Zero Trust Architecture: NIST 800-207 in Practice

The old model had one strong boundary and a soft interior. A firewall separated the corporate network from the internet, and anything inside the boundary was treated as legitimate: file shares open to any domain-joined machine, internal applications with no authentication, management interfaces reachable from any desk. The boundary did all the work.

Two things broke that. The resources left the network, to SaaS and to cloud accounts that were never behind the firewall. And attackers kept getting inside, through phishing, a contractor's laptop or a vulnerable edge appliance, at which point the soft interior was the whole problem. Once inside, an attacker inherited every permission the network implied.

Zero trust removes the inference. Being on the network grants nothing. Every request to every resource is authenticated and authorized on its own terms, using who is asking, what they are asking from, and what they are asking for.

This guide covers what the model actually specifies, which is more concrete than the slogan suggests. Network Security Fundamentals owns the perimeter architecture this replaces, Network Segmentation Guide owns microsegmentation mechanics, What Is mTLS owns the workload-to-workload authentication, and Least Privilege Explained owns the authorization principle. This page owns the architecture that arranges them.

Where the term came from

John Kindervag published the zero trust model at Forrester in 2010, and the phrase "never trust, always verify" comes from that work. The idea has an older ancestor in the Jericho Forum, launched in 2004, whose de-perimeterisation papers argued that the corporate boundary was already dissolving.

The first large implementation that published its details was Google's BeyondCorp, built after the Operation Aurora intrusion in 2009 and described in a series of papers from 2014. BeyondCorp moved every internal application behind an access proxy that evaluated user identity and device state on each request, and removed the privileged corporate network entirely. Employees worked from untrusted networks by default.

NIST published SP 800-207 in August 2020, which turned the concept into a reference architecture with named components. Executive Order 14028 in May 2021 directed federal agencies toward it, and OMB M-22-09 in January 2022 set specific goals with a deadline at the end of fiscal 2024. That sequence is why the term is everywhere: it went from an analyst position to a federal mandate in twelve years.

The seven tenets

Section 2.1 of SP 800-207 states the model as seven basic tenets. They are worth reading as written, because most of the disagreement about what zero trust means dissolves against them.

1. All data sources and computing services are resources. Including personal devices used for work, and services in other people's clouds.
2. All communication is secured regardless of network location. The internal network gets the same treatment as the public one. No plaintext internal protocol on the grounds that it is internal.
3. Access to individual enterprise resources is granted on a per-session basis. Access to one resource does not confer access to another, and the grant covers this session rather than a standing entitlement.
4. Access is determined by dynamic policy. The inputs include client identity, application or service, the requesting asset, and may include behavioral and environmental attributes.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. No asset is trusted inherently, and posture is evaluated at the time of the request.
6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed. This is a loop of scan, assess, adapt, and re-evaluate, rather than a gate passed once.
7. The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications, and uses it to improve its security posture.

Tenets three and six are the ones that change how a system behaves. Everything else can be satisfied by a diligent version of a traditional architecture. Per-session evaluation cannot, because it means a device that fails a posture check at 14:00 loses access at 14:00 rather than when its eight-hour token expires.

The components

Section 3 of SP 800-207 gives the architecture a small number of named parts, drawn in its Figure 2. The naming is worth learning because vendor documentation uses it.

Component	What it does
Policy Engine (PE)	Makes the decision. Takes the request plus its signals, applies policy, returns grant or deny.
Policy Administrator (PA)	Carries the decision out. Establishes or tears down the session, issues the credential or token the client uses.
Policy Decision Point (PDP)	The pair above, taken together.
Policy Enforcement Point (PEP)	Sits in the data path. Enables, monitors and terminates the connection between subject and resource.

The control plane, which is where PE and PA live, is separate from the data plane, which is where the PEP sits (Section 3.4). That separation is the structural point of the design: the thing that decides is not the thing in the traffic path, so the decision logic can consider signals the network never sees.

Around that core, Section 3 lists eight data sources that feed the policy engine: a continuous diagnostics and mitigation (CDM) system reporting asset state, an industry compliance system holding the regulatory rules, threat intelligence feeds, network and system activity logs, data access policies, an enterprise PKI, an ID management system, and a SIEM. Those eight feeds are the practical shape of tenet seven, and their absence is the most common reason a zero trust program stalls. A policy engine with nothing to condition on evaluates the same static rules a firewall did.

What one request looks like

A user opens an internal expense application from a hotel network.

1. The request hits the enforcement point, which holds it rather than forwarding it. Nothing has been decided yet.
2. The enforcement point asks the policy decision point. The request carries a user identity, a device identifier, the target resource and its own context: time, source address, client attributes.
3. The policy engine assembles signals. Is the identity authenticated with a phishing-resistant factor, and how recently. Is the device enrolled, encrypted, patched to a current level, and reporting a clean posture. Is the user's behavior consistent with their history. Is the target resource one this user is entitled to at all.
4. Policy evaluates. Say the device is enrolled and compliant, and the identity has a WebAuthn assertion from twelve minutes ago. Grant, for this application, for this session.
5. The policy administrator establishes the session and hands the enforcement point what it needs to permit the traffic.
6. Evaluation continues. If the endpoint agent reports the disk has been decrypted, or the identity provider receives a signal that the session is compromised, the grant is withdrawn while the user is still working.

Step six is the difference between an architecture that satisfies the tenets and one that describes itself as satisfying them. Continuous evaluation requires a channel for posture changes to reach the policy engine mid-session, which is what the OpenID Foundation's Shared Signals framework and the Continuous Access Evaluation Profile standardise. Both were approved as OpenID Final Specifications in September 2025, so the interface for revoking a session mid-flight now has a published shape rather than a per-vendor one.

ZTNA and the VPN

Zero trust network access is the product category that implements the model for user-to-application access, and it is the piece most organisations meet first.

A VPN authenticates a device and then attaches it to a network. Everything the VPN routes to is reachable, and the checks stop at connect time. The blast radius of a stolen VPN credential is therefore a network foothold, and every incident report describing lateral movement from a compromised remote-access account is describing this property.

A ZTNA broker authenticates the user and evaluates the device, then brokers a connection to one named application. The client never joins a network. There is no route to the subnet the application sits on, so scanning, discovery and lateral movement have nothing to operate on. Applications are typically not exposed inbound at all: a connector inside the environment establishes an outbound session to the broker, which means the application has no listening port on the internet for anyone to find.

	VPN	ZTNA
What you get	A network route	One application session
When authorization happens	At connect	Per session, continuously
Device posture	Rarely, at connect if at all	An input to every decision
Inbound exposure	A concentrator on the internet	An outbound connector, no inbound port
Blast radius of stolen credential	The network	The applications that identity is entitled to

Keeping a VPN is not a contradiction as long as it stops being the access control. What the model rules out is authorization by network position.

The five pillars, and where programs stall

CISA's Zero Trust Maturity Model organises the work into five pillars, with three capabilities that cut across all of them, and four maturity stages from traditional through initial and advanced to optimal. The pillars are a useful map of the work.

Identity. Phishing-resistant authentication, per-request authorization, and identity for workloads as well as people. This is first because every other pillar conditions on identity, and because it is the pillar with the highest ratio of risk reduction to effort. Passkeys Explained and WebAuthn Explained cover the authentication half.

Devices. An inventory that is actually complete, posture reporting from every managed device, and the ability to deny access from a device that fails a check. The stall here is unmanaged devices: contractors, personal phones, and the build server nobody enrolled.

Networks. Encryption everywhere, and segmentation fine enough that a compromised host reaches very little. This is the expensive pillar, covered in Network Segmentation Guide, and the reason to start where the blast radius is worst rather than attempting the estate.

Applications and workloads. Access brokered per application, workload identity between services rather than network position, and continuous testing. What Is mTLS covers the workload-to-workload mechanism, and SPIFFE is the common way to give a workload an identity that survives rescheduling.

Data. Knowing what data exists, classifying it, and conditioning access on the classification. This pillar is last in most programs because it is the one that cannot be bought, and a policy engine that cannot distinguish a public marketing asset from a customer database is making every decision with one input missing.

The three cross-cutting capabilities are visibility and analytics, automation and orchestration, and governance. They are cross-cutting because a pillar with no telemetry cannot support dynamic policy, which is tenet four.

Where programs actually stall, in order:

• Legacy applications that cannot authenticate per request. A 2009 application that trusts the network and has no concept of an identity header has to be fronted by a proxy, rewritten, or accepted as an exception with compensating controls. Most estates have dozens.
• Device posture that does not exist for a third of the fleet. Policy conditioned on posture fails open or fails closed, and both are bad. Fail open and the tenet is decorative; fail closed and the contractor cannot work.
• Data classification that was never done. See above.
• Machine and service accounts. They vastly outnumber human identities, they often authenticate with static secrets, and no amount of user-facing phishing resistance touches them.

What zero trust does not fix

Being precise about the limits keeps the architecture honest.

A valid credential used by an authorized user on a compliant device is granted access, because that is the correct decision from every signal available. Zero trust narrows what an attacker reaches after a compromise and shortens how long the access lasts. It does not detect an insider using their own entitlements, which is Insider Threats Guide territory.

It does not remove application vulnerabilities. An SQL injection in an application a user is legitimately authorized to reach executes with that application's database access, and the enforcement point has already correctly allowed the session.

It does not by itself stop ransomware, though it reduces the reach. Encrypting the files one compromised user could open is a smaller event than encrypting a file server every domain user could write to.

And it concentrates risk in the policy decision point. The identity provider and the policy engine become the highest-value targets in the estate, because compromising the thing that makes every access decision is a shortcut to every decision. That component needs the strictest administrative controls in the organisation.

Where to start

For an organisation with a perimeter architecture and a mandate to move, the order that produces the most risk reduction per unit of effort:

1. Phishing-resistant authentication for every human identity, administrators first. Everything downstream conditions on identity, so this is the prerequisite rather than the first step of many.
2. A device inventory with posture. Policy cannot condition on a signal that does not exist.
3. One application behind a broker, end to end. A real per-session authorization path for one important application teaches the organisation more than a year of planning, and it produces the integration patterns the rest will reuse.
4. Segment the worst blast radius. Typically the flat network that a workstation shares with a domain controller, a backup server or an OT segment.
5. Wire the telemetry into a place decisions are made from, which is where What Is a SIEM comes in, because tenet seven is what turns static rules into dynamic policy.

The verdict

Zero trust is an architecture with a published specification, and the specification is short enough to read in an afternoon. The seven tenets say what the model requires; the policy engine, administrator and enforcement point say how the pieces fit; the maturity model says what order to build in.

The part that is genuinely hard is not the concept and not the products. It is having trustworthy signals about identities, devices and data to condition policy on. An organisation that can answer "who is this, what are they on, is it healthy, and how sensitive is what they want" on every request has zero trust whatever it runs. One that cannot has a VPN with a new name.

Related guides

• Network Security Fundamentals
• Network Segmentation Guide
• What Is mTLS
• Least Privilege Explained
• Passkeys Explained