NIST Zero Trust Architecture: A Practical Guide

Shift changes on a plant floor move fast. One worker leaves a line terminal logged in, the next worker picks up where they left off, and every action after that can be attributed to the wrong person. Nobody questions it until an audit turns up changes that don't match the shift roster.

That mismatch between who acted and who the system believes acted explains why so many zero trust programs stall halfway. A Gartner survey found that 63% of organizations have fully or partially implemented a zero trust strategy, but for most respondents, the strategy covered half or less of their environment.

NIST zero trust architecture gives security teams a vendor-neutral model to close that gap. It evaluates every access request using identity, device health, and context, and it grants no user or device default trust based on network location or ownership. NIST defined the Zero Trust Architecture model in SP 800-207 and subsequently documented implementation examples in SP 1800-35 through the NCCoE's collaborative builds.

This guide covers how the two publications fit together, how the reference model makes decisions, what NIST's own builds revealed, and where shared-device environments need extra attention.

SP 800-207 vs SP 1800-35: The Concept and the Playbook

What SP 800-207 Defines

Published in 2020, SP 800-207 lays the conceptual foundation of NIST zero trust architecture. It sets out seven tenets: treat every data source and service as a resource, secure all communication regardless of location, grant access per session, decide access through dynamic policy, monitor the posture of all assets, enforce authentication and authorization dynamically before access, and collect telemetry to improve over time. CISA

It also describes the deployment models and three approaches that any NIST zero trust architecture can follow: enhanced identity governance (EIG), microsegmentation, and software-defined perimeters (SDP).

What SP 1800-35 Adds

SP 1800-35 turns those principles into tested blueprints. The NIST National Cybersecurity Center of Excellence (NCCoE) worked with 24 collaborators to develop 19 example implementations using commercially available technologies, covering EIG, SDP, microsegmentation, and secure access service edge (SASE). nist

The guide also introduces maturity phases. The Crawl phase protects on-premises resources only, while the Run phase extends coverage to cloud resources. Read SP 800-207 to understand the model, then use SP 1800-35 to plan how you build it.

The NIST Zero Trust Architecture Reference Model, Simplified

NIST SP 800-207 defines a common set of logical components that can be used to describe a zero trust architecture, regardless of the specific products deployed.

‍

The Policy Engine and Policy Administrator together make up the Policy Decision Point (PDP). The PDP determines and executes access decisions, while the Policy Enforcement Point (PEP) enforces those decisions between the subject and resource.

How Trust Decisions Are Made

The Signals That Feed the Policy Engine

The Policy Engine in a NIST zero trust architecture only decides as well as its inputs allow. Common signals include:

• Identity assurance: how strongly the user proved who they are
• Device posture: managed status, patch level, EDR presence
• Behavior: unusual access times, impossible travel, abnormal resource requests
• Resource sensitivity: data classification and business criticality
• Threat intelligence: known malicious IPs, domains, or attacker techniques

Criteria-Based vs Score-Based Decisions

Criteria-based logic grants access only when every condition passes, such as phishing-resistant authentication plus a compliant device. Score-based logic weighs signals into a confidence score and sets thresholds by resource sensitivity. Most mature programs combine both: hard criteria for critical systems and scoring for everything else.

Why Identity Assurance Is the Weakest Link in NIST Zero Trust Architecture

Authentication Strength as a Trust Signal

Every tenet of NIST zero trust architecture assumes the Policy Engine knows who is asking. That confidence depends on how the user authenticated. NIST SP 800-63-4, finalized in 2025, requires systems at Authentication Assurance Level 2 (AAL2) to offer a phishing-resistant option and requires a phishing-resistant authenticator with a non-exportable key at AAL3. wwpass

A password-based login feeds the Policy Engine a weak identity signal, and no amount of device telemetry compensates for it.

Why Authentication Method Matters in Zero Trust

Not all MFA methods provide the same level of phishing resistance or authentication assurance. SMS codes and some push-based workflows can remain vulnerable to phishing and social-engineering techniques. In shared-device environments, another challenge emerges: authentication tied to a personal phone may be impractical when workers do not carry phones or cannot use them on the floor.

The Blind Spot in NIST Zero Trust Architecture: Shared Devices and Frontline Workers

When One Device Serves Many Users

NIST's reference model treats the subject and the endpoint as distinct elements of an access request, allowing information about both to contribute to the access decision. This distinction becomes harder to operationalize when many workers use the same physical endpoint. On a nursing station, factory HMI, warehouse scanner, or POS terminal, the endpoint passes every posture check while the user behind it changes every few hours.

In these settings, a NIST zero trust architecture can report a healthy, compliant session that belongs to the wrong person. Device posture provides evidence about the endpoint. Strong user authentication provides additional evidence about the person requesting access.

Enforcing Continuous Verification Between User Sessions

Shared-device environments need three controls at the PEP:

• Fast, individual authentication at every handoff, with an experience designed for high-frequency shift changes
• Automatic session termination or lock when a user walks away
• Per-user audit trails that associate actions with an authenticated user

OLOID addresses this use case with passwordless authentication methods including face authentication, badge tap, and PIN, enabling individual authentication at shared devices and shift handoffs.

What the NCCoE Builds Revealed

NIST's General Findings offer the most practical lessons for any NIST zero trust architecture rollout:

• Integration gaps are common. Many products did not integrate out of the box in the ways needed for identity solutions to act as decision points, and network-level PEPs such as routers and firewalls typically did not integrate directly with identity systems. NIST
• Policy fragments across tools. Multiple PDPs manage their own policies and rarely share risk data, so one may know a device is noncompliant while another does not. NIST
• Early builds missed the resource side. The Crawl builds verified the requesting user and endpoint but did not verify the identity or health of the endpoint hosting the resource. NIST
• Reauthentication is fundamental. NIST lists periodic reauthentication of the user, requesting endpoint, and resource-hosting endpoint as core capabilities. NIST

Plan budget and time for custom integration, and prioritize identity sources that share signals through open standards.

A Phased Roadmap to NIST-Aligned Zero Trust

Zero trust programs typically evolve incrementally rather than being deployed all at once. SP 1800-35 provides implementation examples that can inform a phased approach.

Crawl: Inventory, Identity, and Protected Surfaces

• Inventory resources, users, and devices, including shared terminals and frontline roles that usually fall outside the identity program
• Replace shared and generic accounts with individual identities
• Deploy phishing-resistant or passwordless authentication, starting with high-risk and high-traffic access points
• Define protected surfaces and default-deny access policies

Run: Extending Enforcement Across Cloud, On-Prem, and Shared Endpoints

• Extend PEPs to cloud and SaaS resources
• Match deployment models to environments: agent and gateway for managed laptops, resource portals for unmanaged or partner devices, and enclaves for legacy OT systems
• Connect endpoint, identity, and analytics signals so PDPs share one view of risk
• Enforce session re-evaluation and termination when signals change

Addressing the Shared-Device Identity Gap

Many zero trust programs begin with managed endpoints and workforce identities, while shared-device and frontline environments can require additional authentication and session-management controls. That leaves the largest, most operationally critical user group feeding the weakest signals into the Policy Engine.

OLOID addresses this gap by providing individual authentication for shift-based teams using shared devices. It integrates with existing identity providers such as Okta and Microsoft Entra ID, so authentication events from shared devices can be incorporated into the identity and access signals used by the organization's access-control architecture.

FAQs

1. What is NIST zero trust architecture?

It is a security model defined in NIST SP 800-207 that removes implicit trust and evaluates every access request using identity, device posture, and context before granting per-session access to a resource.

2. What are the seven tenets of zero trust in NIST SP 800-207?

Treat all data and services as resources, secure all communication, grant access per session, use dynamic policy, monitor asset posture, enforce authentication and authorization dynamically, and collect telemetry to improve security.

3. Is NIST SP 800-207 mandatory?

No. NIST SP 800-207 is guidance rather than a certification standard. Federal agencies may be required to follow related federal zero trust requirements and policies, while private organizations can use SP 800-207 as a reference architecture and planning framework.

4. What is the difference between NIST SP 800-207 and SP 1800-35?

SP 800-207 explains the zero trust concepts and architecture. SP 1800-35 shows how to implement them, using 19 example builds created with commercial technologies.

5. What are the main components of a zero trust architecture?

The Policy Engine decides access, the Policy Administrator executes the decision, and the Policy Enforcement Point enforces it. Policy Information Points supply identity, device, and threat data to inform each decision.

6. What is the difference between NIST Zero Trust Architecture and zero trust?

Zero trust is a security approach based on eliminating implicit trust and continuously evaluating access. NIST SP 800-207 provides a specific architecture and set of principles for implementing zero trust, including its logical components, deployment models, and access-decision process.

7. How does zero trust work with shared devices?

Zero trust can be applied to shared devices by evaluating the identity of the current user separately from the security posture of the endpoint. Organizations can combine individual authentication, device signals, session controls, and audit trails to ensure that access decisions and activity records reflect the person currently using the device.