"Never trust, always verify" is a slogan. NIST and CISA published the architecture and maturity model that turn it into something an architect can design against. This lesson covers both, briefly enough to use as a reference.
NIST SP 800-207: Zero Trust Architecture
NIST Special Publication 800-207, published August 2020, is the formal definition. It is short, free, and worth reading directly. Two takeaways matter most: the seven tenets, and the PDP/PEP logical model.
The Seven Tenets
- All data sources and computing services are considered resources. Not just databases — APIs, SaaS apps, IoT, on-prem servers, cloud workloads.
- All communication is secured regardless of network location. Encryption in transit is mandatory inside the corporate network, not just at the perimeter.
- Access to individual enterprise resources is granted on a per-session basis. Trust is short-lived and resource-specific.
- Access to resources is determined by dynamic policy. Including observable state of identity, application, and the requesting asset.
- The enterprise monitors and measures the integrity and security posture of all owned and associated assets. Continuous evaluation.
- All resource authentication and authorization are dynamic and strictly enforced before access is allowed. Authenticate-once, access-forever does not exist.
- The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications, and uses it to improve security posture.
If you remember nothing else: per-session, per-resource, dynamic, monitored.
The PDP / PEP Model
NIST describes a logical architecture with three roles:
| Component | Role | Examples |
|---|---|---|
| Policy Engine (PE) | Decides whether access is granted, using identity, device, context, and threat signals | Azure Entra Conditional Access engine, Okta policy engine, OPA |
| Policy Administrator (PA) | Establishes or terminates the session based on the PE's decision; issues tokens | Identity provider STS, ZTNA broker |
| Policy Enforcement Point (PEP) | Actually allows or blocks the connection | ZTNA proxy, API gateway, service mesh sidecar, host firewall, application middleware |
The PE and PA together form the Policy Decision Point (PDP) — usually the control plane of your identity provider. The PEP is wherever traffic is intercepted.
The signals the PE consumes come from supporting systems: a CDM (Continuous Diagnostics and Mitigation) feed, threat intelligence, the SIEM, the ID management system, the device-inventory and posture system, PKI, and activity logs. Each adds a dimension to "is this request OK right now."
Three Deployment Approaches
NIST also names three architecture variants:
- Enhanced Identity Governance — identity is the strongest signal; access policy is enforced primarily at the application layer. Common in SaaS-heavy organisations.
- Microsegmentation — network gateways enforce policy between fine-grained zones. Common in regulated industries with heavy on-prem.
- Network Infrastructure and Software-Defined Perimeters — overlay networks (SDP, BeyondCorp-style) dynamically establish encrypted tunnels per session. The path most ZTNA vendors take.
In practice mature deployments combine all three.
The CISA Zero Trust Maturity Model
CISA's Zero Trust Maturity Model, v2 published April 2023, is the planning tool. It defines:
Five Pillars
| Pillar | What it covers |
|---|---|
| Identity | Authentication, identity stores, MFA, risk-based access |
| Devices | Inventory, compliance, EDR, supply-chain assurance |
| Networks | Segmentation, traffic encryption, network resilience |
| Applications & Workloads | App access, secure software development, app threat protection |
| Data | Inventory, categorisation, encryption, DLP, access control |
Three Cross-Cutting Capabilities
- Visibility and Analytics — telemetry across every pillar feeding into a SIEM/SOAR
- Automation and Orchestration — policy as code, automatic remediation
- Governance — policy lifecycle, compliance, risk management
Four Maturity Stages
| Stage | What it looks like |
|---|---|
| Traditional | Perimeter security, manual processes, static policies, isolated tools |
| Initial | Some automation, basic visibility, starting to centralise identity and policy |
| Advanced | Coordinated policy across pillars, integrated identity, increased automation, dynamic context-aware decisions |
| Optimal | Fully automated, continuous, adaptive policies; cross-pillar integration; just-in-time access |
The honest reality: most enterprises sit between Traditional and Initial across most pillars. A pragmatic Zero Trust programme typically targets Advanced in 3-5 years across critical pillars, accepting that Optimal is aspirational.
Example: A Maturity Snapshot
What "Initial" vs "Advanced" Identity looks like:
| Capability | Initial | Advanced |
|---|---|---|
| Authentication | MFA on cloud apps, password + OTP for legacy | Phishing-resistant MFA (FIDO2, WebAuthn) everywhere; passwordless default |
| Identity stores | Two or three directories partially synced | Single source of truth; consolidated identity governance |
| Risk assessment | Periodic access reviews; some risk signals at login | Continuous, real-time risk scoring; automatic step-up and revocation |
| Access management | Role-based, mostly static | Attribute-based, just-in-time, ephemeral credentials |
The same exercise applies to each pillar. CISA's PDF contains the full grid — bring it to your roadmap workshop.
How to Actually Use These Documents
- Assessment. Score yourself against each pillar at each maturity stage. Be honest. Pick the worst row in each pillar as your starting maturity.
- Prioritisation. Identity almost always pays back first. Devices second. Network and data follow.
- Roadmap. Break the journey into 6-month increments. Each should move at least one pillar up one stage.
- Vendor mapping. Map products to the pillar capabilities they implement. Resist buying a product that covers an already-mature pillar.
- Governance. Stand up a Zero Trust steering group with security, network, identity, and platform engineering represented. Without this, you get tool sprawl, not architecture.
The rest of this course walks through each pillar in depth and ends with the practical adoption roadmap.