Zero Trust Architecture (ZTA) is the way an organization designs its network, identity, devices, applications, and data around zero trust principles. NIST SP 800-207, published in August 2020, defines it as an approach where network location or asset ownership alone grants no implicit trust, and where authentication and authorization of the user and the device happen as separate steps before a session to a resource begins. In short, you protect individual resources, not just the network segment they sit in. If you are new to the idea, start with What Is Zero Trust, and Where Should You Start?, then come back here for the architecture.
The core ideas behind ZTA
NIST SP 800-207 describes zero trust through a set of tenets. In plain language:
- Everything is a resource: data sources, services, and devices are all things to protect
- Secure all communication, regardless of network location
- Grant access per session, to one resource at a time
- Decide access with dynamic policy that considers identity, application, device state, and behavior
- Monitor the posture of all assets, owned or not, and act on what you see
- Authenticate and authorize every time, strictly, before access is allowed
- Collect as much information as you can about assets, traffic, and access, and use it to improve policy
The logical components
A ZTA separates the decision about access from the enforcement of it. NIST describes three core logical components:
- Policy Engine (PE): makes the grant or deny decision using enterprise policy and signals from other sources
- Policy Administrator (PA): carries out that decision by establishing or tearing down the communication path, for example by issuing a session token or credential
- Policy Enforcement Point (PEP): sits in front of the resource and enables, monitors, and ends the connection
The PE and PA together are often called the Policy Decision Point. The decision draws on supporting systems: identity management, device posture and monitoring, threat intelligence, activity logs, and data access policies.
The result is a loop rather than a one-time check. A request goes through the PEP, the decision point evaluates identity, device health, and context, a session opens only for the allowed resource, and the signals are re-evaluated while the session continues.
The five pillars
CISA's Zero Trust Maturity Model (version 2.0) organizes the work into five pillars, with three capabilities that cut across all of them. This is the most practical way to divide ownership and plan projects:
- Identity: strong authentication, single sign-on, least privilege, and lifecycle management for people and service accounts
- Devices: inventory, health and compliance checks, and endpoint protection
- Networks: segmentation, encrypted traffic, and per-application access instead of broad network access
- Applications and workloads: secure development, per-application authorization, and protection of cloud workloads
- Data: classification, encryption, access control, and monitoring of data movement
The cross-cutting capabilities are visibility and analytics, automation and orchestration, and governance.
Three common deployment approaches
NIST describes several ways to build a ZTA. Most real programs combine them:
- Enhanced identity governance: access decisions center on identity and attributes. A good fit when identity is your strongest control and most resources are cloud or SaaS
- Micro-segmentation: place resources in small segments protected by gateways or host-based controls. Useful in data centers and for protecting critical systems
- Network-based or software-defined perimeter: users and devices connect only to the resources they are approved for, often delivered as ZTNA (zero trust network access). A common replacement for broad VPN access
ZTNA is one technology that supports ZTA, not the whole architecture. Buying a ZTNA product does not by itself deliver zero trust.
Maturity stages
CISA's model describes four stages for each pillar: traditional, initial, advanced, and optimal. As a rule of thumb, early stages rely on manual configuration and static policy, and later stages integrate pillars, use more automation, and make decisions with dynamic, real-time signals. Use the stages to set honest targets per pillar, since few organizations are at the same level everywhere.
Strengths and limitations
- Strengths: limits lateral movement after a compromise, fits remote work, cloud, and partner access better than a perimeter, improves visibility into who accesses what, and supports compliance evidence
- Limitations: it takes sustained effort rather than a single project, legacy and OT systems may not support modern authentication, stricter checks can add user friction, and it needs skilled people and good asset and identity data
- Design risk: the decision point becomes critical infrastructure, so plan high availability and a safe failure behavior. A compromised decision point is a high-value target
- Marketing risk: no single product is "zero trust in a box". Ask which pillars and which tenets a product actually supports
A practical roadmap
NIST's NCCoE published SP 1800-35 in June 2025, with 19 example implementations of ZTA built with industry collaborators, which is a useful reference for real designs. A general order that works for most organizations is below.
- Define what you protect: inventory users, devices, applications, and data, and rank by criticality
- Strengthen identity first: phishing-resistant MFA where possible (see Which MFA Is Safer?), SSO, and least privilege
- Know your devices: inventory and check health before granting access
- Move to per-application access and segment critical systems: start with a few key applications
- Protect the data: classify, encrypt, and monitor the most sensitive data
- Monitor, automate, and improve: collect signals, tune policy, and automate responses
For plants and control systems, apply the same ideas with care for safety and availability. See Zero Trust for OT: Adapting It Without Disrupting the Plant.
Start today
- List your crown jewels: the five systems or data sets whose compromise would hurt most
- Check identity basics: MFA coverage, stale accounts, and over-privileged admins
- Pick one application and move it from network-wide access to per-application access
- Score yourself per pillar against the CISA stages, with the self-assessment as a starting point
- Rehearse changes in a lab before enforcing them. See Network and Cyber Security Simulators: Types and Uses
Common mistakes
- Treating zero trust as a product purchase: it is an architecture and a program
- Trying to change everything at once: pick high-value applications and expand
- Ignoring legacy systems: plan compensating controls such as segmentation and strict access paths
- Forgetting availability of the decision point: an outage there can lock everyone out
- Neglecting user experience: friction pushes people to workarounds
- Skipping measurement: without logs and metrics you cannot tune policy or show progress
The identity pillar of Zero Trust combines several capabilities that do different jobs. See the comparison in IAM vs IGA vs PAM vs CIEM.
For a phased how-to on the micro-segmentation approach, see Network Segmentation and Micro-segmentation: Start Safely.
The identity pillar covers service accounts as well; see Non-human Identities: The Overlooked Service Account Risk.
Phishing-resistant authentication is a foundation of the identity pillar. Read how passkeys work in Passkeys and FIDO2 Explained: Beyond Passwords.
When you want to choose cloud-delivered network and security services to support the network and identity pillars, see SASE and SSE Explained: When Each One Fits.
How per-app access with ZTNA compares with a VPN, and how to harden the existing VPN during migration, is covered in ZTNA vs VPN: Which Should You Choose?.
Digital certificates are part of how machines and services prove who they are. See Certificate Lifecycle Management in the 47-Day Era.
Data is one pillar of Zero Trust, and it starts with knowing how important each piece of data is. See how in Data Classification: A Practical How-to Guide.
Device state and configuration are among the signals used to decide access. For how to start hardening device settings, see Endpoint Hardening with CIS Benchmarks: Where to Start.
Before designing on the cloud, know which parts the provider and your organization each secure. See Cloud Shared Responsibility Model: Who Secures What.
References and further reading
- NIST SP 800-207: Zero Trust Architecture
- NIST SP 1800-35: Implementing a Zero Trust Architecture: 19 example implementations
- CISA Zero Trust Maturity Model: five pillars, three cross-cutting capabilities, four maturity stages
- OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
- NCSC: Zero trust architecture design principles