NIST SP 800-207 tells you what a zero trust architecture is; NIST SP 1800-35 shows what happened when 24 technology companies tried to build one in a lab, including what did not integrate. Published as final on 10 June 2025 by NIST's National Cybersecurity Center of Excellence (NCCoE), SP 1800-35 "Implementing a Zero Trust Architecture" documents 19 example implementations built from commercial products, demonstrated against a common set of use cases, with lessons learned and mappings to NIST frameworks. Practitioners use it as a set of reference designs and as evidence of where products still fall short. This guide explains its structure, the deployment approaches and builds, what it says about identity and non-human subjects, how to use it in your own programme and where it maps to other frameworks. It assumes familiarity with the concepts in the NIST SP 800-207 Zero Trust Architecture Guide.
Key takeaways
- It is a practice guide, not a requirement. SP 1800-35 is guidance from NCCoE: it demonstrates how commercially available technology can implement SP 800-207, and it imposes no obligations on anyone.
- Nineteen builds, four approaches. The builds cover enhanced identity governance (EIG) in crawl and run phases, software-defined perimeter (SDP), microsegmentation and secure access service edge (SASE), often combined.
- Identity is the foundation. The guide's first finding is that every build depends on authenticating and reauthorising users, requesting endpoints and resource-hosting endpoints, with endpoint health verification highly desirable.
- Integration is the hard part. The lessons repeatedly cite products that could not act as a policy decision point out of the box, one-way integrations, and multiple PDPs that do not share risk information.
- Use the scenarios as your test plan. The use cases, from discovery through federated access, step-up and confidence-level changes, give a ready-made acceptance test set for your own design.
What it is and who it applies to
| Item | Detail (as published, checked 27 October 2026) |
|---|---|
| Full title | NIST SP 1800-35, Implementing a Zero Trust Architecture |
| Publisher | NIST National Cybersecurity Center of Excellence |
| Status | Final, 10 June 2025, after preliminary drafts published between August 2022 and December 2024 |
| Formats | A high-level PDF summarising goals, architecture, implementations and findings, and a full web-format document with technologies, integrations, configurations and use cases |
| Builds | 19 example implementations |
| Collaborators | 24 vendors and integrators under Cooperative Research and Development Agreements |
| Scope | Conventional enterprise IT, on premises and in the cloud, including remote and branch users |
| Framework mappings | NIST CSF (1.1 and 2.0), NIST SP 800-53 Rev. 5 and NIST's critical software security measures |
It applies to anyone designing or buying zero trust capabilities: US federal agencies aligning with zero trust mandates use it, but it is equally useful to private-sector architects because it is vendor-diverse and documents real integration results. It does not rank products, and inclusion of a product in a build is not an endorsement.
How it differs from SP 800-207
- Abstraction level: SP 800-207 defines tenets, logical components and deployment models in product-neutral terms. SP 1800-35 names the products used in each build and records how they were configured and integrated.
- Evidence of gaps: SP 800-207 describes an ideal; SP 1800-35 reports where commercial products could not yet play a role, which is more useful when writing requirements or planning a proof of concept.
- Testability: SP 1800-35 adds a structured set of use cases and scenarios with expected outcomes, which SP 800-207 does not provide.
- Change over time: the builds reflect products as tested in the lab during the project. Product names and capabilities change, so treat build details as a snapshot and confirm current features with vendors' own documentation.
Structure and key requirements
Reference architecture
- Core components: the Policy Engine (PE), Policy Administrator (PA) and Policy Enforcement Point (PEP), with the PE and PA together forming the Policy Decision Point (PDP), as in SP 800-207.
- Supporting components: identity, credential and access management (ICAM), endpoint security (EDR and EPP), security analytics, data security and resource protection, which act as policy information points feeding the PDP.
- Three processes: resource management, session initiation (a five-step sequence) and session management, so access is evaluated at the start and throughout a session.
Deployment approaches and builds
| Approach | What it means in the guide | Builds (examples) |
|---|---|---|
| EIG crawl | On-premises resources only; ICAM, endpoint security and a SIEM; ICAM products act as the PDP | E1B1, E2B1, E3B1 |
| EIG run | Adds cloud resources, a separate PDP, device discovery and tunnelling | E1B2, E3B2, E4B3 |
| SDP | Access reconfigured per decision, often through an agent-to-gateway secure channel | E1B3, E1B4, E3B4 and others |
| Microsegmentation | Resources on segmented networks behind gateways, or host-based agents and firewalls | E2B3 and combined builds |
| SASE | SD-WAN, secure web gateway, CASB, firewall and ZTNA delivered as a service | E2B4, E2B5, E3B5, E2B6 and others |
Several later builds combine approaches, for example SDP with microsegmentation, or SDP with SASE. The lab emulated four enterprises, a branch office and a coffee shop over an emulated WAN, with resources across several cloud providers, which makes the remote and branch scenarios realistic. See the ZTNA Guide for the access technology behind most SDP builds.
Use cases
| Use case | What is demonstrated |
|---|---|
| A Discovery and identification | Endpoint discovery and authentication, reauthentication, transaction flow discovery |
| B Enterprise-ID access | Enterprise and BYOD access, stolen credentials, internet access, just-in-time privileges, step-up authentication |
| C Federated-ID access | Full, limited and no access for federated users; BYOD; stolen credentials |
| D Other-ID access | Similar to C, adding just-in-time access and step-up |
| E Guest (no ID) | Guest internet access only |
| F Confidence level | Responses to reauthentication failure, compliance change, policy violation and suspicious endpoints during a session |
| G and H | Service-to-service interaction and data-level security scenarios |
Identity and NHI requirements
SP 1800-35 is an identity-first document. In the EIG approach, ICAM products are the PDP; in every approach, ICAM is the primary policy information point. Points that matter for identity teams:
- Authenticate every party: the foundational finding covers users, requesting endpoints and the endpoints that host resources. In the crawl builds E1B1 and E3B1, resource-hosting endpoints were not authenticated or health-checked, which the guide records as a gap.
- Non-human subjects: the architecture treats non-human subjects as entities that are authenticated and protected by endpoint security, not as trusted because they sit on the network. Service-to-service interaction is a use case in its own right (G).
- Federated and other identities: use cases C and D test partner and external identities with different access levels, which is where federation trust and attribute quality become access controls. See the Federation and Trust Relationships Guide.
- Just-in-time and step-up: scenarios in B and D demonstrate privileges granted for a limited time and stronger authentication when risk rises, which maps directly to PAM and adaptive authentication designs. See the Privileged Access Management Guide.
- Device trust feeds identity decisions: lessons note that endpoint protection often integrates with ICAM only indirectly, through unified endpoint management, and that one build's integration was one-way, so compliance data could not flow back.
For workloads, service accounts and API credentials, the guide's service-to-service scenario is a starting point; the cloud-native detail is in the NIST SP 800-207A Zero Trust for Cloud-Native Applications Guide, and identity specifics in the Zero Trust Identity Guide.
Lessons learned that should shape your design
| Finding in SP 1800-35 | What to do about it |
|---|---|
| Vendor products often lack out-of-the-box integration to act as PDPs (EIG crawl) | Test PDP integration in proof of concept, not after purchase |
| Network PEPs usually do not integrate directly with ICAM | Plan connectors or move enforcement to identity-aware proxies |
| Devices joined to the network manually, no network admission control (crawl) | Add device discovery and admission control early |
| Builds without an EPP lacked automated remediation and trust scoring | Treat endpoint posture as a required PIP |
| Multiple PDPs fragment policy and do not share risk information | Define one policy model and a shared risk signal path, or accept and document the fragmentation |
| SIEM and SOAR data should feed PDPs in real time | Wire detections into access decisions, not only into tickets |
| Data security tools should inform PDPs; resource management tools should integrate with PDPs | Include data classification and asset inventory in the architecture, not as separate projects |
The run-phase builds showed the benefits that justify the effort: secure direct tunnels to private resources, connectors that hide internal resources from discovery, direct cloud access without hairpinning through the corporate network, inspection of cloud and internet traffic, and blocking of new non-compliant endpoints.
Implementation steps
The guide closes with seven takeaways that work as a programme sequence. Expanded:
- Discover and inventory the environment: users, devices, workloads, non-human identities, applications, data and flows. Use case A (transaction flow discovery) is the test.
- Formulate access policy from business use cases: who and what needs which resource, from where, under which conditions.
- Identify existing capabilities: most organisations already own an IdP, EDR, SIEM and some form of remote access. Map them to PE, PA, PEP and PIP roles.
- Close gaps by risk: prioritise by the value of the data and systems protected.
- Implement incrementally: start with an EIG-style crawl phase (identity and device as the PDP inputs) for one user population and a few applications, then add SDP, microsegmentation or SASE components. Run new policies in report-only or monitoring mode before enforcing, and keep the legacy access path available for the pilot group as a rollback.
- Verify against outcomes: replay the relevant SP 1800-35 scenarios (stolen credentials, non-compliant device, step-up, federated user denied) against your build.
- Improve continuously: revisit policy and integration as threats, technology and business needs change.
Choosing a starting approach
- Identity-heavy, mostly SaaS estate: start with EIG; the IdP's conditional access becomes the first PDP.
- Large private application estate and remote users: SDP or ZTNA to remove network-level access.
- Flat data centre network, lateral movement concern: microsegmentation.
- Distributed branches, existing network refresh: SASE.
- Small organisations: one IdP with device compliance signals and a ZTNA service covers most of the crawl and run outcomes; avoid building multiple PDPs.
Evidence and assessment
- Scenario results: record each SP 1800-35 use case you have tested, the expected outcome and the observed outcome. This is the most persuasive evidence for auditors and leadership.
- Architecture record: document which product plays PE, PA, PEP and each PIP, and where signals flow one way only.
- Logs: policy decision logs, PEP enforcement logs, IdP sign-in and risk events, endpoint compliance changes, all retained centrally (CSF 2.0 PR.PS-04).
| Metric | What it shows |
|---|---|
| Applications behind a PEP (%) | Coverage of the architecture |
| Access decisions using device posture (%) | Whether endpoint signals reach the PDP |
| SP 1800-35 scenarios passed | Functional assurance against a public test set |
| Time from detection to session revocation | Whether SIEM and SOAR feed access in practice |
| Standing network-level access paths remaining | Progress removing implicit trust |
| Non-human identities authenticated per request | Coverage beyond human users |
Mapping to other frameworks
| Framework | Relationship |
|---|---|
| NIST SP 800-207 | The concept and logical architecture SP 1800-35 implements |
| NIST CSF 2.0 | Mapped in the guide; relevant outcomes include ID.AM-01, ID.AM-02, PR.AA-05, PR.IR-01, PR.PS-04, DE.CM-01 |
| NIST SP 800-53 Rev. 5 | Mapped in the guide; controls commonly involved include AC-3, AC-4, AC-6, IA-2, IA-3, IA-9, SC-7, CA-7, SI-4 |
| CISA Zero Trust Maturity Model | A maturity scale across pillars; SP 1800-35 builds show technology that can reach higher stages. See the CISA Zero Trust Maturity Model Guide |
| DoD Zero Trust Reference Architecture | Defence-specific capability framework; see the DoD Zero Trust Strategy and Reference Architecture Guide |
The control lists above are examples of where the topic sits; use the mapping tables in the full SP 1800-35 web document for the authoritative, per-capability mapping.
Common pitfalls
- Copying a build as a product shortlist: builds show feasibility in a lab with vendor engineers, not fit for your estate or a recommendation.
- Stopping at the crawl phase: identity-only PDPs with no resource-hosting endpoint authentication and no device admission leave the gaps the guide itself records.
- Several PDPs with no shared policy: IdP conditional access, ZTNA policy and segmentation rules drift apart, as the lessons warn.
- Humans only: service-to-service traffic and NHIs left on implicit network trust while users get MFA and device checks. See the Top 10 Zero Trust Mistakes.
- No verification: controls deployed but never tested against scenarios like stolen credentials or a device falling out of compliance mid-session.
Practitioner checklist
- Read the high-level document, then the full web document sections for the builds closest to your estate.
- Map your current products to PE, PA, PEP and PIP roles and note one-way integrations.
- Choose a starting approach (EIG, SDP, microsegmentation or SASE) from your estate profile.
- Authenticate resource-hosting endpoints and non-human subjects, not only users.
- Feed endpoint posture and SIEM detections into access decisions.
- Pilot in report-only mode with a rollback path, then enforce in rings.
- Adopt the SP 1800-35 use cases as your acceptance test set and record results.
- Track the six metrics above and report them alongside maturity scores.
Standards and references
- NIST: SP 1800-35 Implementing a Zero Trust Architecture
- NIST: SP 1800-35 High-Level Document (PDF)
- NIST NCCoE: Implementing a Zero Trust Architecture project
- NIST: SP 800-207 Zero Trust Architecture
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: NIST SP 800-207 Zero Trust Architecture Guide · Zero Trust Identity Guide · CISA Zero Trust Maturity Model Guide · ZTNA Guide · Zero Trust for AI Agents Guide