The zero-trust paradox: Why systems built to eliminate trust may be destroying it

There is a phrase I have used in dozens of security briefings over the past decade, delivered to boards, to engineering teams, to skeptical CFOs trying to understand why we needed to rebuild our entire network architecture: “Never trust, always verify.” It is clean, logical and sounds like exactly the kind of discipline that organizations need. I believed it then. I am less certain now.

Zero trust, as a security model, emerged from a reasonable observation: The old perimeter-based model was broken. If you authenticated to the network once, you were trusted everywhere inside it. That was a catastrophic assumption in a world of lateral movement, insider threats and cloud-distributed infrastructure. The NIST Zero Trust Architecture formalized what Google’s BeyondCorp had pioneered: Continuous verification, least-privilege access, micro-segmentation and the assumption that no actor, internal or external, should be implicitly trusted. In pure security terms, this was progress.

But I have started to wonder whether we have built something that works exactly as designed, and whether that is a problem.

When verification became the architecture of everything

A few years ago, I was working with a mid-size financial services firm on a zero-trust implementation. The project was technically successful. We reduced the attack surface, eliminated implicit trust zones and instrumented every lateral connection. When we were done, the CISO was satisfied. The security metrics improved.

But something unexpected happened in the weeks that followed. Employees started complaining, not about the friction of re-authentication, which we had mostly minimized, but about something harder to articulate. One senior analyst told me it felt like the company no longer trusted her. She understood, intellectually, that the system treated everyone the same. But the experience of being continuously verified, of having every access event logged and reviewed, felt less like a security posture and more like surveillance. She was not wrong, technically. That is precisely what it was.

I dismissed this at the time as a change management problem. Now I think it was a signal I underweighted.

Zero trust is spreading beyond the infrastructure layer. The logic of continuous verification (assume nothing, authenticate everything, revoke access dynamically) is showing up in HR platforms that monitor keystrokes, in workplace tools that score “productivity” and in customer-facing AI systems that make real-time decisions about who gets a loan, a job interview or an insurance quote. We built a security framework and we are now, almost without noticing, applying its epistemology to people.

The problem is not that any of these individual systems are necessarily wrong. The problem is that verification and trust are not the same thing. You can verify everything about a person (their credentials, their behavior, their history) and still be in a relationship defined by suspicion rather than trust. Verification answers a technical question. Trust is a social and moral commitment.

The trust deficit no one designed for

In 2024, the Edelman Trust Barometer found that trust in institutions continues to erode globally, with fewer than half of respondents trusting government, media or business to do the right thing. This is the ambient condition in which we are deploying zero trust architectures, and I think we are making it worse, not because the technology is malicious, but because we are importing its logic into human relationships without examining what that costs.

Consider what happens when an AI system mediates access or makes consequential decisions. The model may be technically robust, carefully trained and well-intentioned. But from the perspective of the person on the receiving end, it is opaque, unchallengeable and unaccountable. They do not know why they were denied. They cannot appeal to a human. The system has verified them and still found them wanting, through a process they cannot see or contest.

This is a trust problem that cryptographic assurance cannot solve. You cannot encrypt your way to legitimacy. You cannot audit your way to human dignity. And as we layer more AI-mediated decision-making onto zero trust infrastructure, we are creating systems that are technically secure but experientially corrosive.

I have watched this play out in enterprise settings. Teams that operate under heavy monitoring (even when that monitoring is disclosed, justified and proportionate) develop a different relationship to their work. They become more risk-averse, less willing to experiment and more likely to interpret ambiguous situations conservatively. The psychological research on surveillance and behavior is not ambiguous: Being watched changes how people act, and not always in the direction that organizations want.

There is also an equity dimension that deserves more attention than it receives in most zero trust conversations. Continuous verification systems are not neutral. They encode assumptions about what normal behavior looks like, what legitimate access patterns are and which anomalies warrant scrutiny. Those assumptions are built from historical data, and historical data reflects historical biases. A system that flags unusual behavior will, in practice, flag people whose behavior differs from whatever pattern was used to define “usual.” That is not a zero-trust problem specifically; it is a machine learning problem, but it is one that zero trust deployments inherit and amplify.

Rebuilding worthy systems in a zero-trust world

I am not arguing that we abandon zero trust. The security case for it is sound, and the alternative (implicit trust based on network position) is genuinely dangerous. What I am arguing is that we need a more honest account of what zero trust does and does not accomplish, and a more deliberate effort to design systems that remain worthy of human trust even as they eliminate technical trust assumptions.

That means separating the security posture from the surveillance posture. Continuous verification of access events is a security necessity. Continuous monitoring of employee behavior is a management choice, and one with real costs to morale, autonomy and culture. Organizations should make that choice deliberately; not let it emerge as a byproduct of infrastructure decisions.

It means building explainability into AI-mediated decisions, not as a regulatory checkbox but as a genuine design commitment. If a system makes a consequential decision about a person (access denied, application rejected, claim flagged), that person should have a human-comprehensible account of why and a meaningful path to challenge it. This is not technically easy, but it is ethically necessary.

It means bringing the trust conversation into the boardroom, not just the SOC. Security leaders are usually invited into business discussions when something goes wrong. I would argue we should be present for the upstream decision about whether to deploy a given verification or monitoring system at all, and what the tradeoffs are between security benefit and trust cost. That conversation rarely happens in my experience, and its absence is how we end up with systems that are secure by design and corrosive by consequence.

And finally, it means accepting that some of what we have called a trust problem is actually an accountability problem. People do not withhold trust from systems because they misunderstand them. They withhold it because the systems are not accountable to them. Zero trust, as an architecture, is accountable to the organization that deploys it. It is rarely accountable to the people it governs. Closing that gap (through transparency, contestability and genuine recourse) is not a security problem. It is a political and organizational one.

The phrase “never trust, always verify” was always a metaphor. Networks do not trust. People do. What we are building now are systems that govern people using a logic borrowed from packet inspection, and we are surprised when it does not produce the outcomes that trust actually requires: Cooperation, risk-taking, commitment and the willingness to be vulnerable in ways that no authentication protocol can mandate.

The question I keep returning to, in conversations with peers across the industry, is this: When every interaction is mediated by verification, and every anomaly is flagged and reviewed, and every decision is delegated to a model: What exactly are we securing, and for whom? Security without legitimacy is control. And control, no matter how well- engineered, is not the same thing as trust.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?