# What Is Zero Trust Security
Zero Trust Security is an architecture and operational philosophy built on a single governing principle: no user, device, or network connection should be trusted by default, regardless of where it originates. The model exists because traditional network security assumed that everything inside a corporate perimeter was safe, and everything outside was hostile. That assumption collapsed as organizations moved workloads to the cloud, extended access to remote workers, and connected third-party vendors to internal systems. Zero Trust replaces perimeter-based trust with continuous verification, enforcing strict access controls at every layer of the environment rather than relying on a network boundary that no longer meaningfully exists.
Zero Trust Security is a strategic security model, first formally described by Forrester Research analyst John Kindervag in 2010 and later codified by the National Institute of Standards and Technology in NIST Special Publication 800-207. The model defines a set of principles requiring that all access requests, whether originating from inside or outside a network perimeter, be authenticated, authorized, and continuously validated before access is granted to any resource.
The core tenets are: verify explicitly (always authenticate and authorize based on all available data points), apply least-privilege access (limit user access rights to only what is required for a specific task), and assume breach (operate as if a threat actor is already present inside the environment and design controls accordingly).
Zero Trust is not a single product, tool, or technology. It is a framework that shapes architecture decisions across identity, endpoints, networks, applications, and data. It is not synonymous with multi-factor authentication, although MFA is one component of a Zero Trust implementation. It is not the same as micro-segmentation, though micro-segmentation is a supporting tactic. It is not a firewall upgrade.
Variants include Zero Trust Network Access (ZTNA), which applies the principles specifically to remote access scenarios and replaces traditional VPN architectures. Identity-centric Zero Trust places the identity provider at the center of all access decisions. Data-centric Zero Trust focuses verification controls around the data itself rather than the network path. In practice, mature implementations combine elements of all three approaches.
The mechanics of Zero Trust operate through a policy enforcement architecture that intercepts every access request and subjects it to a verification process before granting or denying access to a protected resource.
The Policy Engine and Policy Enforcement Point
NIST SP 800-207 defines two core logical components: the Policy Decision Point (PDP) and the Policy Enforcement Point (PEP). The PDP evaluates access requests against defined policy rules and signals a trust decision. The PEP sits between the user or device and the resource, and it acts on that decision by allowing or blocking the connection. In modern implementations, the PDP includes a Policy Engine that processes signals and a Policy Administrator that communicates decisions to the enforcement layer.
Signal Collection and Contextual Evaluation
Before granting access, the system collects signals from multiple sources. These signals typically include: identity verification (is this user who they claim to be, verified through credentials and MFA); device health (is the device managed, patched, and compliant with organizational policy); location and network context (is this request coming from an expected geography or an anomalous IP range); behavioral baselines (does this access pattern match what this user normally does); and data sensitivity (what classification level is the resource being requested).
All of these signals feed into the policy engine simultaneously. The engine applies rules and, in more advanced deployments, risk scoring algorithms to produce a trust score for that specific request in that specific context.
Least-Privilege Access Enforcement
Once a trust decision is made, access is granted only to the specific resource requested, only for the session duration required, and only with the permissions that role requires. A user authenticated to access a financial reporting application does not automatically gain access to the human resources database, even if both systems sit on the same internal network segment. Session tokens expire. Re-authentication triggers on behavioral anomalies. Access is not assumed to persist because it was granted once.
Micro-Segmentation in Practice
Network micro-segmentation is a supporting control that divides the network into small, isolated zones. Even if a threat actor compromises one segment, lateral movement to another segment requires passing through another enforcement point where the same verification process applies. This is how Zero Trust contains breaches rather than simply trying to prevent them at the perimeter.
A Concrete Scenario: Remote Contractor Access
Consider a mid-sized manufacturing company that contracts with a software vendor for ongoing ERP support. Under a traditional perimeter model, the vendor receives VPN credentials and, once connected, has broad access to internal systems because they are "inside the network."
Under a Zero Trust implementation, the contractor authenticates through an identity provider using MFA. The policy engine checks that the contractor's device meets compliance requirements (managed endpoint, current patch level, endpoint detection software running). The engine checks that the access request matches the contractor's defined scope of work, specifically the ERP system, during approved working hours, from an expected geographic region. The PEP grants a session-specific connection only to the ERP application. No other systems are reachable. The session is logged continuously, and the policy engine monitors for behavioral deviations. If the contractor attempts to query a database outside their defined scope, the session is flagged and potentially terminated automatically.
Implementation Considerations
Zero Trust implementations require a mature identity foundation. If identity data is inconsistent or incomplete, the policy engine cannot make reliable decisions. Organizations typically sequence implementation by starting with identity consolidation, then moving to device management and endpoint visibility, then applying network segmentation, and finally extending controls to data classification and application-level enforcement. Full Zero Trust maturity is a multi-year program, not a single deployment event.
The business and security impact of Zero Trust is measurable and documented. The 2023 IBM Cost of a Data Breach Report found that organizations with mature Zero Trust deployments saved an average of $1.76 million per breach compared to organizations without Zero Trust controls. That gap reflects the difference between a contained incident and one that propagates across an environment before detection.
Without Zero Trust architecture, the most common failure mode is lateral movement following initial compromise. An attacker who obtains one set of credentials inside a flat network can move from system to system with minimal friction. The 2020 SolarWinds supply chain attack demonstrated this precisely: threat actors entered target environments through a trusted software update mechanism and then moved laterally for months through environments that lacked internal verification controls. The affected organizations had perimeter defenses; what they lacked was the assumption-of-breach posture and internal enforcement that Zero Trust requires.
Compliance frameworks increasingly mandate Zero Trust principles. The U.S. Federal Zero Trust Strategy, published by the Office of Management and Budget in January 2022, required all federal agencies to meet specific Zero Trust architecture goals by fiscal year 2024. The Payment Card Industry Data Security Standard version 4.0 incorporates Zero Trust-aligned requirements for access control and network segmentation. Organizations operating in regulated industries cannot treat Zero Trust as optional.
A common misconception is that Zero Trust is primarily a remote-work solution. It is not. The principles apply equally to on-premises users, cloud workloads, internal service-to-service communication, and operational technology environments. Another misconception is that Zero Trust eliminates the need for other security controls. It does not. Zero Trust is one layer of a defense-in-depth strategy; it must be paired with vulnerability management, threat detection, incident response, and data protection programs.
For practitioners, the operational consequence of the misconception that Zero Trust is a product purchase is significant: organizations that buy a ZTNA solution and declare Zero Trust "done" often have significant gaps in identity governance, device management, and monitoring that undermine the entire model.
CDA approaches Zero Trust through the Planetary Defense Model (PDM), specifically within the Identity and Access Technology (IAT) domain. The PDM recognizes that most breaches are not failures of perimeter technology; they are failures of trust management. The methodology governing this approach is the Zero Possession Architecture (ZPA), which operates on three interdependent directives: trust nothing, possess nothing, verify everything.
Zero Possession Architecture takes Zero Trust principles further than standard implementations by treating possession of credentials, data, and persistent access as an attack surface in itself. Where conventional Zero Trust focuses on verifying access requests, ZPA asks a prior question: should any persistent access exist at all? In the ZPA model, standing access is eliminated wherever operationally feasible. Privileged access is ephemeral, session-scoped, and generated on demand through a just-in-time provisioning workflow. Credentials are never stored in a form that persists beyond their required use window.
In practice, CDA implements this within the IAT domain through several specific mechanisms. Identity verification is continuous rather than point-in-time: the policy engine reassesses trust at defined intervals during an active session, not only at login. Device posture is verified at each enforcement point, not assumed from an initial compliance check. Data classification is applied at the source, ensuring that the sensitivity of a resource informs the trust threshold required to access it, with higher-sensitivity data requiring stronger signal combinations and shorter session windows.
CDA also applies ZPA to service accounts and machine identities, an area where many Zero Trust implementations have gaps. Service-to-service communication in CDA-aligned environments uses short-lived certificates and mutual TLS authentication. No service account holds persistent credentials that an attacker could extract and reuse.
The operational difference between CDA's ZPA approach and a standard Zero Trust deployment is the explicit design goal of reducing the value of any single compromised credential to near zero. A stolen credential that cannot authenticate without a compliant device, cannot persist beyond a session, and cannot reach resources outside a defined scope provides an attacker almost no advantage.