Zero-Trust Architecture Is Already Founded on Trust Research

The name zero-trust architecture bothered me long before I had the language to say why. I was sitting in a security architecture discussion where someone described it as the model where you finally eliminate trust from the system, and something did not sit right. ZTA does not eliminate trust. It shifts trust from the person to the verification machinery. Every access request gets authenticated, every session gets authorized, every data path gets encrypted, and none of that works unless the organization trusts the identity provider, the policy engine, and the device posture system to do their jobs correctly. The name says zero trust. The architecture assumes nothing about the user and everything about the infrastructure that evaluates the user. That is not zero trust. That is institution-based trust made operational, and the gap between the name and the mechanism is costing us both confused implementations and a missed opportunity to connect practice to theory.

McKnight et al. (2002) distinguished four types of trust that operate at different levels and have different antecedents. Disposition to trust is a personality-level willingness to depend on others across situations. Institution-based trust is the belief that structural guarantees and protective mechanisms create safety. Trusting beliefs are perceptions of a specific party's competence, benevolence, and integrity. Trusting intentions are the willingness to depend on that party in a specific situation. ZTA replaces trusting beliefs about individual users with institution-based trust in the structural verification system. The question is no longer whether Alice is trustworthy. The question is whether the identity provider, the device posture check, and the continuous monitoring engine collectively produce an access decision the organization can rely on. The trust target shifts from the end entity to the structural mechanism. McKnight et al. described this exact mechanism in 2002. The cybersecurity industry popularized the same architecture without citing a single trust researcher.

The three operational pillars of ZTA confirm the mapping. Verify identity on every request. That is a continuous trustworthiness assessment. You are not assuming Alice is trustworthy because she logged in this morning. You are reassessing her identity, device state, and behavioral context before every access. Enforce least privilege. That is a limit on the damage of overtrust. If you granted Alice access she should not have, least privilege contains the blast radius. Monitor continuously. That is detecting trust drift. The entity that was trustworthy at nine in the morning may not be trustworthy at two in the afternoon. Its device may have been compromised. Its behavior pattern may have shifted. Lee and See (2004) would recognize this as pure trust calibration in action. An appropriate trust level is not a static setting. It adjusts to changing evidence. Overtrust at nine leads to the same misuse as overtrust in any automation context. Undertrust at two leads to the same disuse. The verification machinery exists to keep trust calibrated to current evidence. That is the Lee and See framework running at the infrastructure level.

But here is where ZTA runs into a problem that trust theory predicted well before the architecture was named. Mayer et al. (1995) defined trust as the willingness to be vulnerable to another party based on the expectation that the party will perform a particular action important to the trustor, irrespective of the trustor's ability to monitor or control that party. Vulnerability acceptance is not a side effect of trust. It is the core of the definition. Trust requires the trustor to accept risk. ZTA was designed by people who wanted to eliminate the need for vulnerability acceptance. Verify everything, trust nothing, never be vulnerable. The architecture fights against the very condition that Mayer et al. said makes trust what it is. But vulnerability is not optional in any system that people actually use. Someone has to decide which policies to write. Someone has to configure the identity provider. Someone has to respond when the monitor flags an anomaly. The organization is vulnerable to those administrators and the systems they operate. ZTA reduces the scope of vulnerability but cannot eliminate it. Organizations that treat ZTA as a vulnerability-elimination strategy discover that vulnerability shifts upward. The risk that used to sit with end users now sits with the people who control the identity infrastructure and the policy engine. The trust was not removed. It was centralized. I think this is the real reason ZTA implementations fail more often than the marketing suggests. They design for zero vulnerability, which is impossible, and then discover they have created a new concentration of power and risk that no one anticipated.

This creates what I think of as the ZTA paradox. The architecture exists precisely because trust cannot be assumed. You build continuous verification machinery because a past session does not guarantee current trustworthiness. But the more rigorously you implement ZTA, the more calibrated your trust becomes. And the more calibrated your trust becomes, the less you need the architecture for the specific entities that have consistently passed verification. You know that Alice's device is clean, her behavior is normal, and her access requests are appropriate. You could skip the reauthentication step for her without material risk. But you cannot know that without having done the verification in the first place. The architecture creates the calibration signal that eventually makes parts of itself redundant for specific entities, but never for the system as a whole. The calibration process produces the evidence that would justify skipping the calibration process, and you cannot get the evidence without running the process. That is not a bug. It is the definition of calibrated trust as a dynamic practice rather than a static state.

The cybersecurity marketing slogan is never trust, always verify. The trust literature would phrase it differently. Verify to trust. The first framing treats trust as a liability that must be surgically removed from the system. The second treats verification as the evidence base that earns calibrated reliance. These two framings produce different systems. An organization that builds ZTA around never trust designs rigid controls that challenge every session equally and frustrate users, which invites shadow workarounds and policy exceptions that reintroduce the vulnerability the architecture was supposed to eliminate. An organization that builds ZTA around verify to trust designs adaptive controls that adjust privilege levels based on real-time evidence. Lee and See would recognize the first as an undertrust trap and the second as a calibration strategy. The difference is not technical. It is a difference in what the architects believe trust is and whether they think it can be calibrated or only cut out.

I think ZTA is the most practically important application of trust theory that information systems researchers do not cite nearly enough. Security architects make trust calibration decisions every day. They decide how much identity proofing is enough, how frequently to reauthenticate, what device posture is acceptable, and what behavior patterns should trigger a block. These are not technical decisions. They are decisions about the cost of overtrust versus the cost of undertrust. They are decisions about whether institution-based trust in the identity provider is sufficient or whether the system needs trusting beliefs about specific users. They are decisions about whether trust and distrust are the same construct or separate ones, which Dimoka (2010) showed can matter at the neural level. Every policy rule encodes an implicit theory about trust, written by someone who has likely never read Mayer, McKnight, or Lee and See. I wrote earlier about why distinguishing trust from trustworthiness, reliance, and delegation is not just academic pedantry, and the same argument applies at the infrastructure level. The security architect who writes a continuous authentication policy without understanding calibrated trust is still making a calibration decision. She just does not have the vocabulary to recognize it as one. The IS field has been studying this problem for three decades. The practitioners who need it most are making these decisions in every policy engine, and they do not know the literature exists. That gap should not survive another year.