Why "Zero Trust" Is Still Just a Marketing Term for Most

"Zero Trust" has become one of those phrases that sounds precise until you ask one simple question: what, exactly, stopped trusting what?

Most companies say they are doing Zero Trust because they added MFA, rolled out a VPN replacement, or put a shiny identity provider in front of a few internal apps. That's not Zero Trust. That's perimeter security with better branding.

If you still have a network model that says, "Once you're in, you're mostly fine," you have not eliminated trust. You have only moved it. Usually from the office firewall to an SSO login screen.

This matters because the threat model changed faster than the language. Work is distributed. Devices are unmanaged. vendors connect from everywhere. APIs talk to other APIs without a human ever touching the flow. And attackers no longer need to smash the front door. They borrow identity, ride a session, abuse a token, and look completely legitimate while they do it.

That's why I get skeptical when I hear vendors promise Zero Trust in a box. Trust is not a product category. It's an architectural discipline. And for most companies, it's still more aspiration than reality.

The original promise was right

The core idea behind Zero Trust is sound: stop treating network location as proof of legitimacy.

That was the old model. If traffic came from the corporate network, or over a trusted tunnel, it was considered safer by default. Applications trusted source ranges. Internal dashboards were exposed because "only employees can reach them." Flat networks made lateral movement easy. Shared credentials lingered for years. Machine identities were an afterthought.

In that world, compromise spread quietly. One phished account became a foothold. One weak bastion became an operations bridge. One forgotten service account became permanent access.

Zero Trust was supposed to kill that entire mental model. Verify every request. Scope access narrowly. Bind trust to identity and context, not location. Assume breach. Minimize blast radius.

That remains the right direction. But somewhere along the way, many organizations translated a strategic architecture into a procurement checklist.

Where most "Zero Trust" programs fail

In practice, I see five recurring failures.

• They keep the same trust assumptions under a new label. A user authenticates once in the morning and gets broad access all day. That's convenience, not Zero Trust.
• They focus on users and ignore workloads. Human SSO improves posture, but modern environments are dominated by service-to-service communication. If your machines still trust each other implicitly, the architecture is porous.
• They treat device posture as optional. Identity without endpoint context is weak identity. A valid login from a compromised laptop should not inherit full privilege.
• They issue long-lived credentials. Anything persistent eventually leaks. API keys, VPN certs, static tokens, hard-coded secrets-they are all future incident reports.
• They stop at access and ignore authorization. Getting into an app is one problem. Determining what you can do inside it is a different one. Many companies solve the first and leave the second dangerously broad.

The result is what I call "slightly less trust." Better than nothing, but not the model people think they bought.

What true Zero Trust actually looks like

A real Zero Trust architecture is not defined by one product. It's defined by how decisions are made at request time.

At a minimum, every access decision should be shaped by four things:

• Who is requesting access
• What device or workload is making the request
• Which resource is being requested
• Under what context the request is happening right now

That context includes geography, device health, time, sensitivity of the action, workload identity, recent behavior, and whether the credential is fresh enough for the risk level involved.

Notice what's missing from that list: IP range as a primary trust signal.

In a true Zero Trust model, access becomes:

• Identity-bound: every human and workload has a distinct, auditable identity
• Device-aware: the state of the endpoint affects the decision
• Ephemeral: sessions and credentials expire quickly and are re-evaluated continuously
• Least-privileged: access is narrow by default, not broad by habit
• Segmented: compromise in one area should not create invisible highways to the rest of the environment
• Observable: every decision leaves evidence good enough for response, forensics, and tuning

This is the difference between "trusted user on trusted network" and "specific identity on a healthy device performing a permitted action for a limited time."

The VPN test is crude, but useful

I often use a deliberately provocative shorthand: if you still depend on a VPN for broad internal access, you probably do not have Zero Trust.

That doesn't mean every tunnel is automatically wrong. Some legacy environments still need them. Some industrial systems cannot be modernized in one step. Some emergency paths must remain available when more elegant control planes fail.

But the VPN test is still useful because it exposes the architectural question: what happens after connection?

If the answer is "the user can now see a large internal surface area," you've preserved the old trust boundary. You've just moved it closer to the endpoint.

Zero Trust should make network access less meaningful, not more. The network should be transport. The actual trust decision should happen at the application, identity, and policy layer.

The overlooked half: workload identity

The next big shift is that Zero Trust can no longer be human-centric.

In modern infrastructure, machines outnumber people by orders of magnitude. Agents call APIs. CI pipelines deploy artifacts. microservices fetch secrets. edge nodes make autonomous routing and mitigation decisions. If those identities are coarse, shared, or static, you've built a human Zero Trust shell around a machine trust swamp.

This is why workload identity is becoming foundational. Every service should authenticate as itself. Every call should be attributable. Every machine credential should be short-lived and scoped to one role. And no system should be able to impersonate three others just because someone reused a secret six months ago.

For security teams, this is operationally harder than SSO rollout. But it is where the real reduction in blast radius happens.

Why most rollouts stall

Zero Trust projects don't usually fail because the principle is wrong. They fail because the migration touches power structures, legacy systems, and engineering habits.

Least privilege breaks convenience. Device compliance breaks bring-your-own-chaos. Short-lived credentials break brittle scripts. Micro-segmentation exposes undocumented dependencies. Stronger authorization reveals how many users had access they could never justify.

In other words: Zero Trust works by removing ambiguity. Organizations often discover they were relying on that ambiguity to move fast.

That's why successful programs are not framed as "install this platform." They are framed as a multi-quarter redesign of access, identity, and operational hygiene.

A practical sequence that actually works

If I were starting from scratch today, I would not begin with a giant transformation deck. I would begin with sequence.

• First, inventory identities. Humans, service accounts, machines, automation, agents-everything. If you can't name it, you can't govern it.
• Second, classify crown-jewel systems. Not every workload needs the same rigor on day one. Start where compromise hurts most.
• Third, eliminate shared and long-lived credentials. This one move improves security immediately and forces better architecture.
• Fourth, move authorization closer to the resource. Don't rely on network reachability as a permission model.
• Fifth, enforce device posture for privileged actions. The more sensitive the action, the stronger the contextual proof should be.
• Sixth, segment aggressively. Especially between control planes, data planes, and internal administrative surfaces.
• Seventh, log policy decisions, not just events. You need to know not only that access happened, but why it was allowed.

That's not glamorous. But real security rarely is. It's disciplined reduction of unnecessary trust, repeated until the environment stops depending on blind faith.

The strategic payoff

Done properly, Zero Trust is not just a security upgrade. It's an operating model upgrade.

You get cleaner identity architecture. Better auditability. Faster incident containment. Safer automation. More confidence in distributed work. More resilience when a credential leaks, a device is compromised, or a third-party integration behaves unexpectedly.

Most importantly, you stop lying to yourself about what "internal" means. In 2026, internal is not a place. It's a policy outcome.

That is the mindset shift many organizations still haven't made.

Call it what it is

I'm not against the term Zero Trust. I'm against using it too cheaply.

If your architecture still grants broad standing access, trusts static credentials, ignores device state, and treats workload identity as optional, call it an access modernization program. Call it identity hardening. Call it a step in the right direction.

Just don't call it Zero Trust yet.

Because the real version is harder than the brochures suggest. It requires architectural honesty. It forces tradeoffs. And it asks leaders to give up the comforting fiction that once someone is "inside," they are safe enough.

They aren't. They never were.

The companies that understand this earliest won't just be more secure. They'll be structurally more resilient-because they built their systems around continuous verification instead of inherited trust.

That's the difference between marketing language and infrastructure reality. And in security, reality always wins.

---