Field Guide · Security Operations
"Never trust, always verify." Zero trust removes the one assumption the old perimeter model was built on — that being inside the network means you can be trusted — and replaces it with an explicit, per-request decision made on identity, device, and context. This guide is the mental model and the architecture behind the slogan: what it actually claims, how NIST SP 800-207 realizes it, how CISA's maturity model stages the rollout, and — just as important — what it does not do.
Zero trust is a strategy, not a product — an architecture you design and a program you run, not a box you buy. The core move is simple to state and hard to implement: stop using network location as a proxy for trust, and make every access to every resource prove itself, every time. Everything below follows from that.
The perimeter model is a hard shell around a soft interior: authenticate once at the edge — the VPN, the firewall — and then move freely, because "inside" is trusted. It fails wherever the shell is bypassed rather than broken: a stolen credential walks straight through the front door, an insider was never outside, and lateral movement lets one compromised host reach the rest. Remote work and cloud dissolved the shell entirely — the resources and the users are no longer inside anything.
Zero trust starts from the opposite assumption. Assume the attacker is already on the network, and treat the enterprise network as no more trustworthy than the open internet. Trust is not granted by where a request comes from; it is earned, per request, by what can be proven about the identity, the device, and the context — and it is never permanent. The term is John Kindervag's (Forrester, around 2010); the idea that "trust is a vulnerability" is the whole thesis.
Zero trust does not make a system "secure." It removes network location as a basis for trust and forces an explicit, signal-based decision at each resource. That directly addresses stolen-credential reuse, flat-network lateral movement, and the dissolved perimeter. The residual risk it leaves: the decision is only as good as the signals feeding it and the policy behind it — a valid credential on a device that looks healthy still passes.
The slogan "never trust, always verify" is usually operationalized as three principles. They are worth stating separately because most failed "zero trust" programs are strong on one and silent on the others.
NIST Special Publication 800-207, Zero Trust Architecture (Final, August 2020), is the reference definition. It frames zero trust as seven tenets — the abstract requirements a real architecture then has to satisfy. Paraphrased:
| # | Tenet — what it requires |
|---|---|
| 1 | All data sources and computing services are treated as resources to be protected — no exceptions for location or perceived importance. |
| 2 | All communication is secured regardless of network location — being on the internal network earns no exemption from authentication or encryption. |
| 3 | Access to individual resources is granted on a per-session basis, with least privilege for that session. |
| 4 | Access is determined by dynamic policy — client identity, application/service, the requesting asset's state, and behavioural and environmental attributes. |
| 5 | The enterprise monitors and measures the integrity and security posture of all owned and associated assets — no asset is inherently trusted. |
| 6 | All resource authentication and authorization are dynamic and strictly enforced before access is allowed — and re-evaluated continuously. |
| 7 | The enterprise collects all it can about the current state of assets, infrastructure, and communications, and uses it to improve its posture. |
Underlying these are 800-207's working assumptions about the modern estate: the private network is not an implicit trust zone; devices on it may not be enterprise-owned or configurable; no resource is inherently trusted; and remote subjects cannot trust their local network. The tenets are what you must achieve; the next section is the machinery that achieves them.
SP 800-207 splits the system into two planes. The control plane decides; the data plane carries traffic and does what it is told. Three logical components do the work:
The Policy Engine (PE) makes the access decision, running a trust algorithm over the available signals. The Policy Administrator (PA) executes that decision — it establishes or tears down the session, issuing or revoking the credential the enforcement point needs. Together, PE and PA form the Policy Decision Point (PDP). The Policy Enforcement Point (PEP) sits in the data path between the subject and the resource and enables, monitors, and terminates the connection on the PA's instruction.
The point of the shape: the subject and its device never reach the resource directly. They reach a PEP, which only opens the specific path the PDP has authorized for that one session — and can close it again the moment the decision changes.
Two consequences follow immediately, and the second is the subject of §09: the decision is only as current as the signals, and the PDP and the identity provider become the highest-value targets in the estate — compromise there subverts every decision made downstream.
Inside the Policy Engine is a trust algorithm that weighs, per request, how strongly the identity is proven (a password is not a passkey), whether the device is managed and healthy, whether the behaviour or environment is anomalous, how sensitive the resource is, and what current threat intelligence says. The output is richer than allow/deny: the engine can step up — demand re-authentication or stronger MFA — or grant reduced access, and because the decision is per-session and re-evaluated, a session already open can be revoked when the signals change.
Two guides carry the detail: how identities are proven and how strong each factor is lives in Identity & Authentication; the discipline of sizing, granting, and expiring the access itself is the Access Decision Handbook. The threat this addresses is stolen-credential reuse and lateral movement — re-checking context at every request, not once. The residual risk: a decision built on stale or fooled signals — a compromised device that still reports healthy — is granted anyway. It narrows the window; it does not read intent.
The clearest place zero trust changes day-to-day practice is remote access. The traditional answer is a VPN: authenticate once, receive a network-level tunnel, and land on a segment — often a broad one — where you are then implicitly trusted. A compromised client reaches everything the tunnel exposes. Zero Trust Network Access (ZTNA) inverts this: a broker, acting as a PEP, authenticates identity and context and connects the user to a specific application, per session, without ever placing the client on the network.
The VPN/IPsec & Tunneling guide covers the tunnel mechanics — and why a tunnel encrypts the path but never makes the endpoints, or the concentrator, trustworthy. ZTNA is the access-model answer to exactly that gap. What it addresses: lateral movement and over-broad network exposure. What it leaves: a legitimately authorized but compromised identity still reaches its one permitted app, and the broker is now a critical dependency and a chokepoint of its own.
If SP 800-207 is the architecture, CISA's Zero Trust Maturity Model (v2.0, April 2023) is the roadmap for reaching it. It organizes the work into five pillars — Identity, Devices, Networks, Applications & Workloads, and Data — each assessed and advanced independently across four maturity stages: Traditional, Initial, Advanced, Optimal (v2.0 added "Initial" to mark the first move off the manual baseline). Three cross-cutting capabilities run through all five.
The model aligns to OMB M-22-09 (January 2022), the US federal zero-trust strategy. Keep the register straight: for federal civilian agencies that memo is a mandate with deadlines; for everyone else CISA's model is recommended practice, not a requirement. Identity is the near-universal starting pillar — it is where attackers concentrate, and one improvement there (phishing-resistant MFA, centralized identity) strengthens every other pillar. These documents revise; align to a named version rather than "zero trust" in the abstract.
"Assume breach" has a structural consequence: shrink the blast radius so one foothold doesn't become the whole estate. Microsegmentation replaces one flat network with many small zones and enforces policy on the traffic between them (east-west), not just at the perimeter. A compromise in one zone then reaches only what that zone's identity is authorized to reach.
NIST SP 800-207A (2023) carries the model into cloud-native and multi-cloud environments, where the "network" is a mesh of microservices that cannot be separated by IP address and subnet. It pushes the decision to the application layer: service-to-service calls authenticate and authorize using workload identities (for example, SPIFFE), enforced by API gateways and service-mesh sidecar proxies — the same per-request logic as user access, applied to machines.
Microsegmentation addresses lateral movement — it is the control that most directly limits how far a breach spreads. What it does not do: segmentation is not isolation. A compromised identity or workload still moves freely within its authorized grants, and over-segmentation adds operational complexity that, under pressure, tends to be relaxed or to fail open. The gain is real; the perimeter it draws is only as tight as the policy behind it.
Because "zero trust" is sold as much as it is engineered, the honest limits matter as much as the model:
No architecture is "secure" in the abstract, and zero trust is no exception. It is evaluable only against a stated adversary — the assume-breach threat model of credential theft, lateral movement, and a dissolved perimeter. Against that adversary it is strong. It does comparatively little against a supply-chain compromise of a component you already trust, a policy that is simply wrong, or a compromised PDP or IdP. State the threat model, or the phrase "zero trust" is decoration.
It is a multi-year program, not a deployment, and a half-built one can fail open — so the order is deliberate.
Verify explicitly · least privilege, per session · assume breach. ("Never trust, always verify.")
Policy Engine + Policy Administrator = the PDP (decides, then executes); the PEP enforces in the data path. The subject never reaches the resource directly — only the path the PDP authorizes, for that one session, revocable at any time.
5 pillars (Identity · Devices · Networks · Apps & Workloads · Data) across 4 stages (Traditional → Initial → Advanced → Optimal), with 3 cross-cutting capabilities (Visibility & Analytics · Automation & Orchestration · Governance). Aligns to OMB M-22-09 — a federal mandate, recommended practice for everyone else.
Frameworks are cited by version — NIST SP 800-207 (Final, August 2020) and SP 800-207A (2023); CISA Zero Trust Maturity Model v2.0 (April 2023); OMB M-22-09 (January 2022) — and all of them revise, so confirm the current revision before aligning control-by-control. Zero trust is a strategy against a stated adversary (assume-breach: credential theft, lateral movement, a dissolved perimeter), not a condition a system can "be in"; it narrows and relocates trust rather than removing it, and every control named here leaves a named residual risk. Pairs with Identity & Authentication, the Access Decision Handbook, VPN/IPsec & Tunneling, Detection Engineering, and Logging & Evidence. Terms are in the Glossary; 00 · Start Here indexes the set.