# Zero Trust Architecture
Zero trust is a security model built on one principle: no user, device, application, or network flow is trusted by default, regardless of location. Every access request is verified before it is granted. Every session is continuously validated. Every resource is protected as if the network perimeter does not exist.
The term was coined by John Kindervag at Forrester Research in 2010, but the concept draws on earlier work in network micro-segmentation, least-privilege access, and the Jericho Forum's de-perimeterization principles from the early 2000s. The U.S. federal government formalized its adoption through Executive Order 14028 (May 2021) and the Office of Management and Budget's Zero Trust Strategy (M-22-09, January 2022), which mandates federal agencies implement zero trust architecture by the end of fiscal year 2024.
Zero trust is not a product. It is not a single technology. It is an architectural approach that changes where and how trust decisions are made. In a traditional perimeter-based model, anything inside the network is implicitly trusted. In a zero trust model, nothing is implicitly trusted. Trust is earned through verification, scoped to the minimum required, and continuously reevaluated.
Zero trust architecture operates on five interconnected principles:
Verify explicitly. Every access request is authenticated and authorized based on all available data points: user identity, device health, location, resource sensitivity, time of day, behavioral patterns. A valid username and password are not sufficient. The entire context of the request determines whether access is granted.
Use least-privilege access. Users and systems receive only the access they need for the specific task they are performing, for the duration they need it. No standing privileges. No permanent admin access. Just-in-time (JIT) access provisioning grants elevated privileges when needed and revokes them when the task is complete.
Assume breach. Design every system as if an attacker is already inside the network. Segment resources so that compromising one system does not grant access to others. Encrypt data in transit even on internal networks. Monitor all traffic, internal and external, for anomalous behavior. If you assume the perimeter has already failed, you build defenses that work without it.
Micro-segment everything. Replace the single network perimeter with granular trust boundaries around each resource, application, and data set. A user authenticated to the email system does not automatically have access to the financial system. Each resource has its own access policy enforced at the point of access.
Continuously validate. Authentication is not a one-time event at the start of a session. Trust is continuously evaluated throughout the session. If a device's security posture changes (antivirus disabled, patch level drops, location changes to an anomalous geography), the session can be downgraded, restricted, or terminated in real time.
NIST Special Publication 800-207 defines the reference architecture for zero trust with three core logical components:
Policy Engine (PE). The decision-maker. The PE evaluates access requests against defined policies, considering identity, device posture, resource sensitivity, threat intelligence, and behavioral context. It renders an allow or deny decision for every request.
Policy Administrator (PA). The enforcer. The PA executes the PE's decisions by signaling the Policy Enforcement Point to establish or terminate access. The PA manages the session lifecycle: create, maintain, monitor, and destroy.
Policy Enforcement Point (PEP). The gate. The PEP sits between the subject (user or system requesting access) and the resource. It enables, monitors, and terminates connections based on PE decisions. Every access path passes through a PEP. There is no way to reach a resource without passing through enforcement.
Zero trust implementation typically follows one of three patterns:
Identity-centric. The identity provider is the primary trust anchor. All access decisions route through the identity provider, which evaluates user identity, device compliance, and contextual risk before granting access. This pattern is common in cloud-native environments where Azure Entra ID, Okta, or Google Workspace serve as the identity plane. Conditional access policies implement the zero trust logic.
Network-centric. Micro-segmentation of the network creates granular trust zones. Software-defined networking (SDN) and micro-segmentation platforms (Illumio, Guardicore/Akamai, VMware NSX) enforce access policies at the network layer. East-west traffic (lateral movement) is controlled as tightly as north-south traffic (perimeter traffic). This pattern is common in environments with significant on-premises infrastructure.
Resource-centric. Each application and data store maintains its own trust boundaries. Application-layer firewalls, API gateways, and database activity monitoring enforce granular access controls at the resource level. This pattern works well for modern application architectures where services communicate through APIs rather than network protocols. Service mesh technologies like Istio implement resource-centric zero trust for containerized applications.
Zero trust is not a binary state. Organizations progress through maturity stages:
Traditional (perimeter-based). Trust is location-based. Inside the network is trusted. Outside is untrusted. VPN extends the trust boundary to remote users. Once inside, lateral movement is largely unrestricted.
Initial zero trust. MFA is deployed for remote access. Some conditional access policies exist. Network segmentation is coarse-grained (VLANs, not micro-segmentation). Identity and network security operate independently.
Advanced zero trust. MFA is universal (including internal access). Conditional access evaluates device compliance, location, and behavioral risk. Micro-segmentation restricts lateral movement. Identity and network security share context. Just-in-time privileged access replaces standing admin accounts.
Optimal zero trust. All access is continuously verified. All traffic is encrypted and inspected. All resources are micro-segmented. Threat intelligence feeds real-time risk into access decisions. Behavioral analytics detect anomalous access patterns. Access is adaptive: trust levels adjust dynamically based on real-time risk assessment.
Real-world zero trust deployment faces predictable obstacles:
Legacy system integration. Mainframes, industrial control systems, and older business applications were not designed for continuous authentication. They assume persistent network connections and rarely support modern authentication protocols. Organizations either accept security gaps around legacy systems or invest in proxy solutions that retrofit zero trust controls.
User experience degradation. Continuous verification can create friction. Users accustomed to single sign-on find themselves repeatedly prompted for additional authentication factors. The key is contextual enforcement: high-risk activities (accessing financial data from an unmanaged device) require additional verification, while low-risk routine access (checking email from a managed corporate device) remains frictionless.
Performance impact. Every access request travels through the Policy Engine. Every network flow passes through a Policy Enforcement Point. Latency increases. Throughput may decrease. High-performance applications (video editing, CAD, real-time trading) may be incompatible with certain zero trust implementations.
Complexity management. Zero trust shifts security complexity from the perimeter to every access point. Policy engines must evaluate thousands of rules across multiple contexts. Policy conflicts create security gaps. Policy changes propagate across distributed enforcement points. Organizations need robust policy management tools and processes to avoid creating new vulnerabilities while solving old ones.
The traditional network perimeter assumed a clear boundary between inside and outside. Cloud computing, remote work, SaaS applications, mobile devices, and API integrations have erased that boundary. A typical enterprise environment in 2024 has data in multiple cloud providers, users accessing resources from personal devices on home networks, SaaS applications processing sensitive data outside the corporate network, and API integrations connecting dozens of third-party services.
In this environment, "inside the network" is a meaningless concept. Zero trust replaces the nonexistent perimeter with a model that works regardless of where the user, device, or data resides.
Most successful attacks do not breach the perimeter and immediately reach their objective. They breach the perimeter (often through phishing or credential theft), then move laterally through the internal network until they reach the target data or system. The 2020 SolarWinds compromise demonstrated this at scale: the initial access was through a supply chain compromise, but the damage was done through lateral movement across trust boundaries that did not exist because everything inside the network was implicitly trusted.
Zero trust architecture disrupts lateral movement by eliminating implicit trust. Every internal access request is verified. Every system is segmented. Compromising one system does not grant access to adjacent systems. The attacker must authenticate and authorize at every step, which creates detection opportunities and increases the cost and complexity of the attack.
Zero trust directly addresses regulatory requirements across multiple frameworks. NIST Cybersecurity Framework 2.0 maps zero trust principles to Protect (PR) functions for identity management and access control. The Department of Defense's Cybersecurity Maturity Model Certification (CMMC 2.0) requires zero trust capabilities for Level 3 certification. PCI DSS 4.0 strengthens network segmentation requirements that zero trust fulfills through micro-segmentation.
For federal contractors, zero trust is increasingly mandatory. The DOD's zero trust strategy requires CMMC-assessed organizations to implement specific zero trust capabilities. Executive Order 14028 creates compliance requirements that flow down through federal supply chains.
The IBM Cost of a Data Breach Report 2023 shows that organizations with mature zero trust implementations experienced $1.76 million lower breach costs than those without zero trust deployed. The reduction comes from three factors: faster incident detection (zero trust monitoring identifies anomalous access patterns), limited blast radius (micro-segmentation contains the impact), and reduced dwell time (continuous validation cuts the time between initial access and detection).
Zero trust architecture sits primarily in the IAT (Identity Access and Trust) domain of the Planetary Defense Model. IAT is the civilization layer: it governs who operates within the environment, what they can access, and how trust is established and verified. CDA's methodology for IAT is Zero Possession Architecture (ZPA): "Trust nothing. Possess nothing. Verify everything."
ZPA extends zero trust in one critical dimension: possession. Standard zero trust focuses on verifying every access request. ZPA adds the principle that the security system itself should not possess the data it protects. CDA operates under ZPA for client engagements: we protect your data without possessing it. Your encryption keys stay yours. Your data stays in your environment. We provide the operational capability without creating a new trust dependency.
This distinction matters because many "zero trust" implementations create new trust concentrations. An identity provider that mediates all access becomes a single point of trust (and therefore a single point of compromise). A SIEM that collects all security telemetry possesses a complete map of the organization's activities. A cloud security broker that inspects all traffic possesses the content of that traffic. Each of these is a trust dependency that zero trust was supposed to eliminate.
ZPA addresses this by designing systems where the security infrastructure verifies without possessing. The principle applies to CDA's own operations and to the architectures CDA designs for clients.
CDA approaches zero trust differently from conventional vendors and consultancies in one specific way: we treat it as an operational capability, not a product deployment. A vendor sells you an identity provider and calls it "zero trust." A consultancy gives you a maturity assessment and a roadmap. CDA executes the missions that implement the architecture: designing the policy engine, deploying conditional access, hardening segmentation, testing with credential compromise drills, and operating the system in steady state through C-COMMAND.