- Zero trust is an architecture and a set of principles, not a product. NIST is explicit that no single component delivers it.
- The central shift is away from deciding trust by network location and towards deciding it per request, per resource, against current signals.
- Zero trust network access replaces the network-level tunnel with a broker that grants access to one named application rather than to a network.
- The whole model depends on continuous re-evaluation. A broker that verifies once at sign-in and then leaves the session alone has rebuilt the VPN with better marketing.
- Device posture is the signal most often skipped and the one that most often matters, because stolen sessions carry valid identity but not a managed device.
- NIST expects most organisations to run a hybrid of zero trust and perimeter models indefinitely. Treat that as the plan, not as failure.
Few terms in security have been stretched further by marketing. Almost every network product now claims to deliver zero trust, which has left a genuinely useful architectural idea sounding like a slogan. This piece covers what the underlying model actually says, what zero trust network access changes in practice, the failure mode that quietly reproduces the thing it replaced, and a sequence for starting that does not require replacing your estate.
What the model actually says
The reference text is NIST SP 800-207, which frames zero trust as protecting resources rather than network segments, on the basis that network location is no longer the primary component of a resource’s security posture. The document is blunt about the assumption underneath it: an attacker is presumed to be present in the environment, and an enterprise-owned network is treated as no more trustworthy than any other.
That assumption is the whole idea. Traditional network security spent decades establishing a boundary and treating everything inside it as broadly trustworthy. Zero trust discards the inference from location and replaces it with a decision made per request, against the identity, the device, the resource being reached, and whatever else the organisation can observe at that moment.
NIST’s follow-up guidance puts the shift plainly: the focus moves from controls based on network parameters such as addresses, subnets and perimeters, towards controls based on identities.
Where the decision gets made
The architecture describes three logical components, and understanding the separation is more useful than knowing any vendor’s product names, because most products bundle all three and the bundling is where the compromises hide.
The policy engine makes the decision to grant, deny or revoke access. The policy administrator carries that decision out, establishing or shutting down the communication path. The policy enforcement point sits in front of the resource and is the thing traffic actually passes through.
The question worth asking any product is what the engine reads. If the only input is “did this person authenticate”, the architecture has been reduced to single sign-on with a tunnel behind it. The signals that make the model meaningfully different are the ones about the device, the behaviour and the sensitivity of what is being reached.
What zero trust network access actually changes
Zero trust network access is the specific application of these ideas to remote connectivity, and it is the most common first step because the comparison with a VPN is concrete.
Three differences carry most of the value. The first is scope: a VPN places a device on a network and everything reachable from that network becomes reachable, whereas a broker grants access to one named application. The second is exposure: a VPN gateway must be permanently listening on the internet, which makes it a standing target, whereas a well-implemented broker has the connector initiate outbound and publishes no inbound service. The third is evaluation: a VPN checks at connection time, and a broker should check every request.
That third point is doing more work than the other two combined, which is why it deserves its own section.
The failure mode that recreates the VPN
Consider what this year’s incidents have consistently looked like. Attackers relay a genuine sign-in so the password and the multi-factor prompt both pass correctly, then take the resulting session. We covered one active campaign doing exactly that, in which the attackers then held those sessions open with automation and returned from a residential connection in the victim’s own country.
Against that, a broker that verified identity once at sign-in offers nothing. The session it issued is valid, the identity behind it authenticated correctly, and no further check is made. The architecture has been deployed and the outcome is the same as the VPN it replaced.
What breaks that pattern is not stronger authentication at the front door. It is the requirement that access be re-evaluated as conditions change, and specifically that the decision include something the attacker does not have. In practice that is nearly always the device. A stolen session carries valid identity but arrives from a machine that is not enrolled, not managed and not compliant, and a policy that requires a managed device rejects it regardless of how legitimate the credential looks.
This is the single most useful test to apply to an existing deployment, or to a vendor conversation. Ask what happens if a valid session token is presented from an unmanaged device an hour after issue. If the answer is that it works, the deployment is a tunnel with a nicer login page.
What NIST says it is not
Two clarifications in the guidance are worth carrying into any internal discussion, because both cut against how the term is sold.
First, zero trust is not a product category. It is a set of principles realised through the combination of identity systems, device management, network controls, policy and monitoring you already own or will acquire. Buying a broker is a step, not an implementation.
Second, NIST anticipates that organisations will operate in a hybrid state, with zero trust and perimeter-based controls coexisting, for an extended period. That is not a concession to slow adopters. Legacy applications that cannot authenticate per request exist in nearly every estate, and a plan that requires them all to be modernised first will not start. A plan that protects the highest-value resources first and leaves the rest behind a perimeter is the realistic version, and it is the one the guidance describes.
Concentrating access decisions into a policy engine creates a new dependency. If that engine is unavailable, access to everything behind it stops, and if it is compromised, an attacker gains a position of unusual leverage. NIST treats the policy components as needing protection commensurate with that role. In practice this means the administrative accounts for your policy and identity systems deserve the strongest controls you have, and availability planning for those components is a real requirement rather than a footnote.
A sequence that does not require a rebuild
The order below reflects what tends to make later steps possible, rather than what a product roadmap would suggest.
Inventory resources before anything else. You cannot write per-resource policy without knowing what the resources are, who uses them, and from where. This step is unglamorous and it is where most programmes actually stall.
Get identity in order. Consolidate onto one identity provider where you can, move administrative accounts to phishing-resistant authentication, and remove accounts that should not exist. Policy quality is capped by identity quality.
Establish device posture as a signal. Enrolment and health reporting need to exist before any policy can require them. This is usually the longest lead item and the reason to start it early.
Pick one application and move it. Choose something used by a defined group, valuable enough to matter, and simple enough to succeed. Publish it through a broker with a policy requiring both a compliant device and phishing-resistant sign-in.
Turn on continuous evaluation. Sessions should be re-checked and revocable rather than valid until expiry. If your identity provider supports near real-time revocation, enable it.
Then expand, and accept that some things will not move. Segment what cannot be modernised and monitor it, rather than blocking the programme on it.
- Test the assumption directly: establish what happens today if a valid session is presented from an unmanaged device. The answer defines your actual position.
- List the applications currently reachable to anyone who connects to the corporate network, and rank them by what an attacker would want.
- Confirm whether your identity provider supports near real-time session revocation, and whether it is switched on.
- Establish device enrolment and health reporting now, even if no policy requires it yet, because it is the long lead item.
- Move administrative accounts for your identity and policy systems to phishing-resistant authentication first.
- Choose one application for a first migration, with a defined user group and a clear success measure.
- Write down which systems will not move, and what compensating controls apply to them.
- When evaluating products, ask what signals the policy engine reads and how often, rather than which framework it claims to implement.
The short version
Zero trust is a sound architectural response to a real change: the perimeter stopped describing anything useful once applications moved to the cloud and staff stopped sitting behind it. Zero trust network access is a practical, well-understood first implementation of it.
What it is not is a purchase that produces the outcome. The value lives entirely in what the policy engine evaluates and how often. Deployments that verify identity once and issue a long-lived session have adopted the vocabulary without the property that makes it work, and this year’s intrusions are a running demonstration of why that distinction matters.
Last verified: 10 August 2026 against NIST SP 800-207 and SP 800-207A. Implementation detail varies considerably between products, and the component separation described here is logical rather than physical.