NIST SP 800-207 §3.0
Zero Trust Architecture
Logical component model — click any node to explore
Click any component to navigate to its detail page · NIST SP 800-207 §3.0 logical architecture
Zero Trust Architecture defines a paradigm where no implicit trust is ever granted based on network location or asset ownership. Every access request is authenticated, authorized, and continuously evaluated. The three core enforcement components — Policy Engine, Policy Administrator, and Policy Enforcement Point — form the decision and enforcement pipeline. Supporting infrastructure (IDMS, PKI, CDM, Threat Intel, Activity Log) feeds the trust algorithm with real-time signals.
NIST SP 800-207 §2.1
Seven Tenets
The foundational principles — all seven must be satisfied by a ZTA implementation
T-01
All data sources & services are resources
Every network-connected device and data source qualifies as a resource — regardless of form factor, ownership, or physical location. Personal devices qualify as resources.
T-02
All communication secured regardless of location
Network location alone does not imply trust. All communication — internal or external — must be authenticated, authorized, and encrypted. Being on the LAN grants nothing.
T-03
Access to resources granted per-session
Access is granted on a per-session basis with least-privilege principles. Trust is evaluated before access is granted and is not persistent — it does not carry over between sessions.
T-04
Access determined by dynamic policy
Resource access policy is dynamic, enforced in real time using identity, device health, behavioral data, and environmental attributes such as time of day, location, and threat intelligence.
T-05
Enterprise monitors & measures all asset integrity
The enterprise monitors the security posture of all owned and associated assets continuously. No device is trusted based on prior authentication state — posture is re-evaluated constantly.
T-06
All auth & authorization is dynamic & strictly enforced
Authentication and authorization are strictly enforced before access is allowed. Continuous re-evaluation occurs throughout sessions; anomalies trigger reauthentication or immediate revocation.
T-07
Collect data to improve security posture
The enterprise collects and analyzes behavioral, traffic, and access data to continuously improve authentication strength, access policies, and threat detection capabilities.
The unifying principle
All seven tenets converge on a single premise: no implicit trust is granted to assets or user accounts based solely on their physical or network location. Authentication and authorization are discrete functions performed before a session is established — derived from verified signals, not from network adjacency.
NIST SP 800-207 §3.1 · PE
Policy Engine
The trust brain — evaluates all signals and renders the access decision
The Policy Engine is responsible for the ultimate decision to grant, deny, or revoke access to a resource for a given subject. It receives input from the enterprise’s supporting infrastructure — CDM data, identity assertions, threat intelligence, behavioral logs — processes them against enterprise access policy, and computes a trust score that drives the decision. The PE and PA are logical components that may be co-located or distributed.
What the PE evaluates
IDENTITY
Subject identity & credential strength
IdP-asserted identity, MFA status and factor type, credential freshness, privileged account flags, federated assertions (SAML, OIDC). An MFA assertion 8 hours old carries less weight than one from 5 minutes ago.
DEVICE
Device health & posture
CDM telemetry: patch level, EDR agent status, certificate validity, OS compliance, MDM enrollment, software inventory. A device matching a known IoC from threat intel fails this signal regardless of identity strength.
NETWORK
Network location & context
Source IP, geolocation, time-of-day, network path characteristics. Contextual signal only — never a trust anchor. Per Tenet T-02, location does not imply trust.
RESOURCE
Resource sensitivity & access policy
Data classification, resource criticality, required assurance level. The PE checks the requesting subject’s attributes against the resource’s policy requirements before granting.
BEHAVIOR
Behavioral & threat intelligence
Historical access patterns, UEBA baseline deviation, threat feed hits (IP/domain reputation, IoCs, CVE correlation), SIEM correlation output. The continuous signal — it updates mid-session.
Decision outcomes
Grant access
All signals pass policy thresholds. PE instructs PA to issue a session token to the PEP. Access scope is limited to least-privilege per Tenet T-03.
Deny access
One or more signals fail: unregistered device, failed MFA, anomalous behavior, policy violation, resource classification exceeds clearance. No token issued; traffic blocked at PEP.
Step-up or revoke mid-session
Risk picture changes during an active session. PE re-evaluates and may require step-up MFA, reduce scope, or instruct PA to revoke the PEP tunnel immediately.
PE is logical, not physical
NIST explicitly states the PE and PA are logical components. In real deployments they may be a single identity-aware proxy, a ZTNA gateway’s policy service, or distributed microservices. What matters is that the functions are performed — not how they are packaged.
NIST SP 800-207 §3.1 · PA
Policy Administrator
Executes the Policy Engine’s decisions — commands the PEP to open or close sessions
The Policy Administrator is responsible for establishing and severing communication paths between subjects and enterprise resources. Where the PE decides, the PA acts. It communicates with the PEP on the control plane, entirely separate from the user’s data traffic. This separation is architectural — the PA’s commands cannot be observed or tampered with by anything on the data plane.
What the PA does
ENABLE
Issue session tokens to the PEP
When the PE grants access, the PA generates a session token scoped to the specific subject, device, and resource. It pushes that token to the PEP, instructing it to permit traffic matching those parameters.
REVOKE
Terminate active sessions
When the PE revokes access — due to a mid-session anomaly, posture change, or explicit policy — the PA instructs the PEP to immediately terminate the tunnel. The PEP executes; it does not decide independently.
SCOPE
Enforce least-privilege access scope
Session tokens are scoped to exactly the resource and action the policy permits. The PA issues the minimum required for the requested task, per Tenet T-03 — not broad-access tokens.
CHANNEL
Control plane communication channel
All PA-to-PEP communications occur out-of-band from user data traffic. This channel must be mutually authenticated and encrypted (TLS 1.3+). A compromised data plane cannot interfere with PA commands.
PA as the enforcement relay
The PA is the operational bridge between policy and enforcement. The PE reasons about trust; the PA operationalizes that reasoning. Neither component alone is sufficient — a PE without a PA has no means of enforcement, and a PEP without a PA has no policy guidance.
NIST SP 800-207 §3.1 · PEP
Policy Enforcement Point
The inline gateway — the only valid path between a subject and an enterprise resource
The PEP enables, monitors, and terminates connections between a subject and an enterprise resource. It is the only valid path to any resource — no route bypasses it. All data plane traffic flows through it. The PEP doesn’t make access decisions; it executes PA commands and enforces session tokens.
Architecture
The PEP logically splits into two halves. The subject-side component (a ZT agent on the device, or a clientless proxy) intercepts the access request and initiates the auth flow. The resource-side component (a gateway or proxy in front of the resource) receives the session token and enforces it for every connection attempt.
What the PEP enforces
GATE
Session token validation
The PEP validates that each connection attempt carries a valid session token issued by the PA. No token, no access — regardless of network origin, protocol, or claimed identity.
SCOPE
Least-privilege scope enforcement
The session token specifies the exact resource, port, protocol, and action permitted. The PEP enforces these constraints on every packet and does not permit lateral movement to adjacent resources.
MONITOR
Continuous session monitoring
The PEP watches all traffic for anomalies throughout the session: unusual data volumes, protocol deviations, new destination IPs, suspicious payload patterns. Anomalies are reported to the activity log.
REVOKE
Session termination on PA command
When the PA issues a revoke command, the PEP tears down the session immediately — mid-transfer if necessary. No grace period.
Telemetry the PEP reports to the activity log
Per-session data (identity, device, resource, bytes, duration, termination reason), anomaly indicators (lateral movement patterns, volume spikes, protocol deviations), authentication events (MFA challenges, step-up triggers, failed attempts), and every policy evaluation result it enforces — grant, deny, and revocation.
The PEP cannot be bypassed — by design
In an SDP deployment, resources are dark to unauthenticated subjects — they don’t respond to port scans or connection attempts that haven’t been authorized by the PA. The PEP isn’t a filter on a known path; it is the path.
NIST SP 800-207 §3.1
Subject
The combination of a user account and the device used to request access
In ZTA, a subject is not simply a user. It is the composite of a user account plus the specific device being used to access a resource. Neither element is trusted independently. Trust is computed as a function of both, along with session context. A trusted user on an unmanaged device — or a managed device with a compromised credential — results in reduced or denied access.
Subject components
USER
User identity
The IdP-verified identity of the human (or non-person entity) initiating the request. Includes MFA assertions, role memberships, entitlement attributes, and credential freshness. Sourced from IDMS.
DEVICE
Device posture
The health and compliance state of the endpoint. Managed devices carry a device certificate (PKI). CDM telemetry reports patch level, EDR status, OS compliance, and MDM enrollment. Unmanaged devices receive reduced access by policy.
AGENT
ZT agent (client-side PEP component)
Software on the device that intercepts resource access requests, enforces posture checks, communicates with the PEP/PA for authentication, and routes traffic through the authorized tunnel. Required for full ZTA enforcement on managed devices.
Non-person entities (NPEs) are subjects too
NIST explicitly includes service accounts, workloads, automated processes, and IoT devices as subjects. Each NPE must authenticate, present posture signals, and obtain session authorization just as a human user would. Service-to-service communication is not exempt from ZTA enforcement.
NIST SP 800-207 §2.1 T-01
Enterprise Resource
Any data source or service the enterprise protects — regardless of location or form factor
Tenet T-01 defines a resource broadly: any data source or computing service the enterprise cares about protecting qualifies. This includes on-premise applications, cloud services, APIs, databases, file shares, IoT sensors, printers, and personal devices used for enterprise work. The resource is always the destination being protected — the PEP sits in front of it, and the PE’s policy governs who can access it under what conditions.
Resource sensitivity classification
LOW
Low-sensitivity resources
General intranet content, read-only reference databases, non-personal productivity tools. May be accessible to managed and unmanaged devices with standard MFA. Session lifetimes can be longer.
MED
Medium-sensitivity resources
Internal collaboration platforms, HR self-service portals, customer data repositories. Requires managed device plus MFA. Behavioral anomalies trigger step-up auth more aggressively.
HIGH
High-sensitivity resources
Financial systems, privileged admin consoles, classified data stores, security tooling. Managed device required, hardware MFA preferred, short session lifetimes, real-time behavioral monitoring mandatory.
Resources must be dark outside the PEP
For ZTA to be effective, resources must not be reachable by any path that bypasses the PEP. In SDP deployments, resources are not publicly resolvable — they have no DNS entry or IP accessible outside the authorized tunnel. The PEP is the exclusive path.
NIST SP 800-207 §3.1.1 · §3.1.3
IDMS & PKI
Identity management + cryptographic verification — the two-layer trust anchor for all subject identity
Two distinct but tightly coupled components that together give the Policy Engine its authoritative answer to “who is this, and can I verify it cryptographically?” Without them, the PE has no trust anchor for identity — and in ZTA, unverified identity means no access, regardless of network location.
Identity Management System (IDMS) — §3.1.1
The IDMS is responsible for creating, storing, and managing identity information for all subjects. It is what the PE queries to resolve a claimed identity into a verified set of attributes.
IdP
Identity assertions
The authoritative binding of a credential to a subject, issued by the Identity Provider. The PE trusts the IdP’s assertion — not the credential the subject presents directly. Delivered as SAML assertions or OIDC tokens.
RBAC
Role and attribute data
Group memberships, entitlements, job function, clearance level, organizational unit. These map directly to the access policy rules the PE evaluates for each resource request.
MFA
MFA status & credential freshness
Whether the authentication event included a second factor, which factor type was used, and how recently it was completed. An MFA assertion 8 hours old carries less weight than one from 5 minutes ago.
PAM
Privileged account flags
PAM integration surfaces whether a subject is using a privileged account, whether it was checked out from a vault, and whether it has time-bounded access. Privileged sessions are higher-risk by policy regardless of other signals.
FED
Federated identity
For global enterprises, subjects may authenticate through partner IdPs or regional directories. IDMS handles federation (SAML, OIDC, SCIM) and presents a normalized assertion to the PE regardless of upstream source.
Public Key Infrastructure (PKI) — §3.1.3
PKI is the cryptographic verification layer beneath identity assertions. Where IDMS tells the PE who a subject claims to be, PKI lets the PE verify that claim is mathematically unforgeable. ZTA requires mutual authentication — the subject authenticates to the PE/PA, and the PE/PA authenticates back. PKI is the foundation of that mutual authentication.
CERT
Device certificates (X.509)
Every managed device carries an enterprise-issued certificate. The PEP validates this certificate during session establishment. This is the primary mechanism distinguishing managed from unmanaged devices.
OCSP
Certificate validity & revocation (OCSP/CRL)
The PE queries OCSP responders or checks CRLs in real time. A revoked certificate results in immediate denial regardless of all other signals — one of the fastest enforcement mechanisms in ZTA.
mTLS
Mutual TLS session authentication
All communication between subjects and the PEP uses mTLS. PKI issues the certificates that make mTLS work. A successful mTLS handshake is part of what the PE considers when determining session integrity.
Combined signal in the trust algorithm
| Signal | Source | What the PE learns |
|---|---|---|
| IdP assertion + MFA | IDMS | Who the user is, how strongly authenticated |
| Role & entitlement | IDMS | What they’re allowed to access by policy |
| Device certificate validity | PKI (OCSP) | Is this a managed, enterprise-issued device? |
| Certificate revocation status | PKI (CRL) | Has this device been removed from trust? |
| mTLS handshake success | PKI | Is the session cryptographically authentic? |
| Credential freshness | IDMS | How recently was identity asserted? |
Valid IdP assertion + revoked device cert = denied
The PE requires both signal layers to be clean. A valid identity assertion from a device with a revoked certificate is denied — the PKI failure overrides the identity assertion. A valid device certificate with a weak identity assertion (no MFA) is blocked for sensitive resources. Neither dimension can compensate for the other.
NIST SP 800-207 §3.1.2
CDM System
Continuous Diagnostics & Mitigation — real-time device posture for the Policy Engine
The CDM system provides the Policy Engine with continuous, real-time data about the current state of enterprise assets. Unlike a point-in-time compliance check at login, CDM is an ongoing telemetry stream. If a device’s posture changes mid-session — a patch becomes uninstalled, an EDR agent stops reporting, a new vulnerability is disclosed — CDM surfaces that change, and the PE can act on it.
What CDM feeds to the Policy Engine
PATCH
Software inventory & patch level
Current installed software versions, outstanding patches, and active CVEs. When a new critical vulnerability is disclosed, CDM correlates it against device software inventories and flags non-compliant devices immediately — without waiting for the next login.
EDR
Endpoint Detection & Response status
Whether the EDR agent is active and reporting, last scan timestamp, active alerts, and detection events. An EDR agent that goes silent is treated as a posture failure — the PE reduces trust for that device until it resumes reporting.
MDM
MDM enrollment & compliance state
Whether the device is enrolled in MDM, current compliance (screen lock, encryption, approved app list), and MDM-reported health. Unenrolled devices are treated as unmanaged regardless of user identity strength.
CERT
Certificate & configuration state
Enterprise certificate presence and validity on the device. Configuration compliance: firewall enabled, disk encryption active, approved browser/runtime versions, no unauthorized remote access tools.
IoC
IoC correlation
CDM correlates device process, file, and network telemetry against threat intelligence IoC feeds. A device running a process matching a known malware hash, or communicating with a C2 domain, is flagged as compromised immediately.
CDM is Tenet T-05 in practice
Tenet T-05 requires the enterprise to monitor and measure the integrity of all assets continuously — not at login time, but throughout the asset lifecycle. CDM is the infrastructure that makes T-05 operational. It transforms the abstract principle of continuous monitoring into a concrete data feed the PE can act on in real time.
NIST SP 800-207 §3.1.4
Threat Intelligence
External context that adjusts the Policy Engine’s trust score in real time
Threat intelligence is one of the external data sources the PE consults at the moment of access evaluation — not as a post-incident tool, but as a live signal that shapes the trust score before a session is granted. The PE doesn’t store or generate threat intel; it queries external feeds as part of the trust algorithm alongside CDM, identity, and behavioral data. It is the PE’s window into the broader threat landscape it couldn’t derive from enterprise telemetry alone.
What the Policy Engine consumes
IP/DOM
IP and domain reputation
If a subject’s observed egress or the resource being requested is associated with known malicious infrastructure, the PE factors that into the trust score. A request from a TOR exit node or recently-flagged ASN raises risk even if identity and device signals are clean.
IoC
Indicator-of-compromise feeds
Hashes, signatures, and behavioral patterns associated with known malware or attack tooling. When combined with a CDM hit (device running matching process), the PE denies or steps down access immediately.
CVE
Vulnerability intelligence
CVE feeds correlated against device software inventory from CDM. A device running an actively-exploited unpatched vulnerability gets reduced trust even if its posture check otherwise passes. PE response scales with CVSS score and exploit availability.
SIEM
SIEM correlation output
The most dynamic input. The SIEM aggregates activity log telemetry and correlates against threat patterns in near-real time. When a rule fires — credential stuffing, impossible travel, lateral movement — the SIEM surfaces an elevated risk signal to the PE immediately.
Impact on trust score
No threat signal
Neutral weight. Other signals dominate. Access proceeds normally if all other factors pass.
Low-confidence hit
E.g., shared IP on a blocklist. PE may still grant access but require step-up MFA, or flag the session for enhanced monitoring.
High-confidence hit
E.g., device IoC match or SIEM anomaly correlation. PE denies access or revokes an active session; PA commands PEP to terminate the tunnel immediately.
The continuous feedback loop
Threat intelligence isn’t evaluated once at login. The activity log feeds the SIEM, the SIEM correlates against threat feeds, and if the risk picture changes mid-session, that signal flows back to the PE. The PE re-evaluates, the PA issues a revoke command, and the PEP tears down the tunnel — without waiting for the session to end. This is what makes Tenet T-06’s requirement for “dynamic” authorization operationally meaningful.
NIST SP 800-207 §3.1.4
Activity Log
The enterprise’s behavioral memory — audit, analytics, and Policy Engine feedback
The activity log is what NIST §3.1.4 describes as the enterprise’s mechanism for collecting and storing all network traffic and access request data — not as a passive audit trail, but as an active input to the trust algorithm. The PE’s access decisions improve over time as behavioral baselines accumulate. The activity log is the memory that makes that possible.
What the PEP reports
SESSION
Per-session telemetry
Source identity and device, timestamp, resource requested, session token used, bytes transferred, session duration, and termination reason (normal close, revocation, timeout, anomaly). The raw record of every authorized access event.
ANOMALY
Anomaly indicators
Unusual access times, atypical data volumes, lateral movement patterns (single subject hitting many resources in sequence), protocol deviations, new destination IPs mid-session, sudden changes in access velocity.
AUTH
Authentication events
MFA challenges issued, step-up auth triggers, failed authentication attempts, and credential anomalies detected mid-session. Critical inputs for UEBA behavioral baseline modeling.
POLICY
Policy evaluation results
Every grant, deny, and revocation the PEP enforces, along with which policy rule triggered it. The audit trail for compliance and the dataset for policy refinement over time.
Where the telemetry flows
Back to the Policy Engine
The PE uses historical behavioral data as one of its five trust algorithm inputs. A subject whose access patterns match their historical baseline gets higher trust; anomalies suppress it.
To SIEM / UEBA
Activity logs are routed to security analytics tools for correlation with threat intelligence. When a SIEM rule fires, the elevated risk signal flows to the PE for re-evaluation — triggering mid-session revocation if needed.
Tenet T-07 — the activity log is its implementation
NIST §2.1 T-07 states the enterprise must “collect as much information as possible about the current state of assets, network infrastructure and communications and use it to improve its security posture.” ZTA isn’t a static gate — it’s a continuously learning system. The PEP’s telemetry flowing into the activity log closes that loop.
NIST SP 800-207 §3.3 · §3.4
Trust Algorithm
How the Policy Engine computes a trust score and renders an access decision
The trust algorithm is the core computational function of the PE. It takes multiple input signals, scores them against access policy thresholds, and produces a confidence level for the subject-device-resource tuple. NIST §3.3 describes this as a function of observable information about subjects, devices, and the enterprise environment evaluated against policy rules. The result produces a confidence level that maps to grant, deny, or step-up — not a simple binary.
Five input signals
IDENTITY
Subject identity & credentials
IdP-asserted identity, MFA status and factor type, credential freshness, privileged account flags, federated assertions. The strongest identity signal combines a hardware MFA factor with a recently-issued IdP assertion.
DEVICE
Device health & posture
CDM telemetry: patch level, EDR status, device certificate validity, OS compliance, MDM enrollment. Often binary in practice — managed and compliant, or not.
NETWORK
Network location & context
Source IP, geolocation, time-of-day, network path. Contextual signal only. It modulates other signals (anomalous location reduces trust) but cannot on its own grant or deny access.
RESOURCE
Resource sensitivity
Data classification, criticality, required assurance level. A high-sensitivity resource raises the thresholds all other signals must meet. A low-sensitivity resource permits weaker signals to succeed.
BEHAVIOR
Behavioral & threat intelligence
UEBA baselines, historical patterns, threat feed hits, SIEM correlation. The dynamic signal — continuously updated, triggers mid-session re-evaluation when it changes significantly.
Access outcomes
Grant access
All signals pass their respective thresholds for the resource requested. PA issues a session token to the PEP. Access scope is limited to the minimum required per Tenet T-03.
Deny access
One or more signals fail their threshold: unregistered device, missing MFA, anomalous behavior, IoC match, policy violation, or resource classification exceeds subject clearance. No token issued.
Step-up authentication
Trust score is borderline, or context has changed mid-session. PE requires an additional authentication factor. If the subject satisfies the step-up, access continues. If not, the session is denied or terminated.
Policy constraints — §3.4
IDENTITY
No access without verified MFA-asserted identity
Access is denied if the subject cannot present a current, IdP-verified assertion with MFA satisfied. Password-only authentication does not meet the threshold for any non-trivial resource.
DEVICE
Unmanaged devices receive reduced or no access to sensitive resources
The device signal is a hard gate for high-sensitivity resources. An unmanaged device cannot satisfy the device threshold regardless of identity strength.
NETWORK
Network location cannot substitute for identity or device trust
Being on the corporate LAN does not reduce identity or device requirements. No implicit trust from network proximity — Tenet T-02 is a hard constraint.
RESOURCE
Access scope bounded to minimum necessary
The session token is scoped to the specific resource and action requested. Over-provisioning is a policy violation. Least-privilege is enforced at the token level.
BEHAVIOR
All decisions and session activity are logged
Every grant, deny, and revocation is recorded. Both a compliance requirement and the data that continuously improves the behavioral baseline used in future trust evaluations.
NIST SP 800-207 §3.0
Control & Data Planes
The architectural separation that makes ZTA enforcement tamper-resistant
One of ZTA’s most critical architectural properties is the strict separation of the control plane from the data plane. The control plane carries policy decisions, session tokens, and revocation commands. The data plane carries user traffic. They share no channel. A compromised subject on the data plane has no visibility into — and no ability to interfere with — the control plane signals that govern their own access.
Control plane
Policy & trust signaling
PE→PA trust decisions — computed grants or denials passed from Policy Engine to Policy Administrator
PA→PEP command channel — session establishment and termination commands, out-of-band from all user data
Subject authentication flows — identity verification, MFA challenges, device posture attestation
CDM & IDMS feeds — continuous device telemetry and identity data for dynamic PE re-evaluation
Mutually authenticated, TLS 1.3+ — all control plane communications are encrypted and mutually authenticated
Data plane
Resource access traffic
Subject ↔ Resource traffic — all application, API, data, and service communication after authorization
PEP as the exclusive boundary — the PEP sits inline; no path to resources exists outside the PEP, regardless of network topology
Session tokens enforced — the PEP validates the PA-issued token for every resource transaction
Continuous monitoring — all data plane traffic is logged; anomalies trigger control plane re-evaluation
Encrypted in transit — network location does not grant trust regardless of underlying encryption state
Why the separation matters
If the control and data planes were co-mingled, a compromised session could observe PA commands, replay session tokens, or inject false telemetry into the activity log. The separation ensures that even a fully compromised endpoint can only affect its own session — and that session can be revoked by the PA the moment the PE detects the compromise from CDM or SIEM signals, because that revocation command travels on a channel the compromised device cannot touch.
NIST SP 800-207 §3.1
Deployment Models
Three NIST-defined approaches — not mutually exclusive, most mature deployments combine all three
NIST §3.1 defines three deployment approaches, each emphasizing a different primary enforcement mechanism. The approaches are defined by where and how the PEP function is implemented, not by vendor. Most enterprises combine elements of all three.
🪪
Identity-based segmentation
Enhanced identity governance
Access policy based primarily on the identity of the user or service. Network location is insufficient for access decisions. The IdP and PAM system are the primary enforcement infrastructure.
- Strong IdP, PAM, and MFA enforced universally
- Least-privilege assigned per-role, per-session
- Service accounts governed identically to users
- Federated identity (SAML, OIDC) for external users
- Best fit: enterprises with mature IAM programs
🔬
Micro-segmentation
Workload & network segmentation
Individual workloads placed in separate micro-segments with independent security gateways. Each segment enforces access policy independently, limiting blast radius of any single compromise.
- NGFWs or SDN-based policy enforcement
- East-west traffic controlled at workload level
- Policy applied at network, OS, and app layers
- Eliminates implicit trust from network adjacency
- Best fit: data centers and cloud workloads
🌐
Software-defined perimeter
Network-based (SDP / ZTNA)
Network infrastructure acts as a policy enforcement agent. Dynamic, per-session tunnels connect authenticated subjects to authorized resources only. Resources are dark to unauthenticated subjects.
- ZTNA overlay replaces traditional VPN perimeter
- Resources have no publicly-resolvable presence
- Per-session tunnels scoped to identity + device posture
- Centralized PE/PA controls distributed PEPs
- Best fit: remote access and multi-cloud environments
Combining all three
Most mature ZTA implementations combine all three deployment models. ZTNA / SDP handles north-south remote access, microsegmentation addresses east-west workload isolation, and identity governance with application-layer controls enforces fine-grained access policy — each model targeting a distinct attack surface.
NIST SP 800-207 §3.0 — Structural view
Logical Architecture
Component groupings, trust relationships, and plane boundaries
This diagram organises the NIST §3.0 components into three structural tiers: supporting infrastructure that feeds signals to the decision engine, the ZTA core (PE + PA) that computes and dispatches decisions, and the enforcement path where subjects traverse the PEP to reach resources. Arrows show the direction of authority and data — not network routing.
Structural hierarchy — click any component to navigate · arrows show authority and data direction, not network routing
Reading the diagram
Tier 1 feeds the Policy Engine with real-time signals — identity assertions from IDMS/PKI, device posture from CDM, external threat context, and behavioral feedback from the activity log. None of these components enforce access on their own; they are data providers.
Tier 2 is the decision and dispatch layer. The PE evaluates all incoming signals and produces a trust score. It passes its decision to the PA, which operationalizes it by commanding the PEP. The PE and PA share no data-plane visibility — they operate exclusively on the control plane.
Tier 3 is the enforcement path. The Subject’s ZT agent initiates a request; the PEP intercepts, validates the session token issued by the PA, and either routes traffic to the resource or terminates it. The PEP then streams session telemetry back to the Activity Log, closing the feedback loop into Tier 1.
NIST SP 800-207 §3.0 — Dynamic view
Access Request Data Flow
Step-by-step lifecycle of a single access request — from initiation to session or denial
This diagram traces the full lifecycle of an access request through the ZTA — from the subject initiating the request through authorization, enforcement, and the continuous monitoring feedback loop that can trigger mid-session revocation. Steps are numbered in sequence. The control plane (top swim lane) and data plane (bottom swim lane) are shown separately.
Full access request lifecycle · control plane (top) separated from data plane (bottom) · mid-session revocation shown via feedback loop
Key flows to note
Steps 1–2 (Subject lane): The subject’s ZT agent intercepts the access request before it ever reaches the network. It performs local posture checks and initiates the authentication flow — the request cannot proceed without this gate.
Steps 3–6 (Control plane): The authentication flow goes to the PA, which hands off to the PE. The PE queries IDMS, CDM, and Threat Intel in parallel — these are concurrent signal lookups, not a sequential chain. The PE then computes a trust score and produces a Grant or Deny decision.
Steps 7–8 (Data plane enforcement): A Grant decision causes the PA to issue a session token to the PEP. The PEP validates that token and permits traffic to flow to the resource within the authorized scope. A Deny means no token is issued and the request is blocked at the agent.
Steps 9–10 (Feedback loop): Throughout the active session, the PEP streams telemetry to the Activity Log. The SIEM correlates this against threat feeds and behavioral patterns. If an anomaly fires, the signal flows back to the PE for re-evaluation — which can trigger a Revoke command from the PA to the PEP, tearing down the session immediately. This is what makes ZTA dynamic rather than static.
Mid-session revocation is architectural, not optional
The feedback loop from the PEP through the Activity Log and SIEM to the PE isn’t a nice-to-have — it’s how ZTA satisfies Tenet T-06’s requirement that authentication and authorization are “dynamic and strictly enforced.” Without this loop, ZTA grants access once at login and then has no mechanism to respond to changing risk during the session — which is exactly the failure mode of traditional VPN-based architectures.
Source document
NIST SP 800-207
Zero Trust Architecture — Final, August 2020
About this document
NIST Special Publication 800-207 defines Zero Trust Architecture (ZTA) and provides guidance for federal agencies and enterprises planning a ZTA migration. It establishes the seven tenets of Zero Trust, defines the logical components (PE, PA, PEP), describes supporting infrastructure, and outlines three deployment models. This reference app is based on the Final version published August 2020.
Full citation: Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture (NIST Special Publication 800-207). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207