NIST SP 800-207: Seven Zero Trust Tenets and Architecture

Being on a corporate network or using a company laptop does not, by itself, make an access request safe. A legitimate account can be stolen, and a managed device can become compromised.

NIST SP 800-207 explains how to design and operate access controls around this reality: allow the people and services that need access to reach the resources they need, with the minimum necessary privileges.

This article summarizes the August 2020 publication. Practical examples illustrate the concepts; they do not represent requirements to purchase particular products.

What is NIST SP 800-207?

NIST is the US National Institute of Standards and Technology. SP stands for Special Publication. The SP 800 series includes information security guidance and research.

SP 800-207, titled Zero Trust Architecture, is primarily intended for enterprise security architects, with useful guidance for administrators and security managers. It covers principles, logical components, deployment patterns, use cases, threats, and migration.

The publication is freely available and can inform organizations outside the United States. It provides an architectural reference that organizations adapt to their business processes and assets, rather than a deployment plan that works unchanged everywhere.

What the document covers

Section	Main subject	What it helps you understand
1. Introduction	Context, purpose, and structure	Why dependence on network boundaries needs to be reconsidered
2. Zero Trust Basics	Definitions, seven tenets, and network assumptions	The foundations of access decisions
3. Logical Components	PE, PA, PEP, information sources, and architecture variations	How decisions and enforcement work together
4. Deployment Scenarios	Branch offices, clouds, contractors, collaboration, and public services	Where the architecture can be applied
5. Threats	Compromised decision processes, outages, stolen credentials, and other risks	What still needs protection after deployment
6. Existing Federal Guidance	Risk management, privacy, identity, and related programs	How ZTA fits into wider governance
7. Migration	Discovery, policy design, pilots, and expansion	How to introduce ZTA incrementally

The appendices also discuss terminology, technology gaps, interoperability, and research needs.

Zero trust and zero trust architecture

Zero trust (ZT) is a set of security principles. Zero trust architecture (ZTA) is the design that puts those principles into practice.

ZT assumes an attacker may already be present. Network location and asset ownership alone do not establish trust. Access decisions consider identity, authorization, device condition, and other relevant information.

ZTA applies those principles across identity management, applications, endpoints, networks, monitoring, and operational policies.

Authentication establishes who or what is requesting access. Authorization determines which resources and actions are permitted. A successful login should not automatically unlock every system.

Why this approach is needed

Enterprise resources and users now span offices, remote locations, SaaS platforms, cloud environments, and partner organizations. A single network boundary cannot adequately describe all of them.

Perimeter controls remain useful for blocking external attacks, but they offer limited protection against lateral movement after a breach or misuse from inside the environment.

ZTA therefore concentrates on access to individual resources. An employee may be allowed to use an HR application without being allowed to read payroll records or change salary information.

The seven zero trust tenets

Section 2.1 describes seven tenets that guide design. It also acknowledges that every tenet may not be fully implemented in its ideal form for a particular strategy. Organizations should assess their gaps and improve progressively according to business needs and risk.

1. Treat all data sources and computing services as resources

The scope extends beyond servers to data, applications, SaaS services, endpoints, and connected devices. Personal devices accessing enterprise resources may also need to be considered within the resource inventory.

Example: Inventory customer databases, file stores, cloud administration interfaces, and business APIs. Record ownership, intended users, and information sensitivity.

2. Protect communications regardless of network location

An internal LAN or private network does not automatically make traffic trustworthy. Protect confidentiality and integrity, and authenticate the communicating parties as appropriate.

Example: Evaluate encryption and authentication for internal service traffic as well as internet-facing connections, using mechanisms such as TLS.

3. Grant access for individual sessions

Authorize access to the specific resource with the privileges required for the task. Approval for one resource does not automatically authorize another.

Example: Permission to view customer records does not imply permission to edit, delete, or access an unrelated system.

Session-based authorization does not require users to type a password for every request. SSO can support a design that still evaluates access conditions for each resource.

4. Make decisions using dynamic policies and contextual information

Consider user or service identity, application identity, device condition, behavior, and environmental information. Resource sensitivity and acceptable risk influence the rules.

Example: Access to payroll records requires an appropriate HR role and a managed device with the required updates. Unusual activity can trigger additional authentication or denial.

5. Monitor and assess asset integrity and security posture

A legitimate device can become unsafe. Track configuration, software versions, vulnerabilities, and signs of compromise, and take corrective action.

Example: Restrict access from a device with an unresolved critical vulnerability or suspected infection, then reassess it after remediation.

6. Authenticate and authorize dynamically before granting access

Establish authentication and authorization before access, and reevaluate trust as needed during the session. Changed conditions can require reauthentication or revocation.

Example: Require MFA for sensitive actions and reconsider active access when an account is disabled or a device becomes compromised.

Tenet 4 concerns the information and policy used to decide. Tenet 6 concerns applying and reevaluating authentication and authorization over time.

7. Use collected information to improve security

Collect relevant information about assets, infrastructure, communications, and access requests. Analyze it to refine policies and strengthen protection.

Example: Correlate authentication logs, endpoint alerts, and application access records to identify excessive permissions or abnormal behavior. Investigate unnecessary denials and adjust the rules.

The goal is a feedback loop: collected information should improve decisions and operations.

The logical components of ZTA

Section 3 separates decision-making from enforcement. These are logical roles; they do not necessarily require separate products or servers.

The core: PE, PA, and PEP

Component	Full name	Responsibility	HR application example
PE	Policy Engine	Decides whether to allow, deny, or revoke access using policy and available information	Evaluates the user’s role, device posture, and requested action
PA	Policy Administrator	Manages connection establishment and termination according to the PE’s decision; directs the PEP	Instructs enforcement components to establish an approved session
PEP	Policy Enforcement Point	Enables, monitors, and terminates the connection between a subject and a resource	Enforces access through a gateway, agent, or other control

Together, the PE and PA perform the Policy Decision Point (PDP) role.

A typical interaction works as follows:

A user or service requests access to a resource.
The PE evaluates identity, permissions, device posture, and other information against policy.
The PA directs the PEP to establish or terminate the connection.
The PEP enforces access and monitors the connection.
New risk information can cause the decision to be revisited and the connection to end.

Decision and administration traffic belongs to the control plane. Application data travels on the data plane.

Supporting systems and information sources

Source or capability	Contribution
Continuous Diagnostics and Mitigation (CDM)	Asset configuration, patching, vulnerabilities, and remediation information
Industry compliance information	Policies derived from applicable regulatory and industry requirements
Threat intelligence	Information about attacks, malware, and vulnerabilities
Network and system activity logs	Records of communications, authentication, and resource access
Data access policies	Rules defining permitted subjects, resources, and actions
Public Key Infrastructure (PKI)	Certificates supporting identification of users, devices, and services
Identity management	Accounts, roles, attributes, and assigned access rights
Security Information and Event Management (SIEM)	Security data collection and analysis to inform policy improvements

An identity system might confirm that a user belongs to HR, while endpoint monitoring indicates that the device is compromised. The PE can combine those signals and deny access.

The trust algorithm

The trust algorithm is the PE’s decision process. Inputs include the request, subject and asset attributes, observed behavior, and threat information.

The publication discusses approaches based on meeting defined conditions and approaches using weighted scores. It does not prescribe a universal trust score or calculation for every organization.

Different approaches to implementation

Section 3.1 describes three approaches that can be combined:

Approach	Main emphasis
Enhanced identity governance	Identity, attributes, and permissions as major decision inputs
Micro-segmentation	Controls around individual resources or small groups to limit lateral movement
Network infrastructure and software-defined perimeters	Dynamic control of the communication paths needed for access

Section 3.2 also illustrates device-agent/gateway, enclave gateway, resource portal, and application sandbox deployment patterns.

Choose patterns according to the workflow: whether devices can run agents, whether external users need access, which protocols must be supported, and how resources are hosted.

Deployment scenarios

Section 4 considers organizations with satellite offices, multiple clouds, contractors or other nonemployees, cross-enterprise collaboration, and public or customer-facing services.

Across these scenarios, being inside an enterprise network is insufficient evidence of identity, authorization, or device safety.

Public anonymous services also need different policies from employee-only systems. Design access rules around the service’s purpose, distinguishing public resources from protected ones.

Risks that remain

Section 5 explains that ZTA does not eliminate security risk.

Risk	Design and operational consideration
Compromised or misconfigured decision components	Protect PE and PA administration, audit changes, and review policy configuration
Denial of service and network disruption	Design for availability and recovery because access depends on decision and connection-management services
Stolen credentials and insider misuse	Maintain least privilege and behavior monitoring; authorized actions can still be abused
Limited visibility	Encrypted traffic and unmanaged devices can reduce available evidence; use metadata and other detection sources
Disclosure of monitoring information	Protect logs and configuration data, which can reveal valuable details to attackers
Proprietary formats and solutions	Assess interoperability, migration costs, and dependency on vendors
Misuse of automated management entities	Protect service credentials and constrain the privileges of agents and management APIs

Section 6 discusses relationships with existing risk management, privacy, identity, and other federal guidance. Improving access control still requires wider governance and resilience practices.

A gradual migration roadmap

Section 7 recommends incremental migration by workflow. Existing perimeter controls and ZTA can coexist in a hybrid environment.

Step	Action	Useful information to establish
1. Identify actors	Discover users, administrators, contractors, and service accounts	Identities, roles, privileges, and purposes
2. Identify assets	Inventory devices, applications, cloud resources, and data	Ownership, configuration, posture, and unmanaged assets
3. Evaluate processes and risks	Map workflows, data flows, and dependencies	Business importance, disruption risk, and pilot candidates
4. Formulate policies	Define conditions for access to the selected workflow	Subjects, resources, actions, and device requirements
5. Select solutions	Compare implementation options	Agent requirements, logging, protocol support, and workflow impact
6. Deploy and monitor	Pilot policies and examine their effects	Incorrect approvals or denials, performance, and user impact
7. Refine and expand	Improve policies and introduce additional workflows	Ongoing monitoring, change-driven reassessment, and next candidates

For an initial pilot, the document recommends an observation and reporting phase. This does not mean allowing failed authentication or clearly malicious requests.

Select a pilot by considering migration risk and learning opportunities alongside business importance. Experience from a manageable workflow can support later deployment to more critical processes.

Applying the guidance

SP 800-207 gives organizations a way to reason about access decisions, enforcement, and improvement.

Start by establishing who or what needs access to which resources and why. Combine minimum necessary privileges with protected communications, posture assessment, ongoing reevaluation, and useful monitoring.

MFA and network segmentation can support this architecture. Their value depends on how they fit into the access policies and operational processes of the business.

References

The main basis for this article is NIST SP 800-207, particularly Section 2.1 and Sections 3–7. Its Japanese translation by PwC Consulting LLC was also consulted.

Further explanatory reading: