Zero trust

The traditional model had a perimeter. Inside it, systems trusted each other; outside, they did not. That model broke for reasons that are now obvious: staff work from anywhere, workloads run in providers’ datacentres, suppliers need access, and one phishing email puts an attacker inside the trusted zone, where nothing further is checked.

Zero trust replaces location with evaluation. Every request is authenticated, authorised against policy, and evaluated with whatever context is available: which identity, on which device, in what state, to which resource, doing what. The decision is made per request rather than per session, so that access can be withdrawn when the context changes.

Architecturally it is described as a policy decision point that makes the call and a policy enforcement point that applies it, sitting in front of the resource. NIST SP 800-207 is the reference document and is worth reading precisely because it is vendor-neutral and describes the properties rather than the products.

Three principles carry most of the practical weight. Verify explicitly, every time, rather than inheriting trust from a previous step. Grant least privilege, including just-in-time and just-enough access rather than standing rights. And assume breach: design so that a compromise of one component does not imply the rest, which in practice means segmentation, small credential scopes and encryption between services.

The most common failure is buying it. There is no zero trust product, and a vendor’s zero trust platform is a component: an identity provider, an access proxy, a device compliance service, a microsegmentation tool. Each is useful. None makes an architecture, and estates that bought one and declared the programme complete have generally improved remote access and changed nothing about the inside of their datacentre.

The second is stopping at the user. Human access gets identity, device checks and conditional policy, and service-to-service traffic inside the estate keeps working exactly as it did: implicit trust based on being on the network, static credentials, no authentication between services. That is where an intruder operates after the first foothold, so a programme that only covers people has not addressed the phase of an intrusion that matters most.

The third is the exception list. Legacy applications that cannot authenticate modernly, appliances that only speak old protocols, a supplier’s tool that needs a flat route. Each exception is negotiated, documented and permanent, and the set of exceptions eventually describes a small classic network inside the new one. On engagements, the exceptions are where we work.

The fourth is a policy engine with no context worth using. Evaluating every request is only valuable if the evaluation has signal in it. Where the policy is “authenticated user, any device, any location”, you have a per-request check that always says yes, which is more infrastructure and the same security.

These are compared as if they were three options for the same job. One is an architecture and two are access mechanisms.

The important rows are the last two. ZTNA is a genuine improvement over a VPN because it removes the network route, and it is one enforcement point in an architecture that also has to cover service-to-service traffic, administrative access and data. Replacing a VPN with ZTNA and calling the programme finished is the most common version of this project, and it leaves the internal estate exactly as it was.

Treating it as a purchase. It is a design principle applied across identity, devices, network, workloads and data, and the work is mostly not in buying anything.

Ignoring machine-to-machine traffic. Most of the traffic in an estate is between services, and most zero trust programmes never touch it.

Building policies with no signal. A conditional policy that accepts any device from anywhere is a box ticked.

Permanent exceptions. Every exception needs an owner, a compensating control and a date. Without those three it is the architecture.

Assuming encryption is authentication. A TLS connection that does not verify the client proves nothing about who is calling, which is why mTLS exists.

Start where the intrusions start. Identity first: one provider, origin-bound factors, conditional policy with device state as a real signal. That single step removes more risk than any network change, because the current perimeter is the identity plane.

Then remove standing access. Administrative rights granted just in time and expiring, rather than permanent membership of privileged groups, changes what a compromised account is worth. This is usually harder politically than technically.

Then work inwards. Microsegmentation between workloads, mutual authentication between services rather than address-based allow-lists, and short-lived workload credentials instead of static keys. Start with the segment that would hurt most and expand, since a programme that tries to do the whole estate at once does not finish.

Measure it as reachability rather than as maturity. The honest question is: from a compromised workstation, what can be reached today without a further credential. Answering that with a test, at the start and again a year later, is a far better metric than a maturity score, and it is the same question an internal engagement answers.

We do not audit zero trust as a checklist. We test the property it claims: whether a foothold in one place yields access elsewhere without an explicit, policy-evaluated decision. The report describes what we reached from where, which decisions were re-evaluated and which were inherited.

The exceptions are the deliverable’s most useful part. We enumerate the paths where trust is still implicit: legacy protocols, flat segments, service accounts with static credentials, appliances outside the policy plane. Those are actionable, and they are invisible to a maturity assessment that reads policy documents.

Severity is written against reach. An exception that permits one legacy application to authenticate weakly is a moderate finding. The same exception on a segment containing the directory or the backup infrastructure is a critical one.

Whether the architecture holds when someone is already inside is exactly what testing from a position inside the network is designed to establish.

Can we buy zero trust? No. You can buy components that enforce it: an identity provider, an access proxy, device compliance, segmentation tooling. The architecture is how they are combined and which decisions are re-evaluated, and that part is yours.

Is zero trust the same as replacing our VPN? No, though it is where most programmes start. Removing the network route in favour of per-application access is a real improvement and covers one path. Service-to-service traffic, administrative access and data access all remain.

Where should we start? Identity, with origin-bound factors and conditional policy that uses device state. It addresses the route most intrusions take, and every later step depends on having one authoritative identity plane.

How do we know it is working? Test it. From a compromised workstation, establish what is reachable without a further explicit decision. That number, measured now and again later, is evidence. A maturity score is an opinion.