NIST Special Publication 800-207, titled Zero Trust Architecture, is a US National Institute of Standards and Technology publication from August 2020 that describes what zero trust means in practice. It sets out the basic tenets, the logical components that make access decisions, and several ways to deploy them. It is vendor-neutral guidance rather than a product specification or a certification, and it has become a common reference point when organizations and providers describe their zero trust plans.
At a glance
- It defines zero trust as granting no implicit trust based on network location or on who owns the asset.
- It lists seven tenets, such as securing all communication regardless of location and granting access per session.
- Its core logical components are a policy engine, a policy administrator and a policy enforcement point.
- It describes several approaches and deployment models, so there is no single “800-207 product”.
- NIST’s companion practice guide, SP 1800-35, shows example implementations built with commercial products.
What problem it solves
Traditional networks assumed that anything inside the perimeter could be trusted. Once an attacker got in through a phished laptop or a weak VPN account, they could often move between systems with little resistance. Remote work, personal devices, partners and cloud applications have also made the perimeter hard to draw at all.
“Zero trust” became the answer, but the term was quickly stretched by marketing. SP 800-207 gives buyers and architects a neutral description to measure claims against: what has to be true for a design to count as zero trust, which functions need to exist, and how they fit together. It helps a mid-sized organization plan a roadmap in stages rather than buying one tool labeled zero trust and assuming the job is done.
How it works
Tenets. The publication lists seven tenets. In plain terms: treat data and services as resources to protect; secure all communication regardless of network location; grant access to each resource per session, with least privilege; decide access with dynamic policy that considers the user or service identity, the application and the state of the requesting device, and possibly behavior and environment; monitor the security posture of owned and associated devices; authenticate and authorize dynamically before access is allowed; and collect information about assets, traffic and requests to improve policy over time. NIST notes these are goals and that not every tenet may be fully achievable in a given environment.
Decision and enforcement. A policy engine decides whether a subject may reach a resource, using enterprise policy and inputs such as device health, threat intelligence, activity logs and identity data. A policy administrator acts on that decision by setting up or shutting down the session. A policy enforcement point sits in the path, often as an agent on the device and a gateway in front of the resource, or as a portal, and allows, monitors and ends connections.
Approaches. The publication describes zero trust driven mainly by enhanced identity governance, by micro-segmentation, or by network infrastructure and software-defined perimeters. Real deployments often mix them.
Practice guidance. NIST’s National Cybersecurity Center of Excellence published SP 1800-35, Implementing a Zero Trust Architecture, in June 2025. It documents 19 example implementations built with collaborators and maps them back to SP 800-207 and other NIST guidance.
Core components and deployment models
SP 800-207 has no levels or certification. Its main structures are the logical components and the deployment models below, shown in general terms.
| Element | What it does | How it is usually delivered | What a buyer can ask to see |
|---|---|---|---|
| Policy engine | Makes the access decision for each request | Identity platform, access broker or security service edge policy | How policy uses identity, device and risk signals |
| Policy administrator | Sets up or tears down the session based on the decision | Same platform as the policy engine, or a controller | How sessions are revoked when risk changes |
| Policy enforcement point | Allows, monitors and ends connections to the resource | Device agent plus gateway, enclave gateway, or portal | Where enforcement sits for each application |
| Device agent/gateway model | Agent on the device and gateway in front of the resource | Common in ZTNA products | Support for unmanaged and managed devices |
| Enclave model | Gateway protects a group of resources rather than each one | Often used for legacy or data center applications | Which resources share a gateway |
| Resource portal model | A portal acts as the gatekeeper, often without an agent | Browser-based access for contractors or partners | What device checks are possible without an agent |
Mapping a product to a component is a starting point, not proof of a complete architecture. This is general information, not legal or audit advice.
When it matters for buyers
- When comparing zero trust offers. Ask vendors which SP 800-207 components their product provides and which you still need.
- When building a roadmap. The tenets give a checklist for staging work across identity, devices, applications and monitoring.
- When replacing VPN. Zero trust network access (ZTNA) usually covers part of the enforcement layer, not the whole architecture.
- When reporting to a board or insurer. Referencing a neutral NIST publication makes the plan easier to explain and review.
- When you work with US federal agencies. Zero trust expectations in federal programs commonly draw on this publication.
Our access management overview covers identity and access services that commonly provide the policy engine and enforcement layers.
Questions to ask vendors
- Which SP 800-207 logical components does your product implement, and which must come from other tools?
- Which deployment model does your design use for our applications: agent and gateway, enclave or portal?
- What signals feed your access decisions, and can we see why a request was allowed or denied?
- How do you handle unmanaged devices, contractors and service accounts?
- How are sessions re-evaluated or revoked when device health or user risk changes?
- Can you show a mapping of your product to SP 800-207 and the example builds in SP 1800-35?
How it differs from zero trust security
Zero trust security is the overall security model: remove implicit trust based on network location, check identity, device and context for each request, grant least privilege and assume a breach can happen. SP 800-207 is one specific publication that turns those principles into a reference architecture with defined tenets, components and deployment models. An organization can pursue zero trust without citing NIST, but SP 800-207 is the most widely used neutral description of what the architecture contains. Practical build examples live in the NIST SP 1800 series, and supporting controls and identity requirements come from publications such as NIST SP 800-53 and NIST SP 800-63.
Problems this helps with
- Every vendor says its product is zero trust and we need a neutral reference
- Users on the office network are trusted by default
- Board or auditors want our zero trust plan tied to a recognized standard
- Remote staff, contractors and cloud apps no longer sit inside one perimeter
