What SP 1800-35 Adds to the Zero Trust Canon
NIST’s SP 1800-35, “Implementing a Zero Trust Architecture (ZTA),” is the latest in the agency’s ongoing effort to move Zero Trust from theory to practice. Where the foundational SP 800-207 laid out the conceptual model, this new publication provides a reference architecture plus a set of “Builds” that show how specific products from multiple vendors can be assembled into a working ZTA that conforms to that architecture.
The publication’s definition of Zero Trust is worth restating:
A zero-trust architecture (ZTA) enables secure authorized access to assets — machines, applications and services running on them, and associated data and resources — whether located on-premises or in the cloud, for a hybrid workforce and partners based on an organization’s defined access policy.
Zero Trust as a Set of Logical Components
Like SP 800-207, SP 1800-35 defines two key actors: the Subject, an entity such as an employee or device that needs access, and the Resource, which can be a computer, database, server, or application. The architecture concentrates on the enhanced identity governance (EIG) approach to ZTA, which bases access decisions primarily on identity and assigned attributes.
The EIG model is explicit about how access decisions are made:
For [the EIG] approach, enterprise resource access policies are based on identity and assigned attributes. The primary requirement for [R]esource access is based on the access privileges granted to the given [S]ubject. Other factors such as device used, asset status, and environmental factors may alter the final confidence level calculation … or tailor the result in some way, such as granting only partial access to a given [Resource] based on network location.
Other ZTA approaches from SP 800-207 are set aside because SP 1800-35 concentrates on EIG. In this model, each logical component in the reference architecture does not necessarily map to a specific physical product; rather, a component describes a required function, and one vendor's offering might cover several components.
The Core Components of the Architecture
Policy is the thread that ties the whole architecture together. A ZTA exists to enforce rules about who may access what, when, and under what conditions. The main logical components are:
- Policy Enforcement Point (PEP): This component protects the “trust zones” that host enterprise Resources. It enables, monitors, and eventually terminates connections between Subjects and Resources; it is effectively the dataplane that supports access.
The Policy Decision Point (PDP) is the decision-making engine that sits behind access requests.
|
Policy Enforcement Point |
The PEP protects the “trust zones” that host enterprise Resources, and handles enabling, monitoring, and eventually terminating connections between Subjects and Resources. You can think of the PEP as the dataplane that supports the Subject’s access to the Resources. |
|
Policy Engine (PE) |
The PE handles the ultimate decision to grant, deny, or revoke access to a Resource for a given Subject, and calculates the trust scores/confidence levels and ultimate access decisions based on enterprise policy and information from supporting components. |
|
Policy Administrator (PA) |
The PA executes the PE’s policy decision by sending commands to the PEP to establish and terminate the communications path between the Subject and the Resource. |
|
Policy Decision Point (PDP) |
The PDP is where the decision as to whether or not to permit a Subject to access a Resource is made. The PIP included the Policy Engine (PE) and the Policy Administrator (PA). You can think of the PDP as the control plane that controls the Subject’s access to the Resources. |
|
Policy Information Point (PIP) |
The PIPs provide various types of telemetry and other information needed for the PDP to make informed access decisions. Some PIPs include:
NIST’s figure might suggest that supporting components in the PIP are mere plug-ins responding in real-time to the PDP. However, for many vendors, the ICAM, EDR/EPP, security analytics, and data security PIPs often represent complex and distributed infrastructures. |
The PDP receives inputs from Policy Information Points (PIPs), the supporting components that supply critical data and policy rules to the PDP.
Crawl and Run Phases
SP 1800-35 defines two deployment scenarios. The Run Phase is the full reference architecture covering both on-premises and cloud Resources. The Crawl Phase is a simplified variant that deals only with on-premises Resources and omits cloud Resources. Both apply the EIG approach. NIST has said of the phases: “We are skipping the EIG walk phase and have proceeded directly to the run phase.”
The publication proceeds through the Builds — detailed sequences of instructions — that demonstrate how to implement each phase using products from various vendors. Because support for cloud and on-premises resources is native to many modern Zero Trust platforms, the practical value of the document is in the Run Phase guidance and in how vendor products can be combined to match the reference architecture’s logical components.
Cloudflare’s Platform as a Policy Engine
NIST SP 1800-35 does not endorse specific vendors. Instead, it defines a general architecture that applies regardless of technology choices. The publication includes several “Builds” using different vendors’ products to demonstrate how organizations can implement a Zero Trust Architecture (ZTA). Cloudflare positions its platform as a practical way to consolidate three of those Builds—specifically:
- E1B3: Software-Defined Perimeter (SDP) with Cloudflare as the Policy Engine (PE).
- E2B4: SDP and Secure Access Service Edge (SASE) with Cloudflare Secure Web Gateway, Cloudflare Zero Trust Network Access (ZTNA), and Cloudflare Cloud Access Security Broker as PEs.
- E3B5: SDP and SASE with Microsoft Entra Conditional Access and Cloudflare Zero Trust as PEs.
Figure 2: General ZTA Reference Architecture Mapped to Cloudflare Zero Trust & Key Integrations. Source: NIST, Special Publication 1800-35, "Implementing a Zero Trust Architecture (ZTA)”, 2025, with modification by Cloudflare.
Cloudflare simplifies the architecture by delivering the Policy Enforcement Point (PEP) via its anycast network and the Policy Decision Point (PDP) through its SaaS management console, which acts as a unified control plane. A complete ZTA, however, requires integrating Cloudflare with Policy Information Points (PIPs) supplied by other vendors.
Where Resources and Subjects Sit
In the reference model, Resources can be on-premise, in private data centers, or spread across multiple clouds. Cloudflare makes these resources accessible through its anycast network via Cloudflare Tunnel or Magic WAN, while shielding them from direct Internet exposure. Cloudflare Access and Cloudflare Gateway act as the PEPs that enforce zero-trust policies, granting access only when policies are satisfied.
Subjects—human or non-human—connect through Cloudflare using either agentless or agent-based paths:
- Agentless: End users reach resources directly from web browsers. Alternatively, Magic WAN connects enterprise networks to Cloudflare via IPsec tunnels, GRE tunnels, or Cloudflare Network Interconnect (CNI).
- Agent-based: The lightweight WARP client protects corporate devices by securely sending traffic to Cloudflare's network.
Policy Enforcement and Decision
Cloudflare Access is the dynamic PEP for user-specific application policies, making decisions based on identity, device posture, and context. Cloudflare Gateway is a Secure Web Gateway that serves as a PEP for traffic destined for the public Internet, handling DNS, HTTP, and network-level filtering, along with egress IP policies.
Both products rely on Cloudflare’s control plane, which functions as the PDP and contains the PE and Policy Administrator (PA). This PDP consumes inputs from vendor integrations serving as PIPs. Key integration categories:
- ICAM: The control plane integrates with providers offering Single Sign-On (SSO) and Multi-Factor Authentication (MFA). The provider authenticates human users and shares identity and group data with Cloudflare via Security Assertion Markup Language (SAML) or OpenID Connect (OIDC). Supported vendors include Okta, Microsoft Entra, JumpCloud, GitHub SSO, and PingOne. Non-human subjects—service accounts, IoT devices, machine identities—can authenticate via certificates, service tokens, or other cryptographic methods.
- Endpoint security: Cloudflare exchanges posture and risk signals with endpoint detection and response (EDR/EPP) tools such as CrowdStrike, Microsoft, and SentinelOne. For example, a device state change to
noncompliantcan automatically restrict access. Synchronizing the Microsoft Entra ID risky users list allows applying stricter policies to higher-risk users. - Security analytics: Cloudflare logs access requests and security events, with optional forwarding via logpush to SIEM solutions like CrowdStrike, Datadog, IBM QRadar, Microsoft Sentinel, New Relic, and Splunk. Its user risk scoring system is based on the OpenID Shared Signals Framework (SSF) specification, which uses Security Event Tokens (SETs)—a specialized JSON Web Token (JWT)—to exchange risk information. This system functions as a PIP that gathers context about the subject, feeds it to the PDP, and enables the PEP to enforce dynamic access decisions.
- Data security: Cloudflare covers data in transit with Data Loss Prevention (DLP), data in use with Remote Browser Isolation (RBI), and data at rest with its Cloud Access Security Broker (CASB) for SaaS applications. These tools collectively prevent unauthorized movement, exfiltration, and leakage.
By mapping its platform to the NIST reference architecture, Cloudflare lets enterprises adopt a ZTA without deploying custom infrastructure, ensuring consistent policy enforcement across users, devices, and resources regardless of location.
What NIST’s SP 1800-35 Means for Deployment
NIST’s SP 1800-35 gives agencies and enterprises a practical blueprint for moving from legacy perimeter security to a Zero Trust architecture. The guidance emphasizes policy enforcement, continuous authentication, and secure access management — but turning those pillars into a working deployment still requires decisions about infrastructure and cryptography that the reference architecture does not make for you.
One of the biggest operational questions is where to put the Policy Enforcement Point (PEP). Many organizations with FedRAMP obligations have historically self-hosted enforcement software inside their own network perimeter. That approach can introduce latency, performance degradation, and higher operational cost. An alternative is to rely on a cloud provider that separates the dataplane from compliance-sensitive processing. In that model, encrypted traffic is handled across a broad global network, while only specific operations such as TLS inspection are routed to FedRAMP-compliant data centers. This keeps organizations compliant without forcing them to operate their own PEP infrastructure.
The Cryptography Clock Is Ticking
NIST has signaled that by 2030, conventional cryptography — RSA and ECDSA — must be deprecated in favor of post-quantum algorithms. Upgrading cryptographic standards is rarely a single-event migration; it touches every application, system, and network connection an organization operates. That burden is significant for enterprises running thousands of endpoints.
One way to reduce the scope of that work is to centralize the cryptographic upgrade at the network layer rather than at each individual asset. Organizations can tunnel corporate traffic through a Zero Trust platform that handles post-quantum protections end-to-end. In this setup, communications from end-user devices reach secured applications via a tunnel, with quantum-safe encryption applied at both ends. This approach shields existing infrastructure from quantum adversaries while avoiding the need to retrofit each application individually.
Measuring the Enforcement Infrastructure
Zero Trust enforcement only works if it can be applied consistently, close to the user, without introducing noticeable delay. Backhauling traffic through centralized choke points undermines both performance and the security model itself. A globally distributed anycast network can enforce access policy, data protection, and security analytics at the edge, in proximity to the user, rather than at a single regional hub.
For a platform such as Cloudflare’s, this means:
- Global footprint: Enforcement points in over 330 cities across 120+ countries, allowing policies to be applied without backhauling user traffic.
- Compliance-ready architecture: 32 FedRAMP data centers handle sensitive operations like TLS inspection, while the broader network carries encrypted traffic — avoiding the need for customers to self-host a PEP.
- Post-quantum readiness: End-to-end quantum-safe communications are available today from web browsers, with WARP device client support planned for mid-2025.
- Ecosystem integration: The platform integrates with identity and security providers such as Okta, Microsoft, Ping, CrowdStrike, and SentinelOne.
For organizations mapping their deployment to NIST SP 1800-35, the practical takeaway is to prioritize where policy is enforced and how cryptographic transitions are managed. The guidance provides the framework; execution depends on aligning network architecture, compliance requirements, and the timeline for deprecating legacy cryptography.
