Executive Summary
Zero Trust Architecture has become the dominant security framework of the 2020s, mandated for federal agencies by executive order and adopted by enterprise security programs worldwide. Its core principle, never trust, always verify, represents a genuine and necessary evolution from perimeter-based security.
But verification, as currently implemented, is a point-in-time binary operation. A request is evaluated against a policy. Access is granted or denied. The decision is correct based on the information available at the moment it is made. It is blind to the causal history that produced that moment, and adversaries have learned to exploit exactly this blindness.
Zero Trust without causal context is theater. Rigorous, well-intentioned theater, but theater nonetheless. This paper examines the gap, how it gets exploited, and what genuine Zero Trust enforcement actually requires.
The Verification Model and Its Limits
NIST SP 800-207 describes a model in which every access request is evaluated against a dynamic policy engine that considers device health, identity context, network location, and behavioral signals before granting access. The policy engine is supposed to be continuous rather than a one-time login check.
In practice, most ZT implementations achieve point-in-time verification at the authentication boundary and limited, rule-based behavioral monitoring thereafter. The reasons are architectural. Truly continuous policy evaluation requires a continuously updated model of each identity's causal trajectory, not just whether a user's MFA token is valid, but what that identity has done in the past 72 hours, what caused each of those actions, and whether the current request is consistent with the causal pattern of their legitimate activity.
Building that model requires causality. Current ZT tooling does not provide it.
How Attackers Exploit the Gap
The canonical Zero Trust bypass used by sophisticated threat actors in 2024 and 2025 follows a consistent template.
The attacker gains initial access through phishing, a supply chain compromise, or a VPN vulnerability, then harvests credentials using techniques that blend with legitimate activity: LSASS memory reads during scheduled maintenance windows, AS-REP roasting against service accounts, OAuth token theft via consent phishing. The ZT policy engine sees valid credentials and grants access.
Using those credentials, the attacker accesses systems they are legitimately authorized to access. They move slowly, during business hours, from expected source IPs where possible. Each individual request passes ZT policy evaluation. CrowdStrike's 2024 threat intelligence puts the median duration of this phase at 16 days.
Having established what looks like a legitimate access pattern over two-plus weeks, the attacker reaches the actual target. From the policy engine's perspective, this request looks almost identical to the preceding two weeks of legitimate-appearing requests. Policy evaluation passes. Breach occurs.
The fundamental failure: the ZT policy engine evaluated each request in isolation. It had no model of the causal chain connecting the credential harvest to the dwell period to the final access event. Each transaction was legitimate on its own terms. The chain was not.
Trust Is Not Binary
The conceptual error in current Zero Trust implementations is treating trust as binary: trusted or not trusted, allow or deny. Real trust has history. It has momentum. It has a trajectory that can be read.
An identity that logs in from Austin at 8:47 AM on a Tuesday, accesses three internal applications, joins two calls, and sends twelve emails is exhibiting trust-consistent behavior. That same identity logging in from the same location at 8:47 AM, but whose device experienced a credential dump event at 8:31 AM that the policy engine has no awareness of, is exhibiting something else entirely. The trust signal has changed. The trajectory has broken. The policy engine, evaluating the request in isolation, cannot see it.
This is the concept behind Trust Drift: rather than asking whether an identity has valid credentials right now, the question becomes whether the identity's current behavior is consistent with the causal trajectory of its established baseline.
Trust scores in a causal intelligence model are computed continuously from the identity's event history, weighted by the causal significance of each event. A credential dump event on the device does not immediately revoke access. It depresses the trust score, flags the trajectory, and escalates the sensitivity of subsequent verification decisions. A legitimate user whose device experiences anomalous process execution followed by a network connection to an unusual endpoint will see their trust score shift before they access anything sensitive. An attacker using their compromised credentials will find the ZT enforcement point evaluating not just the credential, but the full causal context of recent activity on that identity.
The Okta Breach Case Study
The 2023 Okta support system breach illustrates this precisely. An attacker gained access to Okta's customer support case management system via a compromised service account. The credential was valid. The access was to a system the service account was legitimately authorized to use. Standard ZT policy evaluation granted access.
A causal intelligence layer would have surfaced three things: the service account had not accessed the support case management system in 14 days prior to the breach; the access came from a device that had performed an unusual series of file operations in the 40 minutes preceding authentication; and those file operations were consistent with credential extraction tooling.
None of these observations would necessarily trigger a ZT deny decision on their own. Together, as a causal chain, they constitute strong evidence that the trust trajectory of this identity had been disrupted. The appropriate response was step-up verification, session monitoring, and anomaly flagging, not silent access grant. Okta's internal detection lag was weeks. A causal trust model, continuously updating the trajectory of each service account, would have flagged the anomaly within hours of the initial compromise.
NIST SP 800-207 and the Causal Extension
NIST's ZTA specification identifies seven tenets. The most operationally challenging is that "the enterprise monitors and measures the integrity and security posture of all owned and associated assets." Measuring integrity requires a baseline. Detecting deviation requires comparison to that baseline over time. Attributing deviation to a cause requires causal analysis.
The specification also calls for "dynamic policy" based on collecting "as much information as possible about the current state of assets, network infrastructure, and communications." Current state, without causal history, is a snapshot. Causal history with continuous trajectory modeling is the dynamic policy the specification envisions. Most implementations are delivering the snapshot.
TRA-CE's Trust Drift module implements this directly: continuous trust trajectory computation per identity, Hawkes process modeling for predicting escalating risk patterns, and real-time integration with ZT enforcement points to provide causal context at the moment of access decision.
Practical Implementation
Integrating causal trust context with existing ZT architecture does not require replacing your identity provider, policy engine, or CASB. The causal intelligence layer sits between your event data and your policy evaluation, enriching each access decision with trajectory context.
The integration surface is an enrichment API. At the point of policy evaluation, the ZT engine queries the causal intelligence layer for the requesting identity's current trust score, trajectory delta over 1-hour, 6-hour, and 24-hour windows, and any active causal chain involvement. The policy engine uses these as additional policy variables.
Trust score above 0.85 with stable trajectory: standard verification. Between 0.60 and 0.85 with declining trajectory: step-up authentication. Below 0.60, or active causal chain involvement: session hold and analyst notification. No changes to the underlying ZT architecture. No new authentication protocols. The causal layer enriches the decision that was already being made.
Conclusion
Zero Trust Architecture addresses the right problem. Perimeter security is obsolete, and every access decision must be earned. But verification that is blind to causal history is not the "never trust" the framework promises. It is "trust the credential," which is precisely what adversaries have learned to exploit.
Genuine Zero Trust requires continuous trust trajectory modeling. Knowing not just who is asking, but what causal chain produced this request, and whether that chain is consistent with the legitimate baseline of this identity. The framework is right. The implementation needs to catch up.
TRA-CE.ai | Causal Security Intelligence | tra-ce.ai