Zero trust, ZTNA and the end of the VPN default

The perimeter did not fail. It dissolved. Firewalls still do what they always did, and they do it well. What went away was the condition that made a perimeter a sensible place to concentrate defence: that the things worth protecting and the people allowed to use them sat on the same side of one line.

For a long stretch of the industry's history that condition held, and trusting a device because of where it was plugged in was not naive. It was a reasonable engineering shortcut. The applications lived in a data centre the organisation owned. The staff sat at desks in buildings the organisation leased. There was one set of doors, so it made sense to spend the security budget on the doors. Inside the building, machines talked to each other with very little standing between them, because everything inside had already been vouched for by the act of being inside.

Then the two halves of that sentence came apart, and they came apart in opposite directions. Applications moved out: to software as a service, to public cloud, to suppliers who host on your behalf. Users moved out too: to home offices, to client sites, to personal devices, to contractors who never had a desk in the first place. The edge still exists as a piece of equipment, and it is still worth having, but it no longer separates anything meaningful. Most of what your staff use is outside it, and most of the people using it are outside it as well.

The property that turns this from an inconvenience into a security failure is lateral movement. Concentrating defence at one boundary is only safe if nothing behind the boundary matters, and the opposite is true: everything behind it matters. An attacker who gets one foothold, by phishing one set of credentials or compromising one laptop, inherits the same standing that foothold had. From there they move sideways, machine to machine, and nothing asks them to prove anything again, because proving things was the door's job and they are already past the door.

This matters more now than it did when the perimeter model was designed, because of what internal traffic has become. A single click in a modern application fans out into dozens of internal calls between services, and that east-west traffic never crosses the edge firewall at all. The control that everybody points to when asked how the estate is protected is, by volume, watching a small minority of the connections that actually happen.

The virtual private network is the last load-bearing piece of the old model, and it is worth naming precisely what it does. A VPN exists to extend the word inside to people who are physically outside. It authenticates a person, sometimes checks the device, and then places that device on a network: it hands out an address, a route, and the ability to send packets to whatever that network can reach. Everything after that point is decided by the network, not by the person. The VPN, in other words, reproduces trust by location at exactly the moment that trust by location stopped describing anything real.

Naming the property that has to go, rather than the box that has to be replaced, is the whole trick. That property is implicit trust granted by network position, and in 2020 NIST wrote down what an architecture looks like once it has been removed.

NIST published Special Publication 800-207, Zero Trust Architecture, in 2020. It is short, it is free, and it is the document to cite when somebody in a meeting uses the phrase as though it meant a product. Its definition is deliberately about posture rather than equipment.

Zero trust resolves into three working properties, and it is worth taking them one at a time because each one rules out a specific habit.

The first is that there is no implicit trust. Nothing is granted because of where the request came from. Network position may still be an input to a decision, and a request arriving from an unexpected country is a reasonable thing to weigh, but it is an input rather than a verdict. The practical test is simple: if you can name an application that a device can reach purely because of the network it is attached to, you have found implicit trust, and it does not matter how strong the authentication at the edge of that network was.

The second is continuous evaluation. Trust is not a state that a session achieves at nine in the morning and keeps until it is closed. Device posture changes when a laptop misses a patch cycle. Sessions get stolen. People change roles, leave, or have their access revoked in a system that the network has never heard of. A model that decides once and then stops asking is a model that keeps honouring a decision long after the facts it rested on have changed.

The third is per-request authorisation. This is the property that people find hardest, because it changes the unit of decision. The old unit was a session on a network: you are on, therefore you may. The new unit is one request for one resource, evaluated against policy at the moment it is made. It sounds expensive and, done badly, it is. Done well it is invisible, because the evaluation happens in a component that sits in the path anyway.

Two structural ideas follow from that, and they carry through the rest of the module. The decision and the enforcement are separate. Something decides whether this identity may have this resource now, and something else, sitting in front of the resource, carries the decision out. Keeping them separate is what lets one policy govern applications that were built decades apart and know nothing about each other.

It also means segmentation is a component of zero trust rather than a synonym for it. NIST treats logical micro-segmentation as one of the main approaches to a zero trust architecture, alongside enhanced identity governance and the use of network infrastructure with software defined perimeters, and the word alongside is doing real work there. Dividing the network into smaller zones shrinks what a foothold reaches. It does not, by itself, make any decision per request, and an estate that has been carefully segmented can still hand out standing reachability inside every zone.

The definition tells you what has to be true. It does not tell you what to install on Monday. For remote access, which is where most organisations meet the problem first, the product pattern that makes those three properties true has a name of its own.

Zero trust network access is what you get when the three properties above are applied to the specific job a VPN used to do. The mechanism is an identity-aware proxy placed in front of each application, and the crucial detail is that the application has no other front door. It is not published to the internet, and it is not sitting on a network that remote devices can join. The only way to it runs through the proxy, and the proxy asks a question before it forwards anything.

Walk through the decision the way the proxy does, because the order of the questions is the design. A request arrives for a named application. Who is the identity behind it, proven by the identity provider rather than asserted by the client? What is the device, and is it in a state the policy accepts, patched, managed, encrypted? What exactly is being asked for, which application and which operation? What is the context, meaning the time, the location, the recent behaviour of that identity? The proxy takes those answers, evaluates policy, and then either opens a connection to the application on the user's behalf or does nothing at all. Doing nothing is the important half. There is no error page from the application, because the request never reached it.

Set that against the VPN with the same user and the same need, which is what the figure at the top of the module draws. A contractor needs the invoicing application. On the VPN the contractor authenticates, the laptop is placed on a network that includes the invoicing server, and the contractor opens the application. So far the two models look identical from the contractor's chair. The difference is everything that was not asked for. The laptop can now also address the finance file server, the print server, the domain controller and anything else on that network, because reachability was granted at the level of the network rather than the application. Under ZTNA there is nothing to address. The invoicing application was authorised for that identity, that device and that request. The file server was not, so no path to it was ever created.

That is the correction to hold on to. A VPN grants network-level reachability, which is exactly the implicit trust that NIST SP 800-207 exists to remove. ZTNA authorises per application and per request. The two are not points on the same road, so replacing an ageing VPN concentrator with a newer one changes the maintenance bill and nothing about the architecture.

The market has moved accordingly. More than 70 percent of new remote-access deployments now choose ZTNA rather than a VPN. Treat that figure for what it is: an analyst estimate of buying behaviour, not a measurement of a protocol and not evidence that the deployments are any good. It tells you the default has changed, so proposing a VPN for a new remote-access programme is now the option that needs the justification.

Being clear about what ZTNA does not fix is what separates people who have run one from people who have read about one. It does not fix authorisation inside the application: if every authenticated user is an administrator once they are in, the proxy has simply delivered them to that problem more carefully. It does not protect the data after delivery. It does not stop a legitimate identity with a legitimate grant from doing legitimate damage. And it does not cover service-to-service traffic, where the equivalent control is workload identity, typically carried by mutual TLS so that each service proves who it is rather than relying on which subnet it called from.

One more limit deserves naming because it is the one that bites during incidents. The proxy is now in the path of everything. That concentrates a great deal of value in one place, it needs its own availability design, and its policy becomes a production artefact that people will want to change quickly and safely. Moving the decision out of the network does not remove the need to engineer the thing that now makes it.

Almost nobody buys the proxy on its own, which is the next practical problem. ZTNA usually arrives inside a bundle with an acronym on the invoice, and the bundle contains several things that have nothing to do with the access decision.

Secure Access Service Edge, said aloud as sassy, decomposes cleanly and stops being mysterious the moment you take it apart. It is two halves bought as one service. The networking half is SD-WAN, which decides per application flow which underlying link to use, so a branch office can run a broadband line, a private circuit and a mobile connection together and have policy rather than static routing choose between them. The security half is the security service edge, which inspects and authorises what that traffic is allowed to do.

Security Service Edge is that security half bought on its own, without the wide-area networking. It exists as a separate category for a practical reason: plenty of organisations are content with the wide-area network they already have, and are under no obligation to replace a working network contract in order to modernise how access is authorised.

The board names the components of the security half, and naming them is what defuses the acronym. A secure web gateway inspects and filters outbound web traffic. A cloud access security broker governs how staff use sanctioned software as a service. A firewall as a service moves the branch firewall to the provider. And ZTNA authorises one application per request. That last line is the one to sit with: the access decision, the thing the whole argument turns on, is one component, of one half, of one bundle.

Which explains the second market figure, and why it is worth knowing rather than quoting. Over 80 percent of ZTNA is bought inside these bundles, on the same analyst estimates of buying behaviour that produced the first figure. The architectural decision and the procurement decision therefore arrive on the same day, in the same document, from the same supplier, and they get discussed as though they were one decision. Separating them deliberately is a discipline, not a formality: the question of whether the organisation is removing implicit trust is not answered by the question of whose edge the traffic passes through.

As market evidence about who currently sells at scale, the 2025 Magic Quadrant for Security Service Edge, published by Gartner, names Zscaler, Netskope and Palo Alto Networks as leaders. Take that as a description of a market and nothing more. It tells you which suppliers a procurement exercise will encounter. It does not tell you which one fits an estate, and it certainly does not tell you whether a deployment of any of them removed a single grant of standing reachability.

The vendor-neutral questions are more useful than the shortlist, and they are the same four questions whichever logo is on the proposal. Which security functions are actually named in the contract, as opposed to appearing on the diagram in the brochure? Where do the enforcement points physically sit, and what is the added latency for the offices and applications you actually have? What happens when the provider edge is unreachable, meaning does the answer fail open, fail closed, or fail to a cached policy, and have you seen that behaviour tested? And does the ZTNA component authorise per application and per request, or has it been configured as a tunnel terminator that drops users onto an internal network, which is the same old model wearing the new name?

A contract is signed on one date. Removing standing reachability from an estate that has depended on it for its whole working life is not something that happens on a date, and pretending otherwise is how these programmes fail publicly.

The realistic roadmap is a maturity model, and the CISA Zero Trust Maturity Model version 2 is the one to use because it is public, it is free of any supplier's product boundaries, and it was written for organisations carrying decades of inherited systems rather than for a clean sheet.

Its shape is worth learning. It assesses maturity separately in each pillar, covering identity, devices, networks, applications and workloads, and data, with cross-cutting capabilities for visibility and analytics, automation and orchestration, and governance running through all of them. Within each pillar an organisation places itself on a path that runs from a traditional starting point, through initial and advanced stages, to an optimal end state.

Reading it per pillar rather than as a single score is the first discipline, and it is the one that makes the model usable. An organisation is allowed to be advanced on identity and traditional on data. That is not a failure of the assessment, it is the assessment working: it produces a shape that shows where the next increment of effort belongs, which a single number would hide. A single number also invites the wrong conversation, because it can be improved by the pillar that is easiest to move rather than the pillar that carries the risk.

Reading it without vendor goggles is the second discipline. A supplier will map its own product onto the pillars and show you a gap analysis in which the gaps are precisely the things it sells. That is not dishonest, it is what a product map is for, but it is not an assessment of your organisation. The model is a self-assessment, owned by the organisation, and the useful version of it is the one where somebody internal has written down evidence for each placement. A placement with no evidence behind it is an aspiration in a table.

Sequencing follows from how the access decision is made rather than from any ranking in the model. Identity comes first, because every decision in every other pillar needs a trustworthy answer to who this is, and an estate with several unreconciled identity stores cannot make per-request decisions about anything. Devices come next, because posture is the other half of the input to the decision. Applications follow, moving behind a proxy one at a time. Networks and data mature alongside, and treating networks as the starting point is the classic error: it produces a well-segmented estate that still hands out standing reachability within every zone.

The increment that works in practice is unglamorous. Choose one application with a well-understood user population, put it behind the identity-aware proxy, and remove it from the set that the VPN can reach. Keep the VPN for everything that has not moved. Publish the count of applications still reachable only through the VPN, and make that count go down. Each move is small, reversible, and produces evidence, which is what lets the programme survive a change of sponsor. The alternative, switching off remote access on a Friday because a contract went live, produces one memorable weekend and a long-term reputation problem for the whole idea.

None of this makes the older controls redundant, and it is worth saying so plainly because zero trust is sometimes sold as a replacement for everything. Defence in depth still applies: the proxy will sometimes be misconfigured, an identity will sometimes be stolen with its second factor, and the question of what catches the attack next still has to have an answer. What zero trust changes is the size of that answer. Per-request authorisation and segmentation together shrink the blast radius of a compromise, which is a different and more honest goal than preventing every compromise.

A useful definition of finished, then, is not zero VPNs and it is not an optimal rating in every pillar. It is that no application in the estate is protected only by the fact that the requester is on the inside. That sentence can be tested application by application, with a name and a date against each answer, which is why it is worth more than any rating anybody can award themselves.