Everything you need to know about NIST’s new guidance in “SP 1800-35: Implementing a Zero Trust Architecture”
For decades, the United States National Institute of Standards and Technology (NIST) has been guiding industry efforts through the many publications in its Computer Security Resource Center. NIST has played an especially important role in the adoption of Zero Trust architecture, through its series of publications that began with NIST SP 800-207: Zero Trust Architecture, released in 2020.
NIST has released another Special Publication in this series, SP 1800-35, titled "Implementing a Zero Trust Architecture (ZTA)" which aims to provide practical steps and best practices for deploying ZTA across various environments. NIST’s publications about ZTA have been extremely influential across the industry, but are often lengthy and highly detailed, so this blog provides a short and easier-to-read summary of NIST’s latest guidance on ZTA.
And so, in this blog post:
We summarize the key items you need to know about this new NIST publication, which presents a reference architecture for Zero Trust Architecture (ZTA) along with a series of “Builds” that demonstrate how different products from various vendors can be combined to construct a ZTA that complies with the reference architecture.
We show how Cloudflare’s Zero Trust product suite can be integrated with offerings from other vendors to support a Zero Trust Architecture that maps to the NIST’s reference architecture.
We highlight a few key features of Cloudflare’s Zero Trust platform that are especially valuable to customers seeking compliance with NIST’s ZTA reference architecture, including compliance with FedRAMP and new post-quantum cryptography standards.
Let’s dive into NIST’s special publication!
The PDP operates on inputs from Policy Information Points (PIPs) which are supporting components that provide critical data and policy rules to the Policy Decision Point (PDP).
|
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. |
Crawl or run, but don’t walk
</a>
</div>
<p>Next, the <a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-35.pdf"><u>SP 1800-35</u></a> introduces two more detailed reference architectures, the “Crawl Phase” and the “Run Phase”. The “Run Phase” corresponds to the reference architecture that is shown in the figure above. The “Crawl Phase” is a simplified version of this reference architecture that only deals with protecting on-premise Resources, and omits cloud Resources. Both of these phases focused on Enhanced Identity Governance approaches to ZTA, as we defined above. <a href="https://www.nccoe.nist.gov/sites/default/files/2024-11/zta-nist-sp-1800-35-ipd.pdf"><u>NIST stated</u></a>, "<i>We are skipping the EIG walk phase and have proceeded directly to the run phase</i>".</p><p>The <a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-35.pdf"><u>SP 1800-35</u></a> then provides a sequence of detailed instructions, called “Builds”, that show how to implement “Crawl Phase” and “Run Phase” reference architectures using products sold by various vendors.</p><p>Since Cloudflare’s Zero Trust platform natively supports access to both cloud and on-premise resources, we will skip over the “Crawl Phase” and move directly to showing how Cloudflare’s Zero Trust platform can be used to support “Run Phase” of the reference architecture.</p>
<div>
<h2>A complete Zero Trust Architecture using Cloudflare and integrations</h2>
<a href="#a-complete-zero-trust-architecture-using-cloudflare-and-integrations">
</a>
</div>
<p>Nothing in NIST SP 1800-35 represents an endorsement of specific vendor technologies. Instead, the intent of the publication is to offer a general architecture that applies regardless of the technologies or vendors an organization chooses to deploy. It also includes a series of “Builds” using a variety of technologies from different vendors, that allow organizations to achieve a ZTA. This section describes how Cloudflare fits in with a ZTA, enabling you to accelerate your ZTA deployment from Crawl directly to Run.</p><p>Regarding the “Builds” in SP 1800-35, this section can be viewed as an aggregation of the following three specific builds:</p><ul><li><p><a href="https://pages.nist.gov/zero-trust-architecture/VolumeB/appendices/Appendix-E1B3.html#enterprise-1-build-3-e1b3-sdp-zscaler-zpa-ca-as-pe"><u>Enterprise 1 Build 3 (E1B3)</u></a>: Software-Defined Perimeter (SDP) with Cloudflare as the Policy Engine (PE).</p></li><li><p><a href="https://pages.nist.gov/zero-trust-architecture/VolumeB/appendices/Appendix-E2B4.html#enterprise-2-build-4-e2b4-sdp-and-sase-symantec-cloud-secure-web-gateway-symantec-ztna-and-symantec-cloud-access-security-broker-as-pes"><u>Enterprise 2 Build 4 (E2B4)</u></a>: 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.</p></li><li><p><a href="https://pages.nist.gov/zero-trust-architecture/VolumeB/appendices/Appendix-E3B5.html#enterprise-3-build-5-e3b5-sdp-and-sase-microsoft-entra-conditional-access-formerly-called-azure-ad-conditional-access-and-microsoft-security-service-edge-as-pes"><u>Enterprise 3 Build 5 (E3B5)</u></a>: SDP and SASE with Microsoft Entra Conditional Access (formerly known as Azure AD Conditional Access) and Cloudflare Zero Trust as PEs.</p></li></ul><p>Now let’s see how we can map Cloudflare’s Zero Trust platform to the ZTA reference architecture:</p>
<figure>
<img src="https://cf-assets.www.cloudflare.com/zkvhlag99gkb/677H4TOcuuJQuQF51jgP5S/4c21589a9c61571182241e2255308b08/image3.png" />
</figure><p><sup><i>Figure 2: General ZTA Reference Architecture Mapped to Cloudflare Zero Trust & Key Integrations. Source: NIST, </i></sup><a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-35.pdf"><sup><i><u>Special Publication 1800-35</u></i></sup></a><sup><i>, "Implementing a Zero Trust Architecture (ZTA)”, 2025, with modification by Cloudflare.</i></sup></p><p>Cloudflare’s platform simplifies complexity by delivering the PEP via our global anycast network and the PDP via our Software-as-a-Service (SaaS) management console, which also serves as a global unified control plane. A complete ZTA involves integrating Cloudflare with PIPs provided by other vendors, as shown in the figure above.</p><p>Now let’s look at several key points in the figure.</p><p>In the bottom right corner of the figure are Resources, which may reside on-premise, in private data centers, or across multiple cloud environments. Resources are made securely accessible through Cloudflare’s global anycast network via <a href="https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/"><u>Cloudflare Tunnel</u></a> (as shown in the figure) or <a href="https://developers.cloudflare.com/magic-wan/"><u>Magic WAN</u></a> (not shown). Resources are shielded from direct exposure to the public Internet by placing them behind <a href="https://www.cloudflare.com/en-au/zero-trust/products/access/"><u>Cloudflare Access</u></a> and <a href="https://www.cloudflare.com/en-au/zero-trust/products/gateway/"><u>Cloudflare Gateway</u></a>, which are PEPs that enforce zero-trust principles by granting access to Subjects that conform to policy requirements.</p><p>In the bottom left corner of the figure are Subjects, both human and non-human, that need access to Resources. With Cloudflare’s platform, there are multiple ways that Subjects can again access to Resources, including:</p><ul><li><p>Agentless approaches that allow end users to access Resources directly from their <a href="https://developers.cloudflare.com/learning-paths/zero-trust-web-access/concepts/"><u>web browsers</u></a>. Alternatively, Cloudflare’s <a href="https://developers.cloudflare.com/magic-wan/"><u>Magic WAN</u></a> can be used to support connections from enterprise networks directly to Cloudflare’s global anycast network via <a href="https://developers.cloudflare.com/magic-wan/reference/tunnels/"><u>IPsec tunnels, GRE tunnels</u></a> or <a href="https://developers.cloudflare.com/magic-wan/network-interconnect/"><u>Cloudflare Network Interconnect (CNI)</u></a>.</p></li><li><p>Agent-based approaches use Cloudflare’s lightweight <a href="https://developers.cloudflare.com/cloudflare-one/connections/connect-devices/warp/"><u>WARP client</u></a>, which protects corporate devices by securely and privately sending traffic to Cloudflare's global network.</p></li></ul><p>Now we move onto the PEP (the Policy Enforcement Point), which is the dataplane of our ZTA. Cloudflare Access is a modern Zero Trust Network Access solution that serves as a dynamic PEP, enforcing user-specific application access policies based on identity, device posture, context, and other factors. Cloudflare Gateway is a Secure Web Gateway for filtering and inspecting traffic sent to the public Internet, serving as a dynamic PEP that provides DNS, HTTP and network traffic filtering, DNS resolver policies, and egress IP policies.</p><p>Both Cloudflare Access and Cloudflare Gateway rely on Cloudflare’s control plane, which acts as a PDP offering a policy engine (PE) and policy administrator (PA). This PDP takes in inputs from PIPs provided by integrations with other vendors for ICAM, endpoint security, and security analytics. Let’s dig into some of these integrations.</p><ul><li><p><b>ICAM: </b>Cloudflare’s control plane integrates with many ICAM providers that provide Single Sign On (SSO) and Multi-Factor Authentication (MFA). The ICAM provider authenticates human Subjects and passes information about authenticated users and groups back to Cloudflare’s control plane using <a href="https://www.cloudflare.com/learning/access-management/what-is-saml/"><u>Security Assertion Markup Language (SAML)</u></a> or <a href="https://openid.net/developers/how-connect-works/"><u>OpenID Connect (OIDC)</u></a> integrations. Cloudflare’s ICAM integration also supports AI/ML powered <a href="https://blog.cloudflare.com/protect-against-identity-based-attacks-by-sharing-cloudflare-user-risk-with-okta/"><u>behavior-based user risk scoring</u></a>, exchange, and re-evaluation.
In the figure above, we depicted Okta as the ICAM provider, but Cloudflare supports many other ICAM vendors (e.g. Microsoft Entra, Jumpcloud, GitHub SSO, PingOne). For non-human Subjects — such as service accounts, Internet of Things (IoT) devices, or machine identities — authentication can be performed through certificates, service tokens, or other cryptographic methods.
Endpoint security: Cloudflare’s control plane integrates with many endpoint security providers to exchange signals, such as device posture checks and user risk levels. Cloudflare facilitates this through integrations with endpoint detection and response EDR/EPP solutions, such as CrowdStrike, Microsoft, SentinelOne, and more. When posture checks are enabled with one of these vendors such as Microsoft, device state changes, ‘noncompliant’, can be sent to Cloudflare Zero Trust, automatically restricting access to Resources. Additionally, Cloudflare Zero Trust enables the ability to synchronize the Microsoft Entra ID risky users list and apply more stringent Zero Trust policies to users at higher risk.
Security Analytics: Cloudflare’s control plane integrates with real-time logging and analytics for persistent monitoring. Cloudflare’s own analytics and logging features monitor access requests and security events. Optionally, these events can be sent to a Security Information and Event Management (SIEM) solution such as, CrowdStrike, Datadog, IBM QRadar, Microsoft Sentinel, New Relic, Splunk, and more using Cloudflare’s logpush integration.
Cloudflare’s user risk scoring system is built on the OpenID Shared Signals Framework (SSF) Specification, which allows integration with existing and future providers that support this standard. SSF focuses on the exchange of Security Event Tokens (SETs), a specialized type of JSON Web Token (JWT). By using SETs, providers can share user risk information, creating a network of real-time, shared security intelligence. In the context of NIST’s Zero Trust Architecture, this system functions as a PIP, which is responsible for gathering information about the Subject and their context, such as risk scores, device posture, or threat intelligence. This information is then provided to the PDP, which evaluates access requests and determines the appropriate policy actions. The PEP uses these decisions to allow or deny access, completing the cycle of secure, dynamic access control.
Data security: Cloudflare’s Zero Trust offering provides robust data security capabilities across data-in-transit, data-in-use, and data-at-rest. Its Data Loss Prevention (DLP) safeguards sensitive information in transit by inspecting and blocking unauthorized data movement. Remote Browser Isolation (RBI) protects data-in-use by preventing malware, phishing, and unauthorized exfiltration while enabling secure web access. Meanwhile, Cloud Access Security Broker (CASB) ensures data-at-rest security by enforcing granular controls over SaaS applications, preventing unauthorized access and data leakage. Together, these capabilities provide comprehensive protection for modern enterprises operating in a cloud-first environment.
By leveraging Cloudflare’s Zero Trust platform, enterprises can simplify and enhance their ZTA implementation, securing diverse environments and endpoints while ensuring scalability and ease of deployment. This approach ensures that all access requests—regardless of where the Subjects or Resources are located—adhere to robust security policies, reducing risks and improving compliance with modern security standards.