Zero Trust: Why 96% Adopt It and Still Get Breached

Zero trust is no longer a fringe idea. According to Okta’s State of Zero Trust Security report, 61% of organizations say they already have a zero trust initiative in place, and another 35% plan to start one — 96% combined. And yet, in the same window, the 2026 Verizon Data Breach Investigations Report found that software vulnerability exploitation overtook stolen credentials as the top way attackers get in for the first time in the report’s 19-year history, and ransomware is now present in 48% of all breaches.

Those two facts together point at the same gap: most companies that say “we do zero trust” mean “we bought multi-factor authentication.” That’s not nothing, but it’s not zero trust either. Here’s what the model actually requires, where it comes from, and what to do about it without ripping out your infrastructure.

What Zero Trust Actually Means (NIST’s Definition, Not the Marketing One)

Zero trust isn’t a product category. It’s a framework, formally defined by the U.S. National Institute of Standards and Technology in NIST Special Publication 800-207 (August 2020). NIST describes it as “an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.” Four ideas carry the whole model:

• No implicit trust. Being on the corporate network or owning the device doesn’t earn an account anything. Location stopped being a security signal the day remote work and cloud infrastructure became normal.
• Discrete authentication and authorization. Verifying who someone is and verifying what they’re allowed to touch are two separate checks, run every time, not once at login.
• Resource-centric protection. Security wraps around the actual asset — a database, an API, a file share — instead of a network segment. The segment can be breached; the resource still has to defend itself.
• Assumption of compromise. The architecture is designed as if an attacker is already inside. That’s the part most “zero trust” rollouts skip entirely.

Why Attackers Don’t Care What You Call It

The 2026 Verizon DBIR is useful here because it shows what’s actually changing on the attacker’s side, not what vendors are selling. Software vulnerabilities now account for 31% of breaches, beating stolen passwords as the top initial access vector — a reversal from nearly two decades of credential theft leading the field. Generative AI is already bolstering 15% of distinct attack techniques tracked in the report. And ransomware, once it’s in, spreads through exactly the kind of flat, trust-the-network architecture that zero trust is designed to remove.

The lesson isn’t “credentials don’t matter anymore.” It’s that attackers now have two doors instead of one, and a perimeter built to stop phishing does nothing against a patched-but-not-patched-fast-enough API. Zero trust doesn’t try to keep attackers out of every door. It tries to make sure that getting through one door doesn’t open the rest of the building.

Zero Trust Is Not a Product You Buy

This is the part nobody selling a zero trust “solution” wants to say out loud: zero trust is not a product you install. It’s the assumption that you’re already breached.

A company that deploys SSO and MFA and stops there has made login harder. It hasn’t changed what happens after login. If a compromised account can still reach every file share, every database, and every internal tool with one valid session, the architecture is exactly as flat as it was before — just with a better lock on the front door. Okta’s own research on adoption barriers backs this up: organizations cite cost, technology gaps, and privacy/data regulations as the main obstacles to real zero trust — not because the principle is complicated, but because applying it to every resource, not just the login screen, is genuinely hard operational work.

Four Moves That Make Zero Trust Real

Not a login screen. An architecture. In practice, that comes down to four concrete changes, roughly in the order most teams can actually execute them:

1. Verify every request, not just the first one. Session validity, device posture, and context (is this the usual location, the usual hour, the usual action for this account?) get checked continuously, not just at the login prompt. 2. Segment access by resource, not by network zone. An account’s access to the finance database shouldn’t be a side effect of being on the finance VLAN. Each resource defines who can reach it and under what conditions, independent of network topology. 3. Assume breach — and limit the blast radius. Logging, least-privilege access, and micro-segmentation exist so that one compromised account or device can’t become a company-wide incident. Design for containment, not just prevention. 4. Start with identity, not infrastructure. The cheapest, fastest-moving part of a zero trust rollout is tightening who can authenticate as what, and why. Network re-architecture can follow once identity is solid — doing it in the other order burns budget on infrastructure while the actual access-control gap stays open.

Where This Fits With What You Probably Already Have

Zero trust isn’t a rip-and-replace project. If your cloud workloads are already covered by a CNAPP and Defender-based approach, that’s already doing resource-centric protection for cloud assets — zero trust principles extend the same logic to identity and on-prem access. If you’re running XDR and SIEM for threat detection, the continuous verification and blast-radius containment pieces plug directly into the telemetry you’re already collecting. And because ransomware specifically exploits flat, trust-by-default networks, the 25% rise in ransomware cases we covered recently is a direct argument for segmentation, not a separate problem.

Frequently Asked Questions

Is zero trust the same as multi-factor authentication (MFA)? No. MFA is one control inside a zero trust architecture — it strengthens the authentication step. Zero trust also requires authorization checks per resource, continuous verification instead of one-time login trust, and designing for the assumption that an account will eventually be compromised. A company can have MFA everywhere and still have zero trust architecture nowhere.

Do we need to replace our firewall or VPN to adopt zero trust? Not necessarily, and not first. Identity and access controls (who can reach what, verified continuously) deliver most of the risk reduction and can be layered onto existing infrastructure. Network-level changes — segmentation, replacing flat VPN access with per-application access — typically come second, once the identity layer is solid.

How long does a real zero trust rollout take? There’s no single number that applies to every company, and anyone who gives you one without seeing your environment is guessing. What’s measurable is progress: which resources now require per-request verification versus network-location trust, tracked resource by resource.

Is zero trust only for large enterprises? No — it scales down. A 20-person company with cloud file storage and a handful of SaaS tools can apply the same four moves (verify every request, segment by resource, assume breach, start with identity) at a fraction of the operational overhead a 5,000-person enterprise needs, because there are fewer systems to cover.

What’s the single biggest mistake companies make? Treating zero trust as a purchase instead of a redesign. The vendors are happy to sell a “zero trust platform.” The actual work — deciding, resource by resource, who should be able to reach it and under what conditions — doesn’t come in a box.

---

Not sure where your own access architecture actually stands versus where it looks like it stands? That gap is exactly what a free security audit is for, and it’s the first thing our cybersecurity team checks before recommending anything.