Zero Trust Architecture

Key Control Areas

• Identity Verification and Continuous Authentication (IA-02, IA-04, IA-05, IA-08, IA-12): Identity is the foundation of zero trust -- the new perimeter. IA-02 mandates multi-factor authentication for all users accessing any resource, eliminating single-factor password-only access that enables credential stuffing and phishing attacks. IA-04 manages identifier lifecycle including provisioning, de-provisioning, and preventing reuse of stale identities. IA-05 governs authenticator management: credential strength, rotation, and protection against compromise. IA-08 extends identity verification to non-organisational users -- contractors, partners, federated identities -- ensuring external access decisions are made with the same rigour as internal ones. IA-12 provides identity proofing, establishing that the person behind the credential is who they claim to be. Implementation requires consolidating identity providers, deploying phishing-resistant MFA (FIDO2/WebAuthn), and implementing continuous session re-evaluation rather than authenticate-once-trust-forever.
• Access Control and Least Privilege Enforcement (AC-02, AC-03, AC-04, AC-05, AC-06, AC-07, AC-17, AC-20): Access control in zero trust is dynamic, context-aware, and enforced at every resource boundary. AC-02 manages accounts across their lifecycle with automated provisioning and just-in-time access. AC-03 enforces access based on policy -- not network location -- using attributes including identity, device posture, time, geolocation, and risk score. AC-04 controls information flow between security domains, preventing data movement that violates policy even when the user has legitimate access to both endpoints. AC-05 separates duties to prevent single-actor compromise of critical workflows. AC-06 enforces least privilege: users and services receive only the minimum access required for the current task, with privileges revoked immediately when no longer needed. AC-07 limits failed access attempts, feeding signals to the trust engine. AC-17 governs remote access -- in zero trust, all access is treated as remote, eliminating the privileged-internal-network assumption. AC-20 controls access from external systems and BYOD devices.
• Network Segmentation and Microsegmentation (SC-07, SC-32, AC-04, SC-08, SC-39): Network controls in zero trust shift from perimeter firewalls to fine-grained microsegmentation. SC-07 enforces boundary protection at every trust boundary -- not just the network edge but between every workload, service, and data store. SC-32 creates system partitions that isolate components by function, sensitivity, and trust level. AC-04 controls information flow at the network layer, enforcing east-west traffic policies that prevent lateral movement even after a workload is compromised. SC-08 mandates encryption of all data in transit -- zero trust assumes the network is hostile, so TLS/mTLS is required for all communications including internal traffic. SC-39 provides process isolation, ensuring that compromised processes cannot access resources belonging to other trust domains. Implementation typically uses software-defined networking, service mesh (mTLS between services), and identity-aware proxies that replace traditional VPN concentrators.
• Continuous Monitoring, Analytics, and Trust Scoring (SI-04, AU-02, AU-03, AU-06, AU-12, CA-07): Zero trust requires continuous visibility into all access patterns, device behaviour, and network flows. SI-04 provides real-time monitoring of systems for anomalous behaviour that may indicate compromise -- unusual access patterns, impossible travel, privilege escalation attempts. AU-02 defines auditable events: every access decision, policy evaluation, authentication event, and trust score change must be logged. AU-03 specifies record content: who, what, when, where, from which device, with what trust score, and what decision was made. AU-06 analyses audit records to detect patterns that indicate advanced persistent threats, credential compromise, or insider threat. AU-12 generates audit records at policy decision and enforcement points. CA-07 provides continuous monitoring that feeds the trust engine, enabling real-time policy adaptation. The trust engine aggregates signals from identity providers, EDR, SIEM, threat intelligence, and device management to compute dynamic trust scores that drive access decisions.
• Device Trust and Endpoint Posture (CM-02, CM-06, CM-08, SI-07, CM-03): Device posture is a critical input to every access decision. CM-02 establishes baseline configurations that define a healthy endpoint: patched OS, active EDR, encrypted disk, no jailbreak/root. CM-06 enforces security configuration settings and validates them continuously -- not just at enrollment but at every access request. CM-08 maintains a real-time inventory of all devices, their ownership, compliance status, and last-seen posture. SI-07 verifies software and firmware integrity, detecting tampering that could indicate rootkit installation or supply chain compromise. CM-03 controls configuration changes, ensuring that devices that drift from baseline have their trust score reduced and access restricted until remediation. Unmanaged and non-compliant devices receive limited or no access -- they can reach a remediation portal but nothing else.
• Data Protection and Classification (SC-13, SC-28, MP-02, AC-21, SI-12): Data is what zero trust ultimately protects. SC-13 mandates approved cryptographic mechanisms for protecting data at rest and in transit -- in a zero trust model, encryption is non-negotiable because no network segment is trusted. SC-28 protects data at rest with encryption keyed to the data classification and access policy. MP-02 restricts access to digital media containing sensitive data. AC-21 enables controlled information sharing between authorised parties while enforcing classification-based policy -- users can share within policy but the system prevents sharing that violates data governance rules. SI-12 governs information management and retention, ensuring data lifecycle controls are enforced regardless of where data resides. Implementation requires data classification (at minimum: public, internal, confidential, restricted), encryption everywhere, and DLP integration at policy enforcement points.
• Policy Decision and Enforcement Architecture (AC-01, PL-02, PM-14, CA-02, SA-08): The policy engine is the brain of zero trust. AC-01 defines access control policy that governs all decisions -- this policy must be machine-readable, version-controlled, and continuously audited. PL-02 establishes the security architecture plan including trust boundaries, PDP/PEP placement, and integration patterns. PM-14 implements a continuous monitoring programme that tests and validates policy effectiveness. CA-02 provides security assessments of the zero trust architecture itself, ensuring that policy decisions are correct and enforcement points cannot be bypassed. SA-08 mandates security engineering principles in the design of PDP/PEP components: fail-closed design, separation of policy from enforcement, and resilience against single points of failure. The PDP evaluates each request against identity, device, context, and data sensitivity to produce an allow/deny/step-up decision. The PEP enforces that decision as close to the resource as possible.
• Incident Response and Automated Containment (IR-04, IR-05, IR-06, IR-08, SC-07): Zero trust transforms incident response from manual containment to automated, policy-driven isolation. IR-04 handles incidents by automatically adjusting trust scores and access policies -- a compromised credential triggers immediate session revocation and re-authentication across all active sessions. IR-05 provides continuous incident monitoring through the trust engine, which correlates anomalous signals across identity, network, and endpoint telemetry. IR-06 automates incident reporting to SOC analysts with full context: the access decision chain, trust score history, and correlated events. IR-08 defines incident response plans specific to zero trust failure modes: PDP compromise, PEP bypass, trust engine poisoning, and identity provider breach. SC-07 enables dynamic boundary reconfiguration during incidents -- microsegmentation policies can be tightened in real-time to contain blast radius without manual firewall rule changes.

When to Use

This pattern applies to any enterprise that has moved beyond the assumption that internal networks are safe. It is particularly relevant for organisations with significant remote or hybrid workforces, cloud-first or multi-cloud strategies, high-value data requiring granular access control, regulatory requirements for continuous monitoring and least privilege, a history of lateral movement in security incidents, merger or acquisition activity creating heterogeneous network environments, or contractor and third-party access that extends beyond the traditional perimeter.

When NOT to Use

This pattern may be premature for organisations that lack basic security hygiene: if you do not have centralised identity management, asset inventory, or patch management, zero trust adds complexity without a foundation to build on. Air-gapped environments with strict physical access controls may derive limited benefit from the network-assumes-hostile model. Very small organisations (under 50 users) with simple network topologies may find the architectural overhead disproportionate to the risk reduction. Operational technology (OT) and industrial control systems often cannot support continuous authentication and may require purpose-built patterns (see SP-023).

Typical Challenges

Legacy applications that require network-level trust and cannot support modern authentication protocols are the primary blocker -- they require application proxies or gateway translation layers. The cultural shift from 'inside the firewall means trusted' to 'verify everything' faces resistance from users accustomed to frictionless internal access. VPN replacement is politically difficult when remote access 'just works' for users. Microsegmentation at scale generates enormous policy complexity -- without automation, rule sets become unmanageable. Device diversity (corporate, BYOD, contractor, IoT) makes uniform posture enforcement impractical; tiered access models add design complexity. Trust engine tuning requires balancing security (low trust thresholds) against usability (constant re-authentication prompts). Cost of deployment is front-loaded while benefits accrue gradually, making business case justification difficult. Multi-cloud and hybrid environments complicate consistent policy enforcement across trust boundaries.

Threat Resistance

Zero Trust Architecture addresses the full spectrum of post-perimeter threats. Lateral movement after initial compromise is contained by microsegmentation and per-resource authentication (SC-07, SC-32, AC-03). Credential theft and replay attacks are mitigated by continuous authentication, short-lived tokens, and phishing-resistant MFA (IA-02, IA-05, SC-08). Insider threats are detected through behavioural analytics and anomaly detection in the trust engine (SI-04, AU-06). Privilege escalation is prevented by dynamic least privilege and just-in-time access (AC-06, AC-02). Man-in-the-middle attacks on internal networks are eliminated by mandatory mTLS for all communications (SC-08). Compromised endpoints are contained by continuous posture assessment that revokes access when devices drift from baseline (CM-02, CM-06). Data exfiltration through trusted channels is prevented by information flow enforcement and DLP at policy enforcement points (AC-04, AC-21). Session hijacking is mitigated by continuous session validation and context-aware re-authentication (AC-12, IA-02). API abuse is controlled by per-request authorisation at the PEP layer (AC-03, AC-04). Trust boundary bypass attempts are detected by monitoring PDP/PEP integrity and policy consistency checks (CA-07, SI-07).

Assumptions

The organisation has consolidated identity providers to a manageable number (ideally one primary IdP with federation). Network infrastructure supports software-defined segmentation (not solely hardware-based ACLs). Endpoint management capability exists for corporate devices (MDM/UEM). Applications support modern authentication protocols (OAuth 2.0, OIDC, SAML). The organisation has defined data classification policies. Security operations capability exists to monitor and respond to trust engine signals. Executive sponsorship exists for the cultural shift from trusted-network to verify-everything.

Developing Areas

• Zero trust maturity measurement frameworks are still being standardised. CISA's Zero Trust Maturity Model (ZTMM) v2.0 provides the most widely referenced assessment framework, but organisations report difficulty mapping their hybrid architectures to CISA's five-pillar model, particularly when legacy systems span multiple maturity levels simultaneously. Competing frameworks from Forrester, Gartner, and vendor-specific models create confusion, and no industry-accepted certification or audit standard for zero trust exists -- organisations cannot yet demonstrate zero trust compliance to regulators or customers through a standardised assessment.
• Legacy system integration with zero trust architectures is the primary practical barrier to adoption. Applications that rely on network-level trust (IP-based access control, internal-only APIs without authentication, legacy protocols like SMB and RPC) cannot participate in identity-centric access decisions without intermediary proxies or gateway translation layers. Organisations with large estates of 15-20 year old applications face multi-year migration programmes, and the interim state -- partial zero trust with legacy exceptions -- creates architectural complexity and potential bypass paths that are difficult to secure.
• Zero trust for OT/ICS environments presents fundamental compatibility challenges. Industrial control systems often use protocols (Modbus, DNP3, OPC Classic) that do not support authentication or encryption, run on embedded systems that cannot execute modern identity verification, and have real-time latency requirements that continuous authentication may violate. Purpose-built approaches that apply zero trust principles at the zone boundary level while accepting traditional trust models within OT zones are emerging, but no consensus architecture exists for ZT-OT integration.
• Continuous authentication UX friction remains the most common user complaint in zero trust deployments. Step-up authentication prompts triggered by risk signals -- new device, unusual location, sensitive resource access -- interrupt workflow and generate help desk tickets. Organisations report that aggressive trust scoring leads to user workarounds (disabling VPN, using unmanaged devices) that undermine the security model. Adaptive authentication that balances security signals against user productivity without creating fatigue is an active area of platform development with no proven optimal approach.
• Policy engine interoperability across multi-vendor zero trust deployments is a significant gap. Most enterprises use identity providers, network segmentation, endpoint management, and cloud access security from different vendors, each with proprietary policy languages and enforcement mechanisms. The lack of a universal policy interchange format means that organisations cannot define a single zero trust policy and have it enforced consistently across their entire estate. Standards efforts including NIST's work on policy description languages are underway but years from broad adoption.