NIST SP 800-207 Zero Trust Architecture Guide: Tenets, Components and Deployment Models

Most zero trust programmes cite NIST SP 800-207, but few teams can say which of its tenets, components and deployment models they have actually built. SP 800-207, published in final form in August 2020, is the reference model behind US federal zero trust strategy and most vendor architectures. It is a set of principles and an abstract architecture, not a control catalogue, so it is easy to claim and hard to evidence. This guide explains what the publication says, how its companion documents (SP 800-207A for cloud-native and multi-cloud applications, and the NCCoE practice guide SP 1800-35) fill the gaps, and how to turn the model into a staged, measurable programme. It is written for security architects, identity teams and the leaders who fund them, with particular attention to service accounts, workloads and other non-human identities, which the standard names as a risk in their own right.

Key takeaways

• Zero trust removes implicit trust from network location. SP 800-207 defines zero trust as concepts for making precise, least-privilege, per-request access decisions on the assumption that the network may already be compromised.
• Three logical components carry the model. A policy engine (PE) decides, a policy administrator (PA) sets up or tears down the path, and a policy enforcement point (PEP) sits in front of every resource.
• There is no single "compliant" deployment. The standard describes three approaches (enhanced identity governance, microsegmentation, software-defined perimeters) and four deployment models, and most enterprises run a hybrid.
• Non-human identities are in scope by design. Tenet 1 treats every service as a resource, and section 5 lists non-person entities in ZTA administration as a specific threat; SP 800-207A extends the model to service-to-service traffic with short-lived workload credentials.
• Evidence comes from decisions, not diagrams. Assessors should see PE decision logs, PEP coverage of resources and posture signals feeding policy, mapped to SP 800-53 Rev. 5 and CSF 2.0 controls.

What it is and who it applies to

NIST SP 800-207 Zero Trust Architecture was written by Scott Rose, Oliver Borchert, Stu Mitchell and Sean Connelly, went through drafts in September 2019 and February 2020, and was finalised on 11 August 2020. The CSRC page lists no revision or replacement as of October 2026. It defines two terms the rest of the document depends on:

• Zero trust (ZT): a set of concepts designed to minimise uncertainty in enforcing accurate, least-privilege, per-request access decisions, on the assumption that the network is already hostile.
• Zero trust architecture (ZTA): an enterprise cybersecurity plan that applies ZT concepts to component relationships, workflow planning and access policies.

The publication is guidance, not regulation. US federal agencies were directed towards it by Executive Order 14028 and OMB's federal zero trust strategy (M-22-09); check current OMB guidance before relying on any specific federal deadline, because OMB has rescinded several earlier cyber memoranda since 2025. For everyone else it is a voluntary reference that auditors, insurers and customers increasingly use as the vocabulary for "do you do zero trust?".

Structure and key requirements

The seven tenets

Section 2.1 sets out the tenets that any ZTA should be designed to meet. They are paraphrased here:

1. All data sources and computing services are treated as resources, including small devices and SaaS.
2. All communication is secured regardless of network location; being on the internal network confers no trust.
3. Access to individual resources is granted per session, with least privilege, and access to one resource does not grant access to another.
4. Access is determined by dynamic policy that includes the identity of the subject, the state of the requesting asset, 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. Authentication and authorisation are dynamic and strictly enforced before access is allowed, with trust continually re-evaluated.
7. The enterprise collects as much information as possible about assets, network traffic and access requests, and uses it to improve its security posture.

Logical components

The PE and PA together form the policy decision point (PDP). The standard separates a control plane (PE, PA, PEP signalling) from a data plane (application traffic), and section 3.4.1 lists network requirements, including that resources must not be reachable without going through a PEP, that managed assets are identified by authenticated credentials rather than spoofable data such as MAC addresses, and that remote assets reach cloud resources directly rather than through a VPN back to headquarters.

Approaches and deployment models

Trust algorithm and threats

• Criteria-based or score-based: criteria-based requires every configured condition to be met; score-based computes a confidence level against a threshold and can reduce privileges rather than deny outright.
• Singular or contextual: singular evaluates each request on its own; contextual also weighs the subject's recent behaviour, which is better at catching misuse of valid credentials (ATT&CK T1078 Valid Accounts).
• Threats in section 5: subversion of the decision process, denial of service or network disruption, stolen credentials and insider threat, limited visibility of the network, storage of system and network information, reliance on proprietary data formats, and use of non-person entities (NPEs) in ZTA administration.

Section 4 adds deployment scenarios worth testing designs against: satellite facilities, multi-cloud and cloud-to-cloud, contractors and non-employee access, cross-enterprise collaboration, and public or customer-facing services (which largely sit outside the tenets).

Identity and NHI requirements

SP 800-207 is often read as a user-access story, but its text is broader. Every service is a resource (tenet 1), every subject is evaluated per request (tenets 3 and 6), and section 5 warns that NPEs such as automated agents and service accounts used to administer the ZTA may themselves be targets, because they need broad privileges and may authenticate with weaker mechanisms than people do.

• Workload identity, not IP allowlists: SP 800-207A recommends identity-tier policies built on cryptographic service identities, with each service presenting a short-lived, verifiable credential, authenticated per connection over mTLS, with connection lifetimes kept roughly to the certificate TTL (it suggests 15 to 30 minutes). SPIFFE IDs carried in SVIDs are its worked example. See the SPIFFE and SPIRE Guide and the mTLS Guide.
• The five identity-based segmentation elements in SP 800-207A: encryption in transit (ID-SEG-REC-1), service authentication (ID-SEG-REC-2), service-to-service authorisation (ID-SEG-REC-3), end-user authentication with phishing-resistant MFA (ID-SEG-REC-4) and end-user to resource authorisation on each request (ID-SEG-REC-5).
• Mesh mapping: in SP 800-207A the mesh control plane plays the administration role and ingress, sidecar and egress proxies act as PEPs. See the Service Mesh Security Guide.
• Service accounts and API keys: long-lived static secrets defeat tenet 6 because there is nothing to re-evaluate. Inventory them, give each an owner, and move to federated or short-lived credentials. See the Workload Identity Federation Guide.
• The policy plane is privileged: accounts and tokens that can change PE policy or PEP configuration are tier-zero. Treat them like domain administrators, with separate administration paths and logging.
• AI agents: autonomous agents are subjects too, and need per-task scoped credentials and contextual policy. See the Zero Trust for AI Agents Guide.

The Cloudflare Thanksgiving breach shows why: one service token and three service accounts that were wrongly believed unused were not rotated after the Okta support breach, and an attacker used them to reach Atlassian systems and source code. A per-request policy cannot help if the credential presented is valid, owned by nobody and never re-evaluated. See the Zero Trust Identity Guide for the user-side controls.

Implementation steps

Section 7.3 of SP 800-207 gives a migration sequence, and SP 1800-35 adds the lessons from building 19 implementations: discover first, start with identity, implement incrementally and verify. The phased plan below combines both.

1. Identify actors: list human and non-human subjects, including service accounts, workloads, API clients and agents, with owners. SP 1800-35 found discovery tools essential for validating the baseline.
2. Identify assets and resources: devices (managed, BYOD, IoT), applications, data stores and SaaS tenants. Unknown assets cannot sit behind a PEP.
3. Identify key processes and assess risk: pick two or three high-value business flows (for example finance approvals, source code access, production administration) as candidates.
4. Formulate policy: write access policy around the business flow, not the network. Decide criteria-based or score-based, and which posture signals are mandatory.
5. Select candidate solutions: map each flow to an approach and deployment model. SP 1800-35's crawl phase shows what existing identity and endpoint tools can do before buying anything ZTA-specific.
6. Deploy in monitor mode: run the PE in report-only or audit mode for a pilot group, log every would-deny decision, tune, then enforce for the pilot ring. Keep the legacy path (VPN, firewall rule) available but logged as the rollback.
7. Expand: widen rings, move the next flow, and retire legacy paths only after a period with no fallback use. Remove the rollback route deliberately, with a change record.
8. Close the loop: feed SIEM and threat signals back into the PE (tenet 7). SP 1800-35 found that multiple PDPs fragment policy and do not share risk, so plan for integration from the start.

Small and large organisations: a small, SaaS-first organisation can reach most tenets with an identity provider's conditional access acting as PE, device management for posture and an identity-aware proxy for the few private applications. A large or regulated estate will run several approaches at once (SDP for users, microsegmentation for data centres, a service mesh for Kubernetes) and must decide early whether one PDP or several federated PDPs make decisions. See the ZTNA Guide and the Network Segmentation Guide.

Evidence and assessment

SP 1800-35 is explicit that ZTA is a set of concepts and principles, not a technical specification that can be complied with. Assessment therefore means showing that each tenet is implemented for named resources, not producing a certificate.

• Decision logs: the PE logs every grant, deny and revoke with subject, resource, signals evaluated and policy version. Sample them in assessments.
• PEP coverage: a list of resources showing which PEP protects each, and evidence that direct paths are blocked (scan or firewall export).
• Posture inputs: proof that device and workload posture actually changes decisions, for example a test where a non-compliant device is denied.
• Policy change control: who can change PE policy, approvals, and an audit trail.
• Re-evaluation: token and session lifetimes, continuous access evaluation or revocation tests.

Mapping to other frameworks

SP 1800-35's full document maps its implemented capabilities to CSF and SP 800-53 Rev. 5, and is the best source for detailed control-level evidence. For the wider control set see the NIST SP 800-53 Guide and the NIST CSF 2.0 Guide; CSWP 20 links zero trust planning to the NIST Risk Management Framework (SP 800-37) Guide.

Common pitfalls

• Buying a product called zero trust: a ZTNA or SASE subscription covers some PEPs. Without policy built on identity and posture, it is a VPN replacement with a new name.
• Users only: service accounts, CI/CD tokens and workloads keep static keys and flat network paths. The Cloudflare breach shows valid but forgotten NHI credentials walking straight through.
• Enclave gateways that never shrink: putting a gateway in front of a data centre and declaring done leaves implicit trust inside it.
• Fragmented PDPs: separate policy engines in the identity provider, the ZTNA broker and the mesh, each with different rules and no shared risk signal, as SP 1800-35 observed.
• Unprotected policy plane: administrators and automation that can change PE rules without strong authentication, approval or logging (the section 5 "subversion of the decision process" threat).
• Posture signals that never deny: device compliance collected but configured as informational only, so tenet 5 exists on paper.

Practitioner checklist

• Map each of the seven tenets to the controls and resources where it is implemented today, and record the gaps.
• Name the PE, PA and PEP for every in-scope resource, and confirm there is no path that bypasses the PEP.
• Choose the approach and deployment model per business flow, and document why.
• Inventory non-human identities with owners and move the highest-risk ones to short-lived or federated credentials.
• Treat accounts and pipelines that change ZTA policy as tier-zero, with separate administration and full logging.
• Run new policies in report-only mode with a pilot ring, keep a logged rollback path, and set a date to retire it.
• Feed device posture, workload identity and SIEM risk into decisions, and test that a failing signal actually denies.
• Track the six metrics above quarterly and report them alongside the CISA Zero Trust Maturity Model Guide stages.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• NIST: SP 800-207A A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments
• NIST: SP 1800-35 Implementing a Zero Trust Architecture
• NIST NCCoE: Implementing a Zero Trust Architecture project
• NIST: CSWP 20 Planning for a Zero Trust Architecture
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Valid Accounts

Related NHI Mgmt Group resources: Zero Trust Identity Guide · Zero Trust for AI Agents Guide · CISA Zero Trust Maturity Model Guide · ZTNA Guide · Device and IoT Identity Guide