Organizations spent billions implementing zero trust architecture over the past five years. It's been called the end of the network perimeter, the future of security, the framework that finally assumes breach instead of pretending it won't happen. And companies that fully adopted it are still getting breached — sometimes through the exact systems they deployed to enforce it.

Zero trust isn't a failed idea. It's a misunderstood one. And the misunderstanding is where the breaches live.

Zero trust is a security model built on a simple, powerful principle: never trust, always verify. Instead of assuming that anything inside the network perimeter is safe — the old model, where getting past the firewall meant you were treated as trusted — zero trust treats every request as potentially hostile, regardless of where it comes from. Every access attempt must prove its identity and authorization, every time. On paper, it's the most coherent response we've developed to the reality that perimeters always eventually get breached.

The principle is sound. That's not what's in question. What's in question is the gap between the principle and what organizations actually deploy when they say they've "implemented zero trust" — because that phrase has come to mean almost anything a vendor wants it to mean, and the distance between the architecture in the diagram and the architecture in production is exactly where attackers operate.

The assumption that sinks most zero trust deployments is that zero trust is a product you buy and switch on. Vendors sell it that way. Buy the identity platform, deploy the access broker, turn on the policy engine, and you've achieved zero trust. The architecture diagram shows neat boxes verifying each other, and the implication is that once those boxes are in place, the "never trust, always verify" principle is now enforced across your environment.

Zero trust is not a product. It's a design philosophy that has to be applied to every system, every identity, and every trust relationship in an environment — and the moment one of those relationships gets an exception, the whole model has a hole in it.

The deeper assumption is that verification equals security. But verification only checks whether a request is authorized — it says nothing about whether the authorized identity has been compromised. If an attacker steals legitimate credentials or hijacks a valid session, zero trust will dutifully verify them and grant access, because from the system's perspective, everything checks out. The framework is doing exactly what it was designed to do. It just wasn't designed to catch this.

The breaches happen in the gaps the diagrams don't show. The first and most common gap is incomplete coverage. An organization rolls out strict verification for its cloud applications and modern systems, but the legacy database, the old file server, the industrial control system that can't support modern authentication — those get exceptions. They have to keep running, so they're carved out of the policy. Attackers don't attack the part of your environment you secured. They find the exception, and the exception is almost always the thing too old or too critical to touch.

The second gap is identity compromise, and it's the one that should worry people most. Zero trust shifts the entire weight of security onto identity — if identity is the new perimeter, then stealing an identity is breaching the perimeter. Modern attacks reflect this exactly. Phishing for session tokens, SIM-swapping to defeat phone-based authentication, social-engineering help desks into resetting credentials, and abusing the single sign-on systems that zero trust depends on. When the verification system itself becomes the highest-value target, compromising it doesn't just bypass zero trust — it weaponizes it, because now the attacker is the verified, trusted identity moving freely through an environment that assumes verified means safe.

The pattern beneath the breaches

Every zero trust failure traces back to the same root: a place where verification was assumed but not actually enforced, or where verification succeeded but the verified identity was already compromised. The framework didn't break. The trust assumptions underneath it did.

The third gap is the most human. Zero trust is operationally demanding. Every exception, every "just make it work for now," every overly broad access policy written under deadline pressure quietly reintroduces the implicit trust the model was supposed to eliminate. Over months and years, these accumulate. The architecture that was genuinely zero trust at launch slowly becomes zero trust in name only, riddled with the small compromises that real organizations make to keep functioning. The diagram still says zero trust. The reality has drifted somewhere else entirely.

The mental model worth carrying is this: zero trust is not a state you achieve — it's a property you continuously maintain, and it's only ever as strong as its weakest trust relationship. The question is never "have we implemented zero trust?" That question invites a yes, and the yes is almost always a comforting fiction. The real question is "where in our environment does trust still get granted implicitly, and what would it take for an attacker to become a verified identity?" Those two questions point directly at the gaps the framework can't see on its own.

More broadly, this is the trap that swallows every hyped security framework. The name becomes a destination, the destination becomes a checkbox, and the checkbox becomes a substitute for the ongoing judgment the framework was supposed to encode. Zero trust done well is genuinely powerful — it limits how far a breach can spread and forces attackers to work for every inch. But it earns that power through relentless maintenance of its trust boundaries, not through the act of buying it. The framework is a discipline, not a purchase. The organizations that forget this are the ones still showing up in breach reports with a zero trust architecture they were certain would protect them.

I've watched organizations treat zero trust like a finish line, announce they'd crossed it, and quietly accumulate exceptions until the model meant nothing. The framework didn't fail them. Their belief that they were done did. The most dangerous moment in any security program is the moment you become certain you're protected — because that's the moment you stop looking for the gap. I'm curious where your own thinking sits on this.

This week's question

If your organization claims to do zero trust — where are the exceptions? The legacy systems, the "temporary" access grants, the carve-outs nobody revisited. Hit reply and tell me where the gaps actually are. I read every response.

Think clearly,

— DJ Brar

SKBSEC | SKB Decoded  ·  www.skbsec.com