NIST SP 800-207
Zero Trust Architecture: tenets, components, and evidence
NIST SP 800-207 (Zero Trust Architecture) is the authoritative reference standard for Zero Trust, published by NIST in August 2020. It defines Zero Trust as a set of design principles for an enterprise cybersecurity architecture that moves the defensive perimeter away from network locations and onto users, assets, and resources. This page covers the seven tenets, the three logical components (Policy Engine, Policy Administrator, Policy Enforcement Point), the trust algorithm inputs, the three core deployment approaches, the variations (Device Agent/Gateway, Enclave Gateway, Resource Portal, Application Sandboxing), the threats specific to ZTA, the relationship with the CISA Zero Trust Maturity Model and OMB M-22-09, and the audit-grade evidence a Zero Trust programme keeps in one operating record.
No credit card required. Free plan available forever.
NIST SP 800-207 Zero Trust Architecture explained
NIST Special Publication 800-207, published in August 2020 and authored by Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly, is the authoritative reference standard for Zero Trust Architecture. The publication defines Zero Trust as a set of design principles, not a product. It names the architecture by what it does (treat every resource as untrusted by default, evaluate access per session against dynamic policy, monitor asset posture continuously) rather than by what it is built from, which is why the same reference reads against a programme deploying identity-aware proxies, a programme building software-defined perimeters, and a programme adopting micro-segmentation behind cloud-native gateways.
For internal security teams, AppSec teams, vulnerability management functions, GRC owners, security engineering teams, and CISOs, SP 800-207 is the vocabulary that lets a Zero Trust programme communicate consistently across architecture review boards, audit committees, federal customers, and security vendors. Programmes already operating against NIST CSF 2.0, NIST SP 800-53, or ISO 27001 do not need to migrate; SP 800-207 sits as the architectural overlay that the underlying control catalogues evidence.
The seven tenets of Zero Trust
SP 800-207 grounds Zero Trust in seven tenets that describe the operating posture rather than a product or a checklist. The tenets are the test a programme runs itself against: a design that violates a tenet is not Zero Trust under SP 800-207, regardless of what the vendor literature claims.
Tenet 1: All data sources and computing services are resources
Everything that produces or consumes data inside the enterprise is treated as a resource subject to access policy. The legacy distinction between trusted infrastructure (databases, internal services) and untrusted infrastructure (the open internet) is dropped. The shift matters because the inventory the rest of the architecture reads against is now exhaustive rather than implicit.
Tenet 2: All communication is secured regardless of network location
Location on the corporate network is no longer a credential. The same authentication, encryption, and policy enforcement apply whether the subject is on the office LAN, on a coffee-shop hotspot, or on a contractor laptop. The tenet rules out the implicit trust that legacy perimeter models granted to anything inside the firewall.
Tenet 3: Access to individual enterprise resources is granted on a per-session basis
Trust is evaluated before each connection, not granted at logon and assumed for the day. A session getting access to one resource does not entail access to any other resource. Per-session evaluation is what makes ZTA different from a stronger VPN; the same identity may be granted access to resource A and denied access to resource B within seconds.
Tenet 4: Access is determined by dynamic policy
Policy decisions take inputs beyond identity: the client identity, the application or service, the requesting asset state, behavioural attributes, and environmental attributes (geolocation, time, network in use). Dynamic policy is what lets the architecture respond to changes in posture (an unpatched device, a credential reused on an unfamiliar host) without rewriting the rule set.
Tenet 5: The enterprise monitors and measures the integrity and security posture of all assets
No asset is trusted simply because it exists. The enterprise maintains a continuous posture view: patch level, configuration drift, presence and currency of security agents, observed behaviour. The asset posture feeds the trust algorithm directly, so a previously trusted device that drifts out of policy loses access until it returns to a known-good state.
Tenet 6: All resource authentication and authorisation are dynamic and strictly enforced
Authentication and authorisation happen before access is allowed, every time. The tenet covers both the strength of the authentication (the standard names MFA explicitly) and the strict-enforcement requirement (the policy decision binds, with no soft-fail fallback to the legacy network path).
Tenet 7: The enterprise collects information about the current state and uses it to improve the security posture
Logging is not optional and not retrospective only. Telemetry across PEPs, resources, identity providers, and asset posture is collected, correlated, and fed back into the policy engine so the architecture compounds: each cycle the policy reads against richer context than the previous cycle.
The three logical components: PE, PA, PEP
SP 800-207 splits the ZTA decision plane into three logical components. The Policy Engine and the Policy Administrator together form the Policy Decision Point (PDP), which the Policy Enforcement Point queries before each access decision. The decomposition is logical; an implementation can host the PE and PA inside one product, distribute them across multiple services, or replace either independently as the architecture evolves.
Policy Engine (PE)
The decision-making component. The PE evaluates the trust algorithm against the policy rule set for the requested resource and the available subject, asset, and environmental inputs, then issues a grant, deny, or revoke decision. The PE is logically distinct from the gate that enforces the decision; programmes can replace the PE without rebuilding the PEPs.
Policy Administrator (PA)
The component that establishes, modifies, and terminates the communication path between a subject and a resource based on the PE decision. The PA is the operational arm: it provisions sessions, configures the credentials or tokens the PEP needs to allow traffic, and tears the session down when the PE revokes the decision.
Policy Enforcement Point (PEP)
The gate that enables, monitors, and eventually terminates connections between a subject and an enterprise resource. The PEP is the data-plane component that sits in the request path. PEPs can be implemented as identity-aware proxies, gateway services, sidecars, host-based agents, or as overlay tunnels, depending on the deployment approach.
Trust algorithm inputs
The trust algorithm is the process the PE uses to grant, deny, or revoke access. SP 800-207 names the input categories the algorithm reads against. The algorithm can be criteria-based (binary checks against a fixed rule set, useful when the inputs are well-typed and the policy is regulator-grade) or score-based (weighted scoring against a confidence threshold, useful when behavioural and environmental signals carry meaningful but uncertain information). Mature programmes blend the two: a criteria check on the regulator-grade requirements, then a score-based read for the contextual nuance.
- Access request attributes: the subject identity, the requested resource, the requested action, the requesting application, and the network path the request travelled.
- Subject database: identity attributes, group memberships, role assignments, MFA strength used at logon, and the recent access history that informs behavioural signals.
- Asset database: device posture (operating system patch level, security agent presence, configuration drift), ownership, observed behaviour, and recent integrity events.
- Resource policy requirements: the per-resource rule set, including the required authentication strength, the allowed action set, the environmental constraints, and the additional inputs the resource demands.
- Threat intelligence: vulnerability data on the requesting asset or the resource, indicators of compromise, and observed malicious activity that should weight the decision toward denial.
Three core deployment approaches
SP 800-207 names three approaches a programme can take to ZTA. The approaches are not mutually exclusive; most enterprise programmes blend two or three of them rather than adopting only one. The choice is driven by the legacy architecture in place, the identity and asset management maturity, and the rate at which the resource catalogue is changing.
Enhanced Identity Governance
Identity is the primary policy driver. Resource access decisions read against the assigned identity privileges, the observed identity behaviour, the MFA strength used at logon, and the asset the identity is authenticating from. Enhanced Identity Governance is the approach a programme already running modern identity management can grow into without rebuilding the network. The PEPs are typically identity-aware proxies or identity-aware application access services.
Logical Micro-segmentation
Resources sit behind gateways that enforce identity-and-context policy on each access decision. The legacy flat network is split into segment-of-one boundaries, with policy granularity at the resource (or small cluster of resources) rather than the subnet. Micro-segmentation is the approach programmes with significant east-west traffic exposure adopt; it limits the blast radius of any compromise that lands inside the perimeter.
Network Infrastructure and Software-Defined Perimeters
The underlying network infrastructure (or an overlay on top of it) creates resource access paths that are invisible to unauthorised subjects. Software-Defined Perimeter (SDP) constructions, identity-aware overlay networks, and dynamic ACL provisioning are the typical instruments. The approach is closest to a wholesale replacement of the legacy network path and is most common where the programme has the runway to invest in the underlying infrastructure.
ZTA deployment variations
Beyond the three approaches, SP 800-207 details four deployment variations that describe how the components physically sit relative to the subject and the resource. The variation choice depends on what the device fleet looks like, whether the resource can host a sidecar, and whether partner or contractor access is in scope. A real programme typically runs more than one variation across the resource catalogue.
Device Agent / Gateway
An agent on the subject device coordinates with a gateway in front of the resource, with the PA establishing the session between them. The agent reports the device posture to the PE; the gateway enforces the PE decision in the data path. Common when the subject device is managed (corporate laptops, managed mobile fleets) and the resource sits behind a network boundary the programme controls.
Enclave Gateway
A single gateway protects a collection of resources rather than each resource individually. Useful for legacy applications that cannot host a sidecar, mainframe-style estates, and partner-facing services that must be brokered. The PEP discipline applies at the enclave boundary; resources inside the enclave inherit the policy decision the gateway enforced.
Resource Portal
A single PEP acts as the entry to a portfolio of resources, common for partner and contractor access where the subject device is unmanaged. The portal exposes the subset of resources the policy decision allows, with no direct network path from the subject to any resource other than through the portal.
Device Application Sandboxing
A trusted application on the subject device holds the access path, with the rest of the device treated as untrusted. The sandbox enforces the resource access through itself, so identity, application identity, and asset posture combine to gate the resource. Useful where the device is shared, BYOD, or otherwise not amenable to full management.
Threats specific to Zero Trust Architecture
SP 800-207 documents the threats that arise from the ZTA model itself, not from the absence of it. The threats are not arguments against ZTA; they are the engineering requirements the architecture has to meet for the trust-shift from the network to the policy plane to net out positive. Programmes that adopt ZTA without designing against these threats inherit them in concentrated form.
- Subversion of the ZTA decision process. Compromise of the PE or PA shifts the trust boundary from the network to the policy plane, and a compromised PDP can grant access at will. Defence is governance: separation of duties around PE and PA administration, strong identity for PE and PA operators, immutable audit trail of policy changes, and tamper-evident logging of PDP decisions.
- Denial of service against the PDP or PEPs. A ZTA with a centralised PDP that cannot reach the PEPs (or vice versa) breaks legitimate resource access; the fail-closed default is correct but adds availability sensitivity. Defence is redundancy at the PDP, cached policy decisions at the PEP within a bounded freshness window, and observability that distinguishes outage from attack.
- Stolen credentials and insider threats. Identity-centric policy raises the value of identity compromise. Defence is phishing-resistant MFA, behavioural detection on identity use, just-in-time elevation rather than standing privilege, and continuous monitoring of identity behaviour through the same PDP that issues access decisions.
- Reduced network visibility from end-to-end encryption. Traffic between PEP and resource is typically encrypted, which constrains traditional inspection-based detection. Defence is endpoint and resource-side telemetry that does not depend on inline traffic inspection, plus selective decryption points where the policy allows and the data-protection regime permits.
- High-value PDP data store. The PDP holds the subject, asset, and policy inventory the rest of the architecture reads against. Defence is data minimisation in the PDP, encryption of the policy and inventory at rest, strict access control to the PDP administrative surface, and integrity verification on the policy rule set.
- Proprietary identity and policy formats. Reliance on vendor-specific data formats can lock the programme to one ecosystem and constrain evolution. Defence is standards-based identity (OIDC, SAML, SCIM where supported), portable policy formats where the deployment allows, and a documented exit plan that the programme can execute without rebuilding the architecture from scratch.
CISA Zero Trust Maturity Model alignment
SP 800-207 is the reference architecture; the CISA Zero Trust Maturity Model (ZTMM) v2.0 is the maturity model the federal-civilian community and most non-federal programmes use to track progress. ZTMM organises Zero Trust across five pillars and three cross-cutting capabilities, with four maturity stages (Traditional, Initial, Advanced, Optimal). OMB Memorandum M-22-09 is the federal-side mandate that obliges United States federal civilian agencies to adopt the Zero Trust strategy. The DoD Zero Trust Reference Architecture is the defence-side companion. Non-federal programmes typically read ZTMM as the maturity inventory and SP 800-207 as the architectural reference.
- Identity: identity providers, MFA, identity governance, behavioural analytics on identity use, and the identity-side inputs the trust algorithm reads against.
- Devices: asset inventory, device posture (patch, configuration, agent presence), continuous device-posture verification, and the device-side inputs the trust algorithm reads against.
- Networks: network segmentation, encrypted transport, software-defined perimeters where applicable, and the network-side inputs that feed the policy decision.
- Applications and Workloads: application-aware access, application-level inspection where decryptable, secure development practices, and the application-side inputs the policy considers.
- Data: data classification, data-aware access control, data-loss telemetry, and the data-side context the policy decision uses for the most sensitive resources.
- Cross-cutting: Visibility and Analytics, Automation and Orchestration, and Governance are the three capabilities CISA ZTMM names as pillars-spanning rather than pillar-specific.
Failure modes the reference architecture is designed to surface
SP 800-207 is forgiving on the choice of vendor, the choice of deployment approach, and the choice of identity provider. It is unforgiving about a small number of patterns that erode the integrity of the architecture and leave the programme with the appearance of Zero Trust rather than the operating posture. The patterns below are the recurring ones across early and mid-stage adoptions.
- Calling a VPN replacement Zero Trust. A network access broker that authenticates once and then trusts the session is not ZTA. The session-by-session re-evaluation in Tenet 3 and the dynamic policy in Tenet 4 are what distinguish ZTA from a stronger remote access tunnel.
- Adopting one vendor stack and calling it the architecture. NIST SP 800-207 is intentionally vendor-neutral. Programmes that confuse a vendor reference architecture with the NIST standard lose the portability that lets the programme evolve. The architecture is the design; the vendor is the implementation.
- Skipping the inventory step. The trust algorithm cannot read against subjects and assets it does not know about. Programmes that begin with the PEP rollout before completing the subject and asset inventory ship a policy plane that grants by default on the unknown set.
- Treating identity as the only input. Identity is essential but insufficient. Tenet 5 names asset posture explicitly; Tenet 4 names behavioural and environmental attributes. A programme that authenticates well and ignores device posture has rebuilt the legacy perimeter with a stronger logon.
- Centralising the PDP without redundancy. The PDP becomes a single point of failure when there is no fallback path. The fail-closed default is correct, but availability needs the same engineering attention any other tier-zero service receives.
- Conflating the CISA ZTMM with the NIST SP 800-207 reference architecture. ZTMM is the maturity inventory; SP 800-207 is the architectural reference. A programme that reads ZTMM as the design and never returns to SP 800-207 ends up with a checklist that does not describe the architecture it is supposed to evidence.
- Failing to update the policy rule set as the resource catalogue grows. A static rule set is a stale rule set; new resources land outside the policy, inherit a permissive default, or sit behind no PEP at all. The architecture stays operational only when the policy refresh cadence matches the rate of resource change.
Evidence the architecture expects to see
A SP 800-207 programme is auditable when the evidence is produced as a side effect of the operating work rather than reconstructed at audit time. The minimum set below maps to the artefacts examiners, customer auditors, and federal customers most often ask against, and the same artefacts feed parallel reads under NIST CSF 2.0, NIST SP 800-53, ISO 27001, SOC 2, and the CISA ZTMM scorecard when the underlying record is structured.
- Documented Zero Trust strategy and target architecture, with the deployment approach (Enhanced Identity Governance, Logical Micro-segmentation, SDP, or a documented blend) named and the rationale recorded
- Inventory of subjects (users, devices, services) and resources, with the criticality classification and the assigned policy rule set per resource class
- Trust algorithm description and the inputs feeding it (subject, asset, resource policy, threat intelligence), with the criteria-based or score-based decision logic documented
- PEP coverage map showing which resources are behind which PEP, the deployment variation each PEP uses, and the fail-open or fail-closed default per PEP
- Asset posture record covering device patch level, configuration baseline, security agent presence, and observed behaviour for the assets the trust algorithm reads against
- Identity governance evidence covering account lifecycle, privilege review cadence, MFA enforcement strength, and the SCIM or equivalent provisioning record
- Continuous monitoring output across PEP logs, resource-side telemetry, identity provider logs, and the PDP decision log, with retention sufficient for the incident timeline
- Incident record covering ZTA-specific events (PDP availability incidents, policy misconfiguration, credential compromise with policy implications), with the post-incident improvement folded back into the policy rule set
- CISA ZTMM scorecard per pillar (Identity, Devices, Networks, Applications and Workloads, Data) and per cross-cutting capability, with the maturity stage and the supporting evidence recorded
How SP 800-207 relates to CSF 2.0, SP 800-53, ISO 27001, and adjacent regimes
SP 800-207 is an architectural reference, not a control catalogue. The control evidence the architecture needs lives in the underlying catalogues a programme already operates against. The relationships below are the ones programmes most often need to read together.
- The NIST CSF 2.0 framework page covers the outcome framework that ZTA reads against. The PR (Protect) function maps directly to the access-control and identity-management work ZTA carries; the DE (Detect) function reads against the continuous monitoring SP 800-207 mandates; the GV (Govern) function carries the policy hierarchy and the executive accountability the architecture needs at scale.
- The NIST SP 800-53 framework page covers the control catalogue underneath. ZTA reads against the AC (Access Control), IA (Identification and Authentication), SC (System and Communications Protection), AU (Audit and Accountability), and SI (System and Information Integrity) families directly. Federal and federally regulated programmes typically operate SP 800-53 as the control set and SP 800-207 as the architectural overlay.
- The ISO 27001 framework page covers the certifiable Information Security Management System standard. ISO 27001 Annex A controls (A.5 access control, A.6 identity, A.7 authentication, A.8 asset management, A.5.7 threat intelligence) carry the underlying evidence SP 800-207 reads against, so an ISO 27001 ISMS already produces most of the artefact set the ZTA programme needs.
- The CISA Secure by Design framework page covers the principles and pledge for software manufacturers. Secure by Design and Zero Trust share the operating premise that defaults must be safe; software produced under Secure by Design reduces the burden ZTA carries by removing the unsafe defaults the architecture would otherwise have to constrain.
- The CIS Controls framework page covers the prioritised defensive actions. CIS Controls v8.1 carries the prescriptive guidance for identity (Control 5, Control 6), asset inventory (Control 1, Control 2), and access control (Control 12) that ZTA depends on, so a CIS Controls IG2 or IG3 baseline gives ZTA a strong foundation to read against.
- The SOC 2 framework page covers the AICPA Trust Services Criteria. SOC 2 examinations read against the same underlying access-control, authentication, and monitoring evidence ZTA needs; programmes operating SOC 2 already hold most of the CC6 (Logical and Physical Access) and CC7 (System Operations) artefacts ZTA expects.
- The CISA Cybersecurity Performance Goals framework page covers the prioritised baseline CISA recommends for critical infrastructure and any organisation with a comparable risk profile. CPGs v2.0 reads against the same identity, access-control, and continuous monitoring outcomes SP 800-207 expects; programmes adopting CPGs as the prioritised first wave land most of the prerequisite work ZTA reads against.
- The Zero Trust Architecture implementation guide covers the practitioner-side rollout: building the inventory, choosing the deployment approach, sequencing the PEP rollout, and operating the policy rule set against the changing resource catalogue. The implementation guide pairs with this reference page as the operational companion.
Where SecPortal fits in a SP 800-207 programme
SecPortal is the operating layer for the Zero Trust programme record, not a Policy Engine, Policy Administrator, or Policy Enforcement Point. The platform handles the strategy document, the inventory of subjects and resources at audit time, the asset posture findings from the SAST, authenticated DAST, and external scanning work, the continuous monitoring evidence, the policy review cadence, and the ZTMM scorecard refresh so the architecture evidence sits on one operating record rather than spread across a dozen tools and spreadsheets.
- Engagement management dedicated to the Zero Trust programme, with the strategy work, the inventory build, the PEP rollout per resource class, the policy refresh cadence, and the ZTMM scorecard refresh tracked as workstreams rather than ad hoc projects
- Findings management with CVSS 3.1 scoring so the asset posture issues (unpatched devices, missing security agents, configuration drift) that feed the trust algorithm have owners, deadlines, and verification evidence
- Compliance tracking that maps the same evidence pack across NIST SP 800-207, CISA ZTMM, NIST CSF 2.0, NIST SP 800-53, ISO 27001, and SOC 2, so the cross-framework footprint reads from a single source
- External, authenticated, and code scanning so the resource inventory the architecture protects has named coverage across internet-facing infrastructure, authenticated application surface, and source repositories rather than disconnected tooling silos
- Continuous monitoring with scheduled scans so the asset posture refresh cadence the trust algorithm reads against is recorded rather than reconstructed during examination
- MFA enforcement on the SecPortal workspace itself, so the identity governance the ZTA depends on is not undermined at the platform that holds the evidence
- Activity log that captures every state change to a finding, an asset record, or a policy review item with timestamp and named user, so the audit trail is reproducible without a multi-team excavation
- AI report generation that turns the engagement evidence and the ZTMM scorecard refresh output into a Zero-Trust-shaped leadership report and a board-ready summary without manual rewriting
The asset posture inputs that feed the trust algorithm are where most of the day-to-day vulnerability work touches ZTA. Findings from authenticated scans against the resources the PEPs guard, external scanning against the internet-facing surface, and code scanning against the repositories that build the resources all read against the asset posture record the PE consumes. The remediation tracking workflow keeps the line from the finding through to the asset posture evidence auditable. The asset criticality scoring workflow carries the resource classification ZTA uses to attach the right policy rule set per resource class. The security leadership reporting workflow rolls the ZTMM scorecard refresh and the architecture posture into the leadership cadence the GOVERN function expects.
For internal teams running the programme, the internal security teams workspace bundles the platform with the engagement structure SP 800-207 expects across the cycle. For the security engineering function that owns the PEP rollout, the policy rule set, and the asset posture integrations, the security engineering teams workspace covers the build-side mechanics. For the AppSec function that owns the application-side access-control evidence the architecture reads against, the AppSec teams workspace carries the development-adjacent angle. For the security architecture function that owns the threat model, the design review queue, the control-to-architecture mapping, and the review evidence the ZTA tenet checklist reads against, the security architects workspace carries the design-side angle on the same engagement record the rest of the workspace operates from. For the GRC function that holds the audit-side evidence pack across CSF 2.0, SP 800-53, ISO 27001, and the CISA ZTMM scorecard, the GRC and compliance teams workspace carries the cross-framework reconciliation. For security leaders carrying the architecture accountability and the ZTMM scorecard cadence, the CISOs and security leaders workspace covers the program-level reporting model.
For the continuous monitoring discipline SP 800-207 mandates, the continuous monitoring capability and the authenticated scanning capability produce the cadence and coverage record the architecture reads against. For analytical context on how the maturity model evolves across cycles, the continuous control monitoring cadence research covers the operating discipline that pairs with the ZTMM scorecard refresh, and the security control drift research covers the erosion patterns the architecture is designed to surface.
Key control areas
SecPortal helps you track and manage compliance across these domains.
The seven tenets
NIST SP 800-207 grounds Zero Trust in seven tenets that describe the operating posture rather than a product list. All data sources and computing services are treated as resources. All communication is secured regardless of network location. Access to individual enterprise resources is granted on a per-session basis. Access is determined by a dynamic policy that considers client identity, application, requesting asset state, behavioural attributes, and environmental attributes. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. All resource authentication and authorisation are dynamic and strictly enforced before access is allowed. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve the security posture.
The three logical components: PE, PA, PEP
The ZTA decision plane consists of three logical components. The Policy Engine (PE) is the decision-making component that ultimately decides whether to grant access to a resource for a given subject, based on the trust algorithm inputs. The Policy Administrator (PA) is responsible for establishing, modifying, and terminating the communication path between a subject and a resource based on the PE decision. The Policy Enforcement Point (PEP) is the gate that enables, monitors, and eventually terminates connections between a subject and an enterprise resource. The PE and PA are typically described as a single logical Policy Decision Point (PDP) that the PEP queries.
Trust algorithm inputs
The trust algorithm is the process the PE uses to grant, deny, or revoke access. NIST SP 800-207 names the inputs that feed it: access request attributes (subject, requested resource, requested action), subject database (identity attributes, group memberships, role assignments), asset database (device posture, patch level, configuration, observed behaviour), resource policy requirements (the rules attached to the requested resource), and threat intelligence (vulnerability information, indicators of compromise, observed malicious activity). The algorithm can be criteria-based (binary checks against a fixed rule set) or score-based (weighted scoring with a confidence threshold).
Three core deployment approaches
SP 800-207 names three approaches a programme can take to ZTA. Enhanced Identity Governance treats identity as the primary policy driver, with resource access decisions based on assigned identity privileges and observed identity behaviour. Logical Micro-segmentation places resources behind gateways that enforce identity-and-context policy on each access decision, splitting the legacy network into segment-of-one boundaries. Network Infrastructure and Software-Defined Perimeters use the underlying infrastructure to create resource access overlays that are invisible to unauthorised subjects. Most enterprise programmes blend the three rather than adopting only one.
ZTA deployment variations
NIST SP 800-207 details four deployment variations the components can take. Device Agent/Gateway has an agent on the subject device and a gateway in front of the resource, with the PA establishing the session between them. Enclave-based has gateways protecting collections of resources rather than individual resources, useful for legacy applications that cannot host a sidecar. Resource Portal has a single PEP that acts as the entry to a portfolio of resources, common for partner and contractor access. Device Application Sandboxing isolates approved applications on a managed device so the trusted application has the access path rather than the device. Each variation reads against the same trust algorithm; what changes is the placement of the PEP relative to the subject and the resource.
ZTA-specific threats
SP 800-207 documents threats that arise from the ZTA model itself rather than from the absence of it. Subversion of the ZTA decision process (compromise of the PE or PA) shifts the trust boundary from the network to the policy plane, so the integrity of that plane is now a single point of failure. Denial of service against the PDP or PEPs breaks resource access for legitimate subjects. Stolen credentials or insider threats remain potent because identity-centric policy raises the value of identity compromise. Visibility into the network reduces when traffic is end-to-end encrypted between PEP and resource, which constrains traditional inspection-based detection. Storage of system and network information at the PDP creates a new high-value target. Reliance on proprietary data formats and identity providers risks vendor lock-in that constrains the ability to evolve the architecture.
Programme maturity inputs from CISA and DoD
NIST SP 800-207 is the reference architecture; the CISA Zero Trust Maturity Model (ZTMM) v2.0 and the DoD Zero Trust Reference Architecture translate it into a maturity model that programmes adopt. CISA ZTMM organises Zero Trust across five pillars (Identity, Devices, Networks, Applications and Workloads, Data) and three cross-cutting capabilities (Visibility and Analytics, Automation and Orchestration, Governance), with four maturity stages (Traditional, Initial, Advanced, Optimal). OMB Memorandum M-22-09 is the federal-side mandate that obliges United States federal civilian agencies to adopt the Zero Trust strategy. Non-federal programmes use ZTMM as the maturity inventory and read against NIST SP 800-207 as the architectural reference.
Evidence the architecture expects to see
A NIST SP 800-207 programme is auditable when the evidence is produced as a side effect of the operating work. The minimum set includes the documented Zero Trust strategy and target architecture, the inventory of subjects (users, devices, services) and resources, the policy rule set per resource class, the trust algorithm description and the inputs feeding it, the PEP coverage map (which resources are behind which PEP), the asset posture record (device patch level, configuration baseline, observed behaviour), the identity governance evidence (account lifecycle, privilege review cadence, MFA enforcement), the continuous monitoring output across PEP logs and resource-side telemetry, and the incident record for ZTA-specific events. The CISA ZTMM scorecard reads against the same artefact set when the programme is structured.
Related features
Compliance tracking without a full GRC platform
Vulnerability management software that tracks every finding
Orchestrate every security engagement from start to finish
Test web apps behind the login
Monitor continuously catch regressions early
Every action recorded across the workspace
Multi-factor authentication on every workspace
Hold the Zero Trust architecture record on one workspace
Capture the documented strategy, the policy rule set per resource, the PEP coverage map, the asset posture evidence, the continuous monitoring output, and the CISA ZTMM scorecard alongside the SAST, DAST, external scanning, and engagement evidence the SecPortal workspace already holds. Start free.
No credit card required. Free plan available forever.