Trust Is Reduced, Not Removed

No system eliminates trust. The best systems make the remaining trust assumptions explicit, narrow, and independently checkable. The worst systems hide them behind confident language.

The distinction

Eliminating trust would mean a system where no party needs to believe anything about any other party. That does not exist in practice. Even cryptographic verification requires trusting the key distribution mechanism, the timestamp authority, or the hardware that generated the signature.

Reducing trust means shrinking the set of things you have to take on faith, and making the remaining assumptions visible so they can be evaluated, challenged, or mitigated.

Why this matters

"Zero trust" is a useful network architecture principle. It is a terrible description of what actually happens in a real system. Every deployed system has trust assumptions. The question is whether those assumptions are:

• Explicit — stated clearly in documentation, threat models, or architecture diagrams
• Narrow — scoped to specific components rather than spread across the system
• Checkable — verifiable by someone outside the system, or at least auditable

When a system claims to "eliminate trust," the first response should be: trust in what, exactly?

The marketing term "zero trust" illustrates this exactly. A zero trust network architecture does not eliminate trust — it moves trust from the network perimeter to identity verification, device posture, and per-request policy evaluation. The trust surface is smaller and better defined, but it still exists. The identity provider must be trusted. The policy engine must be trusted. The device attestation mechanism must be trusted. Calling this "zero trust" obscures the real question: what trust remains, and is it visible?

Three categories of remaining trust

1. Key material trust

If a receipt is signed, someone has to trust that the signing key belongs to the claimed issuer. Key distribution is a trust assumption. Certificate chains reduce it. Hardware security modules narrow it further. But it is never fully eliminated — at some point, a root of trust must be accepted.

2. Timestamp trust

If a record is timestamped, someone has to trust that the timestamp authority reported the correct time. RFC 3161 timestamps reduce this to trusting a specific, auditable third party. But the trust remains: the timestamp authority could lie, collude, or be compromised.

3. Environmental trust

If a system claims that execution stayed in scope, someone has to trust that the runtime enforced the scope constraint correctly. The receipt can prove what the governance layer approved, but proving what the execution environment actually did requires evidence from the execution layer itself.

The test

When evaluating any system's trust claims:

1. List every entity the system expects you to trust.
2. For each one, ask: can I verify this independently, or do I have to take their word for it?
3. For each trust assumption you cannot verify, ask: how narrow is this assumption, and what happens if it is wrong?

A good system will have a short list, with clear answers. A bad system will have a long list hidden behind a reassuring summary.

The principle

Trust is not a binary. It is a surface. Good systems reduce that surface and make the remaining edges visible. The goal is not to trust nothing — it is to know exactly what you are trusting and why.

See also: How to Review a System for Trust Boundaries — a structured checklist for mapping and evaluating the remaining trust surface.