What Zero Trust Does Not Fix

Limits · July 30, 2026 · 10 min read

The name is the worst thing about this subject. “Zero trust” describes a system in which trust has been removed, and no such system exists or could. Every architecture trusts something. What this one does is move trust off the network and onto a small number of components that are explicitly named, deliberately built and, in principle, defensible.

That is a genuine improvement, because implicit trust distributed across thousands of network paths cannot be reasoned about, whereas explicit trust in a handful of systems can. But it means the honest description of the model is relocation, and relocation obliges you to know the new address. This essay is about the addresses.

The issuer is now the estate

Every enforcement point in an identity-centric architecture accepts assertions from an authority. That is the design. It is also the single largest concentration of risk you have created, and it is not adequately described as “an important system”.

An attacker who obtains the ability to issue valid assertions does not have to attack anything else. Enforcement points will accept the resulting credentials because accepting correctly signed credentials from the trusted issuer is exactly what they are built to do. They cannot detect the difference; there is no difference to detect. Segmentation does not help, because the assertions name principals that are permitted to cross the segments. Posture does not help, if the assertion carries the claims the policy reads. The controls behave correctly and the outcome is total.

Nor does this require compromising a signing key, which is the version people plan for. Adding a federated identity provider to a tenant achieves the same thing without touching key material — an attacker-controlled authority becomes trusted by configuration change. So does modifying the directory that feeds claims, or the group memberships that policy reads, or the conditional access rules that decide when to challenge. Anything that can change what the issuer asserts is functionally equivalent to control of the issuer, and the administrative surface for that is much wider than the cryptographic one.

There is no architectural trick that removes this. What is available is containment: administering identity infrastructure from dedicated paths that do not share credentials with ordinary corporate systems, separating the authority to change federation and key material from the authority to administer users, logging issuance and configuration changes to a store the identity system cannot rewrite, and knowing in advance how you would invalidate everything currently outstanding. Every one of those is operational rather than architectural, which is why they are the ones most often missing.

A verified identity can be the wrong identity

Zero trust verifies that a request comes from the principal it claims. It has no opinion about whether that principal is currently under the control of the person it belongs to.

Session theft is the clean illustration. Modern authentication has become genuinely hard to defeat directly, so the attack moved past it: take the artefact issued after a successful authentication and use it. The credential is authentic, the authentication really happened, and every downstream check passes, because every downstream check is asking a question that has already been answered correctly. Binding tokens to the device or channel they were issued for raises the cost of this considerably and should be done wherever the platform supports it — but the general shape of the problem, that authority once issued can be taken, does not go away.

The same applies to a principal that has been socially engineered into approving something, or an insider acting within their entitlements. The model was built to answer “is this who it says it is”, and it answers it well. It was never able to answer “should this be happening”, and no amount of verification converts one question into the other.

Policy is where the trust really lives

The mechanism gets almost all of the attention. Tokens, mutual TLS, enforcement points, decision points — these are the parts with specifications and diagrams.

But a correctly functioning enforcement point applies whatever policy it is given, and the policy is a human artefact. It is written under time pressure, against an incomplete understanding of what applications need, by people who are penalised for outages and not for excess permissions. Then it is never substantially narrowed, because narrowing it risks breaking something and the benefit is invisible.

The predictable outcome is an estate with excellent mechanism and permissive rules. Every access decision is properly evaluated, cryptographically sound, fully logged — and returns “allow”, because the rule was written broadly. The machinery is working. It is working on a policy that grants more than anyone intends, and no property of the machinery detects that.

This is why entitlement review is not an adjacent compliance activity but part of the control itself, and why the ability to answer “what would this principal be able to reach if it were compromised right now” matters more than the sophistication of how the answer is enforced.

The enforcement point is code

Every place a policy decision is applied is software: a proxy, a gateway, a sidecar, a library, an agent. It parses untrusted input, handles authentication material, and makes a security decision, which is a description of the most dangerous category of code there is.

Bypasses in this layer are a recurring category of finding — path handling that disagrees with the application behind it, a header the enforcement point strips that the application still reads, a fallback route added for health checks that skips evaluation. When the enforcement point can be bypassed, the entire policy above it is a formality, and the failure is invisible from the policy side because the decision point was never asked.

Moving authorisation into a dedicated layer concentrates that risk in the same way the issuer concentrates issuance risk. It is still the right move, for the same reason: one well-understood component beats a thousand ad hoc ones. But it has to be treated as a security-critical service, with the update discipline and adversarial testing that implies, and not as infrastructure that was installed once.

Availability is a security property here

An architecture in which access decisions are made in the request path has made the decision path a dependency of everything.

That produces a failure mode with no comfortable answer. Fail closed and the identity infrastructure’s availability becomes the business’s availability, so a degraded decision point is an outage across the estate. Fail open and the control disappears during exactly the disruption an adversary might have engineered. Cache and there is a window of stale authority whose width you must choose deliberately.

The trade is real, the usual answer is a tolerated staleness window plus generous redundancy, and the point is that it should be chosen and stated rather than discovered at three in the morning.

What remains true

None of this is an argument for the perimeter, which failed worse and failed quietly. It is an argument for describing the model accurately.

Zero trust reduces the value of network position, which removes a large class of easy lateral movement. It makes access decisions explicit and therefore auditable. It bounds what a single compromised endpoint yields. Those are substantial, durable gains and they justify the work.

What it does not do is remove trust. It moves it into the issuer, the policy, the enforcement layer and the people who administer all three. A programme that knows this is defending four things carefully. A programme that believes the name is defending nothing in particular, very thoroughly.