Most organisations still protect their data the way medieval towns protected themselves: a thick wall around the outside, and once you are through the gate, you are treated as a friend. That worked when everyone sat in the same office and the data lived in one server room. It stopped working the day your finance team started approving invoices from a kitchen table three time zones away.
Zero trust is the name for the replacement model. You do not need to understand encryption or network protocols to lead its adoption, but you do need to understand what changes, why it costs money, and what your people will complain about first. That is what this covers.
Why the perimeter stopped protecting anyone
Traditional security assumed a clear inside and outside. Firewalls guarded the edge, and a VPN tunnel was the modern equivalent of a staff pass at the door: once you were in, you could wander.
The problem is that the wall assumes the wrong thing about the people inside. A stolen password is not a broken wall. A contractor's laptop that was compromised at another client is not a broken wall. A convincing email that gets one employee to sign into a fake login page is not a broken wall either. In each case, the attacker is now standing inside the castle with a valid badge, and the network treats them as staff.
That is why the phrase assume breach matters. Perimeter thinking asks, "How do we keep them out?" Zero trust asks a harder and more useful question: "If they are already in, how much can they reach before anyone notices?"
What zero trust actually means
Zero trust is not a product you buy, and it is not a single project with a finish date. It is a design principle: no request is trusted because of where it comes from. Every request is verified on its own merits, every time.
In practice, that means four questions get answered before anyone sees a piece of data:
- Who is asking? Identity confirmed with strong authentication, not just a password.
- From what device? Is it managed, patched, encrypted, and free of obvious compromise?
- What are they trying to reach? Access is granted to a specific application or data set, not to the network as a whole.
- Does policy allow it right now? Context matters: unusual location, unusual hour, unusual volume of downloads.
A useful comparison is a hotel rather than a castle. Your key card opens your room, the gym, and maybe the lounge. It does not open the room next door, and it stops working the moment you check out.
What changes for your team, day to day
Less invisible convenience
Under the old model, one VPN login bought hours of quiet access. Under zero trust, people authenticate more often and to more specific things. Expect friction in the first weeks, especially from anyone who works across many systems.
More device discipline
If a laptop is badly out of date, it may simply be denied access to a system. That is the system working, not failing. It also means device management stops being an IT preference and becomes a condition of doing the job.
Better answers during an incident
When something does go wrong, the question "what did they touch?" has a real answer, because access was scoped from the start. Investigations get shorter. Notification decisions get easier. Regulators and customers get clearer answers.
Perimeter security bets that nobody gets in. Zero trust bets that someone eventually will, and plans accordingly.
Why managers decide whether this works
Most zero trust programmes fail for reasons that have nothing to do with technology. They fail because rollout felt like punishment, because a senior leader quietly kept an exemption, or because nobody explained why the extra login step appeared.
Three things are firmly in your control:
- Explain the reason, not just the rule. "This is so a stolen password cannot reach payroll" lands far better than "security policy requires it."
- Protect people who report mistakes. Someone who clicks a phishing link and tells you within ten minutes has done you a favour. Treat that as a win publicly, or the next person stays quiet.
- Hold the line on exemptions. Every informal bypass becomes the example everyone else cites. If an exception is genuinely needed, make it time-limited and recorded.
Questions to ask before you approve a budget
- What breaks for employees on the first day, and who supports them?
- Can we pilot with one team before a company-wide switch?
- How are contractors, temporary staff, and personal phones handled?
- Who is on call when a legitimate user is locked out at 7am?
- What will we measure to know this is working, beyond "nobody complained"?
Identity, device management, and logging are the three areas where money is usually needed. Skipping logging is the most common mistake: without it you have stricter doors but no idea who walked through them.
A practical first ninety days
You do not need to rebuild everything at once. Start with the changes that reduce the most risk for the least disruption.
- List your critical systems and who genuinely needs access to each. The list is usually shorter than expected.
- Turn on multi-factor authentication everywhere, starting with email and administrator accounts.
- Cut the number of people with administrator rights, and shorten how long a session stays valid.
- Pick one application and pilot scoped, verified access with a willing team.
- Write a one-page access policy that a new hire could read and follow.
- Run a tabletop exercise: if an account were stolen tomorrow, what would you do in the first hour?
Treat this as a direction rather than a destination. Systems get added, people change roles, suppliers come and go, so the access rules need reviewing at least once a year. Your job is not to understand the plumbing. It is to make sure the organisation keeps asking who should have access to what, and to back the people who make the answer real. If your contracts or regulatory obligations are unclear, a qualified adviser in your jurisdiction can confirm what you are required to do.
Photo: Utility_Inc / Pixabay
