NIST SP 800-207 — Zero Trust Architecture (ZTA)

Why does it matter?

NIST SP 800-207 matters because it replaced vendor definitions of zero trust with a reference architecture written in neutral terms. Section 1.1 traces the idea from the Defense Information Systems Agency's black core work and the Jericho Forum's de-perimeterization of 2004 to the term coined at Forrester, and notes that federal programs such as FISMA, the RMF, FICAM, TIC and CDM have pushed agencies the same way for more than a decade. The tenets in 2.1 and the components in Section 3 give an enterprise a vocabulary that a policy, an architecture review or a procurement can cite without naming a product.

Key benefits include:

• Resources, not segments

Tenet 1 treats all data sources and computing services as resources, and the abstract makes protecting resources rather than network segments the point of the design (Section 2.1).

• Access per session

Tenet 3 grants access to individual enterprise resources on a per-session basis with the least privilege needed, after trust in the requester is evaluated.

• Dynamic policy

Tenet 4 decides access by dynamic policy that includes the observable state of client identity, the application or service and the requesting asset, with other behavioral and environmental attributes allowed.

• Posture is measured

Tenets 5 and 7 have the enterprise monitor the integrity and security posture of all owned and associated assets and collect as much information as possible to improve that posture.

• Named components

The PE, PA and PEP in Section 3, with their data sources, let an organization map what it already owns to the roles the architecture needs.

How does it work?

Section 2.1 presents seven tenets as an ideal that a given strategy may not fully reach. In order: all data sources and computing services are resources; all communication is secured regardless of network location; access to individual resources is granted per session; access is determined by dynamic policy; the enterprise monitors and measures the integrity and security posture of all owned and associated assets; all resource authentication and authorization are dynamic and strictly enforced before access is allowed; and the enterprise collects as much information as possible about assets, network infrastructure and communications and uses it to improve its security posture. Section 2.2 adds six assumptions, starting with the private network not being an implicit trust zone.

Section 3 describes the policy decision point as two logical components. The policy engine uses enterprise policy plus external inputs in a trust algorithm (Section 3.3) to grant, deny or revoke access and logs the decision; the policy administrator establishes or shuts down the path between subject and resource and generates any session-specific credential; the policy enforcement point enables, monitors and terminates the connection. Inputs come from a continuous diagnostics and mitigation (CDM) system, an industry compliance system, threat intelligence feeds, network and system activity logs, data access policies, enterprise PKI, an ID management system and a SIEM. Section 3.3.1 contrasts criteria-based with score-based and singular with contextual trust algorithms, and says a contextual algorithm is the ideal.

Section 7 describes migration. A pure ZTA built from scratch (7.1) is rarely viable, so most enterprises run a hybrid of ZTA and perimeter-based architecture (7.2) and follow the steps in 7.3: identify the actors on the enterprise (7.3.1), identify the assets it owns (7.3.2), identify key processes and evaluate the risks of executing them (7.3.3), formulate policies for the ZTA candidate (7.3.4), identify candidate solutions (7.3.5), deploy and monitor initially (7.3.6) and expand the ZTA (7.3.7). Section 7.3 warns that incomplete knowledge of assets, subjects and workflows, including shadow IT, leads the policy engine to deny legitimate requests, and maps the steps to the RMF in SP 800-37.

Key Elements

• Section 1, Introduction

1.1 the history of zero trust in federal agencies and 1.2 the structure of the document.

• Section 2, Zero Trust Basics

2.1 the seven tenets and 2.2 the zero trust view of a network, with six assumptions about enterprise and nonenterprise infrastructure.

• Section 3, Logical Components

The PE, PA and PEP and their data sources; 3.1 three approaches; 3.2 four deployed variations (device agent or gateway, enclave, resource portal, device application sandboxing); 3.3 the trust algorithm and its variations; 3.4 network and environment components with the network requirements in 3.4.1.

• Section 4, Deployment Scenarios and Use Cases

4.1 an enterprise with satellite facilities, 4.2 multi-cloud, 4.3 contracted services and nonemployee access, 4.4 collaboration across enterprise boundaries, 4.5 public or customer-facing services.

• Section 5, Threats Associated with ZTA

5.1 subversion of the ZTA decision process, 5.2 denial of service or network disruption, 5.3 stolen credentials and insider threat, 5.4 visibility on the network, 5.5 storage of system and network information, 5.6 reliance on proprietary data formats or solutions, 5.7 non-person entities in ZTA administration.

• Section 6, ZTA and Existing Federal Guidance

Interactions with the RMF (6.1), the NIST Privacy Framework (6.2), FICAM (6.3), TIC 3.0 (6.4), EINSTEIN (6.5), the CDM program (6.6) and Cloud Smart and the Federal Data Strategy (6.7).

• Section 7 and Appendix B

7.1 pure ZTA, 7.2 hybrid architecture, 7.3 the seven migration steps; Appendix B identified gaps in the state of the art.

What does it cover?

NIST SP 800-207 applies to any enterprise planning industrial or enterprise infrastructure and workflows on zero trust principles, and it was written with federal agencies in view (Section 1.1 and Section 6). The abstract names the trends it answers: remote users, bring your own device and cloud-based assets outside the enterprise-owned network boundary. Section 3.4.1 sets the network requirements an architecture must meet, including that enterprise assets have basic connectivity, that the enterprise can distinguish owned from unowned assets, can observe all network traffic, and that resources are not reachable without passing a PEP. The document describes an architecture, not a product or a control catalog, and carries no certification.

What are its objectives?

The publication sets out what a zero trust architecture is meant to achieve:

To remove implicit trust based on network location or asset ownership and evaluate trust per request (abstract and tenets 2, 3 and 6).

To protect resources, meaning assets, services, workflows and network accounts, rather than network segments (abstract).

To decide access by dynamic policy fed by the data sources in Section 3, through a trust algorithm that is ideally contextual (3.3).

To keep the enterprise aware of the integrity and security posture of every asset and to use collected data to improve it (tenets 5 and 7).

To give enterprises a migration path from a perimeter-based network through the hybrid state in 7.2 and the steps in 7.3.

Framework in Context

NIST SP 800-207 is the base document of NIST's zero trust work. SP 800-207A (September 13, 2023) extends it with a model for access control in cloud-native and multi-cloud applications, and SP 1800-35 (June 2025) from the National Cybersecurity Center of Excellence documents implementations built with 24 collaborators. OMB M-22-09 (January 26, 2022) organizes the federal strategy by the pillars of CISA's zero trust maturity model, identity, devices, networks, applications and workloads, and data, and cites SP 800-207 for attribute-based authorization and for traffic that cannot be inspected. Section 6.1 and 7.3 tie adoption to the RMF in SP 800-37 Rev. 2, and Section 6.2 to the NIST Privacy Framework.

Common Framework Mappings

NIST SP 800-207 is commonly mapped to the control catalogs and frameworks whose controls implement its tenets, so a zero trust program can show which existing controls cover each tenet and component.

Mapped frameworks include:

CIS Controls v8.1

CSA CCM v4

ISO 27001:2022

ISO 27002:2022

MITRE ATT&CK

NIST CSF 2.0

NIST 800-53 Rev.5

SOC 2