What zero trust architecture actually is

Over the last two or three years, “zero trust” has probably turned up in more than one deck you’ve sat through. Your IT lead has mentioned it. So has the auditor. There’s a column for it on the supplier questionnaire a customer sent over. You nodded along — while being fairly clear that nobody has ever actually explained what it means.

That’s what this article is for. No technical specifications, no feature lists. Just one question: the company already spends a respectable sum on security every year, so why is everyone now saying we need to “move to zero trust”? Is this a new label on old products, or has something genuinely changed?

Start with an office building

Picture your security architecture as an office building.

There’s a guard at the front. Visitors sign in, badge through, and they’re in. What happens after that? Nothing, really. They can walk to the kitchen, into a meeting room, take the lift up to the finance floor. The one serious check happened at the door, and it never happens again.

That sounds crude, but twenty years ago it was entirely reasonable. Staff came in at nine. The servers were in the basement. Data didn’t leave the building. The wall was easy to draw, and holding the door meant holding everything.

Firewalls and VPNs are products of that model. They are the door.

Except nobody is in the building any more

The problem isn’t that the door is flimsy. It’s that the building it guards has emptied out.

People work from home, from client sites, from a train, reading email on their own phones. Half the systems are still in the server room, half are in the cloud, and a good number are SaaS subscriptions paid on a card — your HR system, your CRM, physically nowhere near you. Consultants, resellers and the engineer who services the equipment all need to reach something inside.

So where does the wall go? There’s no good answer to that any more.

And that still isn’t the worst of it.

What actually happens is that somebody borrows a badge

Think back over the larger incidents of the past few years. Almost none of them involved anyone breaking through a wall.

What usually happens looks more like this. Someone clicks an email that looks convincingly like it came from accounts. Or a password leaks from an unrelated website and it turns out they used the same one at work. Or someone left six months ago and their account was never disabled. Or a small supplier you’ve worked with for years gets compromised first, and the attacker walks in from there.

What these have in common is that the attacker holds legitimate credentials. They badged in. The guard had no reason to stop them, because as far as the access system is concerned, they’re a normal member of staff.

So what happens once they’re inside?

In the old model, where they can go depends on how the network was carved up — not on what that account was ever supposed to reach. A sales assistant’s account should only see quotations. But since the person is now “inside”, whatever their segment of the network can reach, they can reach too. Including the file server nobody remembers, running software that hasn’t been patched in five years.

The industry has a name for this stage: lateral movement. Think of it as somebody who is now inside the building, working down the corridor trying door handles.

And in nearly every incident that makes the news, the damage isn’t done at the moment they badge in. It’s done once they start trying handles.

That stage is what zero trust exists to deal with.

So what does zero trust actually change?

It removes “where you are” from the security decision entirely.

Under zero trust, being inside the corporate network buys you nothing. Every time you reach for a system, it asks again: who is this? What device are they on? What condition is that device in right now? Are they allowed to touch this particular thing at this particular moment?

Permissions stop being granted at the level of “may enter the network”, too. They’re bound to a combination — this person, on this laptop, may reach these three systems and nothing else.

The last part is the least intuitive and makes the biggest difference: anything you’re not authorised for is invisible to you.

The traditional arrangement lets an attacker see the doors but not open them, so they can work along the corridor at their leisure looking for a broken lock. Under zero trust there are no doors in that corridor at all. You can’t try what you can’t see.

Put the three together and the result is this: when an account is stolen, the exposure equals what that account was already allowed to do. It doesn’t widen just because someone got onto the network.

Worth noting, incidentally, that none of this is a vendor’s invention. The US National Institute of Standards and Technology publishes SP 800-207, the most widely cited formal definition of the principle, and most government and regulatory requirements on the subject are written on top of it.

What is it worth, though?

This is the part you actually care about. Five things, all of which show up in either the P&L or the risk register.

It caps how bad any one incident can get

An unwelcome premise first: security incidents cannot be driven to zero. Anyone who tells you otherwise isn’t worth listening to.

What can genuinely be managed is the worst case for a single incident.

Zero trust changes the shape of one. From “an account was stolen, so every system is exposed” to “an account was stolen, so what that account could do is exposed”.

For a board, that swaps a risk you can’t size for one you can. And once you can size it, you can insure it, explain it, and put a number next to it on the risk matrix.

Remote work, branches and outsourcing stop being exceptions

Most companies handle this the same way today: someone needs remote access, so they get a VPN account.

But a VPN grants entry to the internal network. Handing an outside consultant a VPN login effectively stands them inside your network, after which you’re hoping they don’t wander — or hoping the firewall rules somebody wrote years ago were set correctly.

With zero trust the unit of authorisation is a single system, so “this vendor, three months, this test environment only” is routine rather than an exception that needs its own meeting. Opening a branch, connecting two companies after an acquisition, standing up a temporary cross-company project team — same logic, same process, every time.

The value here isn’t really security. It’s speed.

Audit questions get much easier to answer

If you’re in finance, healthcare, or anywhere on a manufacturing supply chain, these will be familiar: who accessed what, and when? Who approved that permission? How long after someone left was their access removed?

Under the old architecture those answers live scattered across firewall rules, directory groups and each system’s own list of accounts. Producing a report you’re willing to hand over usually means somebody spending several days reconciling it by hand.

Because zero trust routes every access through the same authorisation decision, the record is a natural by-product of the architecture rather than something assembled after the fact.

This benefit gets underestimated a lot. What it saves is senior security people’s time going back and forth with auditors, and that time is expensive.

You stop betting on the internal network being clean

The old architecture carries an unwritten assumption: everything inside the wall is safe.

Once that assumption breaks, there’s no second line of defence. And it breaks in more ways than people expect — a personal laptop that picked something up at home joins the office Wi-Fi; a machine stood up for a test years ago and since forgotten; the engineer’s laptop that came in with the maintenance visit.

Zero trust never assumed the inside was clean in the first place, so none of those turns straight into an incident.

The systems you can’t touch can be protected anyway

Nearly every company has a few untouchables: the controller on the production line, the ERP from a decade ago, equipment the manufacturer stopped supporting long ago.

They tend to be the weakest link, and everyone knows it. The trouble is that the cost and downtime of replacing them is high enough that it gets proposed every year and scheduled never.

Zero trust protection can be placed in front of those systems without modifying them. Which means security improvement no longer has to be tied to the budget for replacing legacy infrastructure.

And that tie is usually where security programmes actually get stuck.

A few things we hear a lot that aren’t quite right

“Zero trust is a product — buy it and you have it.”

It’s an architectural principle, not a part number. There are several ways to implement it and the outcomes differ considerably. Plenty of products carry the label while still funnelling every packet through the vendor’s own infrastructure — which differs from changing VPN suppliers rather less than the slides suggest.

One question is enough during an evaluation: whose hands does our data actually pass through?

“It’s a huge project — downtime, network rebuild, the lot.”

If that’s what a vendor is proposing, it’s worth asking more questions.

The mature approach is staged. Bring one or two systems under management first — the most sensitive, or the ones most often reached from outside — run it for three to six months, see how it behaves, then widen. The first stage usually requires no change to the existing network at all.

“We’re not big enough to need this.”

Smaller companies are more exposed, not less. No dedicated security team, nobody watching a screen at three in the morning, and one ransomware event can stop the business for a fortnight.

The point of zero trust is precisely that it reduces the dependence on somebody watching — it puts the safety in the architecture instead of in one person’s diligence.

If you only have one meeting

Ask these four. They’ll surface where you actually stand fairly quickly:

1. If a member of staff’s password leaked today, what’s the most an attacker could reach? If the answer starts with “it depends which part of the network they come in on”, that’s the old model.
2. How do outside vendors reach our systems today, and how is access revoked when it expires? If revocation depends on someone remembering, that’s a risk.
3. Scanning us from outside, which of our addresses and ports answer? That list is your attack surface. It should be short, and ideally empty.
4. How long would it take to prove that someone who left hasn’t touched anything since? However long that is, that’s your audit cost.

Finally

Zero trust isn’t a stricter front door. It’s the decision to stop using a door to define security at all.

Now that the people, the devices and the systems have all moved outside the wall anyway, reinforcing that wall returns less and less. What zero trust does is swap the basis of the decision — from “where are you” to “who are you, on what device, reaching what”.

That’s a change at the level of architecture, which is why it’s worth an executive understanding it once, properly, rather than filing it as an IT purchase.

In the end, what you’re buying isn’t “nothing will go wrong”. It’s that when something does, the blast radius is predictable.

In risk terms, those are two completely different things.