From VPNs to zero trust

The perimeter model draws one line around the organization. Outside the line is the internet, untrusted. Inside is the corporate network: the file servers, the wiki, the build system, the payroll application, the admin consoles. A firewall guards the line, and the rule of thumb is that anything already inside is one of us.

The VPN fits into that picture as a drawbridge. A remote employee proves who they are, usually with a password and sometimes a second factor, and the VPN gives their laptop an address on the inside network. From that moment the laptop is, as far as the network can tell, sitting at a desk in the office. That is the crucial detail: a classic VPN grants network-level access. It does not let you into "the wiki"; it lets you onto the network where the wiki, and everything else, happens to live.

NIST's zero trust document has a precise name for that inside space: an implicit trust zone, an area where everything is trusted to the level of the last checkpoint it passed. Airport security is its example. Once you are past screening, nobody checks again at the gate lounge. A perimeter network makes the whole company one enormous lounge.

The trouble shows up when the wrong person gets past the checkpoint. A phished password, a token stolen from a browser, an infected laptop that connects to the VPN every morning: each one puts an attacker inside the trust zone with whatever the network allows. What happens next has its own name. Lateral movement is the work of going from the first foothold to the thing the attacker actually wants, hop by hop: from the laptop to a file share, from the share to a script with a service password in it, from that service account to the database. MITRE ATT&CK lists it as a whole tactic, and lists "valid accounts" as one of the most common ways in, because a real username and password look exactly like an employee.

Two changes made this worse. First, the inside stopped being a place. Applications moved to cloud services, staff moved home, and contractors brought their own devices, so the perimeter turned into a collection of exceptions. Second, nearly every serious intrusion now involves a credential at some step, and a perimeter checks credentials once, at the drawbridge, and then believes them for hours.

"Zero trust" was coined years before it had a standard definition, which is part of why the phrase gets stretched over almost any product. The reference most people now use is NIST Special Publication 800-207, Zero Trust Architecture, from August 2020. It is short, vendor-neutral and readable, and it states the idea as seven tenets. The headline sentence of each is quoted below; the comments are ours.

The same document names the moving parts, and the names are worth learning because every product maps onto them somehow. The policy enforcement point (PEP) sits in the path between a subject (a person or a program) and a resource. It enables, monitors and terminates connections, but it does not decide anything itself. It asks. The policy engine (PE) makes "the ultimate decision to grant access to a resource for a given subject", feeding enterprise policy and outside signals into what NIST calls a trust algorithm, and it logs every decision. The policy administrator (PA) carries the decision out: it tells the enforcement point to open or close the path and issues any session-specific token or credential. Together the engine and the administrator form the policy decision point (PDP).

Notice the two planes. Decisions travel on a control plane, a separate channel between the enforcement points and the decision point. Application traffic travels on the data plane, through the enforcement point and nowhere else. A resource should not be reachable except through a PEP at all; ideally an attacker on the same network cannot even see that it exists.

Here is a small policy engine. At the top is the policy: a list of allow rules. Each rule names who (a role), what (a resource), and the conditions the request must meet: what kind of device, how strong the sign-in, from where, and when. Anything no rule allows is denied. That is default deny, the same principle as in a firewall, applied to people and applications instead of addresses and ports.

Below the policy are twelve made-up requests from one morning. Most come from employees doing their jobs. Four come from an attacker using phished credentials: in two of them the attacker also talked a tired user into approving a push prompt. Load the VPN = full access preset and watch everything go through. Then load Zero trust and see which requests survive, and which honest ones now get stopped. Click any request to see the engine's reasoning, rule by rule, and change its attributes to see what would flip the answer.

Worked example: the phished payroll clerk

Request 10 is an attacker who phished Ben's password and then sent push prompts until Ben tapped "approve". Under VPN + MFA it is allowed: the VPN wanted a password and a second factor, and it got both. Nothing in that policy knows that the device is one the company has never seen, in a country Ben has never logged in from, at two in the morning.

Under Zero trust, the engine looks for a rule that grants the finance role access to payroll. Rule 4 does, and the engine checks its conditions one by one: device must be healthy (it is unmanaged, so fail), sign-in must be a passkey (it was a push approval, so fail), location must be known (it is unfamiliar, so fail). Three independent reasons to say no. The attacker would have to beat all three at once, and the passkey condition alone defeats remote phishing, because a passkey will not sign in to a look-alike site (Chapter 4).

Now look at the cost. Request 4 is the real Ben, checking payroll from his own phone in the evening. The zero-trust policy denies him too. That is not a bug in the simulator; it is the trade-off every policy author makes. The usual answer is to give the honest user a path that meets the bar, such as a managed device or a passkey on his phone, and to make the denial message tell him exactly which condition failed. Request 12 is the other honest lesson: the wiki rule accepts any device with a second factor, so the attacker who phished Cara and got her push approved reads the wiki. Low-value resources get looser rules on purpose. Make sure they really are low-value.

The second input to every decision, after identity, is the device. Device posture is the set of facts about a device that bear on how far to trust it: is it enrolled in the organization's device management, is the disk encrypted, is the operating system on a supported version with current security updates, is endpoint protection running and quiet, is the screen lock on. Tenet 5 asks the enterprise to measure this for every asset, owned or not.

The facts have to be trustworthy, and that is harder than it sounds. A device that simply reports "I am patched" can lie, and malware with administrator rights can make it lie. Stronger designs tie the device's identity to a key held in its hardware security chip, issued when the device was enrolled, so that "this request comes from managed laptop 4471" is a cryptographic statement rather than a claim. NIST is explicit that devices must be told apart using enterprise-issued credentials, not information that can be spoofed, such as a network MAC address.

Posture changes over a day. A laptop that was healthy at nine can miss a critical update by lunch, or trip an endpoint alert at three. A perimeter network checks posture, if at all, when the VPN connects, and then trusts the session until the user disconnects. Zero trust asks the question again. The usual mechanism is the token: after a decision, the policy administrator issues a short-lived credential for that resource, and when it expires the device must come back and be judged again. Some systems go further and push a revocation as soon as a signal changes, without waiting for the expiry.

How long should tokens live? The instrument below lets you measure the trade-off. The laptop falls out of compliance at a moment you choose. You set how long tokens last and how often the engine re-evaluates live sessions. The timeline computes how long the unhealthy laptop keeps its access under three designs.

Worked example. Tokens last 60 minutes and are issued at 9:00, 10:00, 11:00 and so on. The laptop misses a critical update and goes out of compliance at 11:15, which is t₀ = 135 minutes into the day. The next renewal is at 12:00, minute 180, so the unhealthy laptop keeps access for 180 − 135 = 45 minutes. Add live re-evaluation every 5 minutes and the next check is at minute 140, so the exposure drops to 5 minutes. The classic VPN session, checked only when the user connected at 9:00, keeps access for the remaining 480 − 135 = 345 minutes, until the user goes home.

The price shows in the last readout. Five-minute tokens mean 96 decisions per laptop per day, against 8 for hourly tokens. Multiply by every laptop and every application and the policy engine becomes a busy, critical service. That is why designs mix the two: moderately long tokens for the common case, with live re-evaluation or pushed revocation for the signals that matter most, such as "this device just raised an alert".

Blast radius is a graph problem. Draw every resource as a node. Draw an arrow from A to B wherever something on A can open a connection to B. An attacker who controls A can reach everything along the arrows, and if they can take over one of those nodes (because it is unpatched, or keeps a password in a script, or holds keys to something else) the search continues from there. Everything the search touches is exposed: the attacker can at least try it.

This model company has fifteen resources in five zones. Four are crown jewels, marked ◆: payroll, the customer database, the backups, and the identity admin console. Choose the attacker's foothold and the access model, and the instrument runs a breadth-first search: it counts what is reachable, which crown jewels are exposed, and the shortest path to each. Click a node, or pick it from the list, to see the path.

Worked example: the engineer's laptop, four ways

Start from the engineer's laptop with malware the endpoint tools have not noticed. On the flat VPN, all 14 other resources are one hop away, including all four crown jewels. The attacker does not need to be clever; the network does the work.

Segmented, the laptop sits in the user zone. It can still reach the other laptops (same zone), the printer, the four applications, and the file server and payroll, because users legitimately use them and a zone rule cannot tell this user from the others. The file server is weak, and servers talk freely among themselves, so the database and backups fall at hop 2. Three of four jewels are exposed. Only the identity console, in the admin zone, is out of reach.

Per-app, identity only: the engineer is entitled to the wiki, email, code repository and build server, and nothing else is even visible. One jewel is still exposed: the build server holds deployment keys to the customer database, so the path is laptop → build server → database, two hops. That is the lesson zero trust does not erase: an entitlement is an arrow, and a machine with broad keys is a bridge. The fix is to scope those keys, which is what workload identity is for.

Per-app with device checks gives the same answer while the malware is undetected, because the device still looks healthy. Switch the foothold to "endpoint protection flagged it" and the device fails posture: every arrow from the laptop disappears and the exposure drops to zero. Switch to "phished password, attacker's own device" and the same thing happens, because an unknown device never passes the device check, while on either VPN model the phished password alone opens everything a laptop could reach.

BeyondCorp. The best-documented early large deployment is Google's. In a 2014 paper, BeyondCorp: A New Approach to Enterprise Security, Rory Ward and Betsy Beyer described "removing the requirement for a privileged intranet and moving our corporate applications to the Internet". Employees reached internal applications through an access proxy on the public internet, the same way from the office as from home. The proxy granted access based on who the user was and on an inventory of managed devices, each with its own certificate. The office network itself was treated as no more trusted than a coffee shop's. It took years and many follow-up papers, and that is part of the lesson.

Identity-aware proxies and ZTNA. That access proxy is now a product category, usually called an identity-aware proxy or zero trust network access (ZTNA). A proxy in front of each web application authenticates the user with the organization's identity provider, checks device posture through an agent or a certificate, consults policy, and only then forwards the request. The application itself is not reachable from the internet except through the proxy. For non-web protocols, an agent on the laptop builds a tunnel to a gateway per application rather than to a whole network: the VPN's mechanics, with the scope cut down to one resource.

Mesh networks with ACLs. For a small organization the most practical step is often an overlay network: a mesh of encrypted peer-to-peer tunnels, typically WireGuard, where each device has its own key and a coordination service distributes keys and policy (the mechanics are on networks.jelia.nyc, under overlays and NAT traversal). What makes a mesh a zero-trust tool rather than a flat VPN is its access control list. Every device is enrolled to a person or a tag, and the list says which identities may reach which tags on which ports. With no rule, there is no path, even between two laptops on the same mesh.

Service to service: mutual TLS and workload identity. Zero trust is not only about people. Inside a data center, services call each other constantly, and the perimeter habit is to trust a call because of where it comes from: anything on the build subnet must be the build system. That fails the moment anything else lands on that subnet. The alternative is to give every workload a cryptographic identity and to have both ends of every connection prove theirs with mutual TLS (mTLS): in an ordinary TLS handshake only the server shows a certificate (Chapter 3); in mTLS the client does too. The receiving service then authorizes by that identity, not by address.

The spiffe:// name comes from SPIFFE, an open set of standards for naming workloads and issuing them identity documents, as X.509 certificates or JWTs; SPIRE is its reference implementation. The pattern matters more than the product: identity is issued automatically to the workload by something that can attest what it is (which machine, which container image), certificates live for minutes or hours rather than years, and renewal is automatic. A stolen certificate is worth little for very long, and there is no long-lived password sitting in a configuration file for an attacker to find. The same idea reaches into OAuth: RFC 8705 binds access tokens to a client's TLS certificate, so a token copied off the wire is useless without the matching private key.

The US Cybersecurity and Infrastructure Security Agency publishes a maturity model that turns NIST's principles into a progression. Version 2.0, dated April 2023, organizes the work into five pillars, "Identity, Devices, Networks, Applications and Workloads, and Data", with three capabilities that cut across all of them: visibility and analytics, automation and orchestration, and governance. Each pillar moves through four stages, from Traditional through Initial and Advanced to Optimal. The point of the model is that an organization can be Advanced on identity and Traditional on data at the same time, and that is normal.

Its identity pillar shows how concrete the stages are. For authentication, the model's four stages read, in short:

A realistic migration follows the same logic as the instruments above. Most guidance, from NIST, CISA and the UK's National Cyber Security Centre, lands on roughly this order:

1. Inventory. Know your users, devices, applications, services and data. NIST's migration chapter starts here; you cannot write "who may reach what" without both lists.
2. Identity first. One identity provider for everything, with strong, ideally phishing-resistant, sign-in. Every later decision depends on it.
3. Device health. Enroll managed devices, give them hardware-backed identities, and start collecting posture before you enforce on it, so you know how many devices would fail.
4. Protect the highest-value applications first. Put an enforcement point in front of the systems in your crown-jewel list, write narrow rules, and run them in a logging-only mode before switching to enforce.
5. Shrink the VPN. As applications move behind enforcement points, take them off the flat network. The VPN ends up as a fallback for the few systems that cannot move yet.
6. Workloads and data. Workload identity and mTLS between services, then data-level controls, are the long tail.

The identity provider becomes the crown jewel. When every decision starts with "who is this?", whoever controls the identity provider controls everything. Its administrator accounts need the strongest sign-in you have, their own enforcement, few members and close monitoring. Its availability matters too: if the policy engine is down, nobody works. NIST calls out both risks, subversion of the decision process and denial of service against it, as threats to a zero-trust architecture.

Policy sprawl. Hundreds of applications times dozens of roles times device and location conditions is a lot of rules, and rules accumulate the way firewall rules do. A rule written for one urgent project ("contractors may reach the build server from any device") outlives the project. Review rules on a schedule, attach an owner and an expiry to each exception, and prefer a few broad roles with clear rules over many personal ones.

"Zero trust" as a label. Because the phrase has no trademark, it gets attached to almost anything with a login page. A useful test is to ask the NIST questions of any product: does it decide per resource and per session, does it use device state, does it re-evaluate, does it log the decision, and can a resource be reached without passing through it? A VPN with MFA is a better VPN, not zero trust.

Legacy systems. Some applications cannot sit behind a proxy: old protocols, hard-coded addresses, devices with no way to install an agent. NIST's enclave model exists for them. Put a gateway in front of the whole group, keep the group small, and accept that inside it, the old rules still apply.

It does not stop an authorized user. If the policy says the finance clerk may read payroll, malware running as the finance clerk on a healthy-looking laptop can read payroll too. The lateral-movement graph made this plain. Zero trust shrinks what any one compromise can reach and makes every access a logged decision; detecting misuse of legitimate access is still the job of monitoring (Chapter 17) and response (Chapter 18).