Zero trust is easy to endorse and hard to run. This post focuses on the practical, hands-on reasons zero trust network access implementations break in production — the issues security and network teams actually hit when they move from architecture diagram to live enforcement — backed by data from Gartner, the Cloud Security Alliance, NIST, and field research from ZTNA and microsegmentation vendors. If you're still getting oriented on the fundamentals of ZTNA, start there and come back for the deployment specifics below.
The Adoption-Execution Gap, in Numbers
- 82% of organizations view zero trust as essential, yet only 17% have fully implemented it, and 88% report significant implementation challenges (Expert Insights, 2025).
- 35% of organizations that attempted or partially attempted a zero trust initiative suffered failures that adversely affected the business (Gartner).
- Only 6% of organizations have fully implemented zero trust; 36% are still in early deployment (Gartner/Forrester data via CSO Online).
- Gartner expects 30% of organizations to abandon their zero trust initiatives entirely by 2028, citing complexity and integration failures (Network World).
9 Practical Reasons ZTNA Breaks in Deployment
1. Legacy applications weren't built to survive continuous verification
NIST's SP 800-207 assumes identity, device posture, and context can be evaluated on every request. Most legacy applications can't cooperate — they lack modern authentication hooks or APIs, and interdependent legacy subsystems can break outright when suddenly placed behind new access controls, because they were never designed for isolation. Reviews of implementation barriers found legacy system integration issues in 65% of documented cases and overall complexity in 74%. Teams that don't plan for this end up quietly exempting legacy systems into a “trusted” zone — recreating the exact perimeter blind spot ZTNA was meant to close.
2. Microsegmentation gets rolled out before dependency mapping is done
Microsegmentation is often bundled into ZTNA rollouts, and it's where projects most visibly break things. Without a full map of how applications and services actually talk to each other, segmentation policies end up guessing — and guesses block legitimate traffic. Zero Networks' field research on failed microsegmentation projects names this directly: organizations “struggle to map out every application dependency and network flow,” and poorly configured policies “inadvertently block legitimate traffic, leading to downtime and user frustration” that causes teams to hesitate or abandon the project entirely. The same research flags scalability as a compounding problem: as environments grow across hybrid and multi-cloud infrastructure, hand-maintained segmentation policies stop keeping up. Map dependencies before you segment anything — our segmentation primer covers the groundwork this section assumes.
3. Latency turns ZTNA into something employees route around
Performance, not philosophy, is what kills ZTNA adoption on the ground. DNS resolution, TLS handshakes, policy evaluation, and routing backhaul commonly account for more than 80% of the delay users notice after a ZTNA rollout (Zero Trust Explained). Many ZTNA platforms still route traffic through a centralized cloud broker or regional inspection hub, which adds latency amplification and traffic hairpinning rather than removing it. The behavioral result is predictable: users bypass controls, teams file exceptions, split-tunnel policies quietly expand, and the legacy VPN that ZTNA was supposed to replace stays active as a permanent fallback.
4. Overly strict policies push users into shadow IT
When ZTNA enforcement makes routine work slower or breaks a legitimate workflow, employees don't file a ticket — they find a workaround: personal devices, unsanctioned apps, or shared logins. This isn't hypothetical; VPN- and access-related issues already account for roughly 30% of help desk tickets in organizations with hybrid workforces, an early warning sign of the friction that drives shadow IT once stricter ZTNA policy is layered on (TerraZone, 2025). Every workaround is a policy gap that undermines the access model the project was built to enforce.
5. Policies go straight to full enforcement without a monitoring phase
A recurring, avoidable mistake is skipping a “monitor-only” or observation period before enforcing new access policies. Analysts studying dependency-mapping failures specifically recommend deploying policies in monitor-only mode first, to evaluate impact and accuracy before flipping enforcement on. Teams that skip this step discover which traffic they misjudged only after production breaks.
6. Non-human identities don't fit tools built for human logins
Service accounts, API keys, bots, and now autonomous AI agents typically outnumber human identities by roughly 50 to 1 inside large enterprises, and the large majority operate outside any formal governance program (Identity Defined Security Alliance). Most ZTNA and IAM tooling was built around human sign-in patterns — passwords, MFA prompts, session timeouts — and doesn't map cleanly onto machine-to-machine traffic. Autonomous agents in particular can carry valid tokens and pass identity checks while taking downstream actions nobody explicitly approved, a gap that human-centric zero trust controls weren't designed to catch. Non-human identities need their own governance model, separate from human user groups — not a bolt-on to it.
7. IoT and resource-constrained devices can't run the agents ZTNA needs
Continuous verification assumes a device that can run an agent, respond to posture checks, and handle frequent re-authentication. Many IoT and operational technology devices can't. Their hardware constraints and device heterogeneity make it difficult to support computationally intensive security checks, and forcing continuous verification onto them can measurably degrade their performance — which is why these devices are so often quietly excluded from ZTNA policy instead of properly accounted for.
8. Cross-team resource and expertise limits stall the technical build
Microsegmentation and ZTNA policy engineering are specialized, ongoing work — tagging assets, tuning rules, and maintaining policy as environments change. Zero Networks' research on failed projects points to this directly: the work “demands significant time, specialized expertise, and financial investment,” and IT teams that are already stretched thin can't sustain it once the initial rollout is done, so policies stop getting updated and drift out of accuracy.
9. Visibility gaps mean nobody can tell if policy is actually correct
Underneath most of the failures above is one common gap: fragmented tooling and outdated asset inventories that leave no clear picture of what exists and how it communicates. CSA's 2025 research found insecure identities and over-permissioned access are now the top cloud security risk, and 21% of security teams cite difficulty enforcing least privilege at scale as a top challenge. Without that visibility, ZTNA policy is a best guess dressed up as an architecture.
The Organizational Factors That Compound All of This
The technical breakage above rarely happens in isolation — it's usually made worse by a few organizational conditions worth naming briefly: no strategic, measurable plan before deployment begins (Gartner's most-cited root cause of failed initiatives); a cybersecurity skills shortage that leaves the specialized policy work in #8 permanently under-resourced; security, IT, and identity teams operating in silos with no shared owner; too many competing frameworks (NIST, CISA, sector-specific mandates) causing decision paralysis; and scoping ZTNA as a simple VPN replacement rather than an identity- and context-aware model. These factors set the conditions for failure; the nine items above are where it actually shows up.
How to Avoid These Failure Patterns
- Map dependencies before you segment anything. Run traffic analysis long enough to understand real application-to-application communication before writing enforcement policy.
- Deploy new policies in monitor-only mode first. Watch what a policy would block before you let it block anything.
- Budget for legacy systems explicitly. Decide — deliberately, not by default — how systems that can't support modern auth will be handled, rather than quietly exempting them.
- Test for latency before rollout, not after. Measure DNS, handshake, and policy-evaluation overhead under real user conditions, and prefer architectures that avoid unnecessary traffic hairpinning.
- Inventory non-human identities separately from human ones. Service accounts, API keys, and AI agents need their own governance model, not a bolt-on to human IAM.
- Decide how OT/IoT devices fit in up front. Don't let resource-constrained devices become an unplanned exception that quietly bypasses policy.
- Staff for the maintenance phase, not just the rollout. Policy tuning is ongoing operational work; budget headcount or managed services accordingly.
FAQ
What's the most common technical reason ZTNA projects fail?
Breaking production traffic — most often through microsegmentation policies written without full dependency mapping, or legacy applications that can't support continuous verification. Both are avoidable with monitor-only testing before enforcement.
Does ZTNA add noticeable latency?
It can. DNS resolution, TLS handshakes, policy evaluation, and backhaul routing through centralized brokers commonly account for the majority of added delay, and poor performance is one of the most common reasons users bypass ZTNA controls entirely.
Can ZTNA cover IoT devices and service accounts?
Not automatically. Most ZTNA tooling is built around human login patterns. IoT devices often can't run the required agents, and non-human identities (service accounts, API keys, AI agents) need separate governance, since they now outnumber human identities by roughly 50 to 1 in large enterprises.
What percentage of zero trust projects fail?
Gartner found 35% of organizations that attempted a zero trust initiative suffered failures that hurt the business, and projects 30% of organizations will abandon their initiatives by 2028.
What is “monitor-only mode” in a ZTNA rollout?
A staged deployment step where new access policies log what they would block — without actually blocking it — so teams can review the impact and fix false positives before switching enforcement on. Skipping this step is one of the most common, and most avoidable, causes of production breakage.
Should microsegmentation and ZTNA be rolled out at the same time?
Only if dependency mapping is complete first. Bundling microsegmentation into a ZTNA rollout before you understand how applications and services actually communicate is one of the leading causes of blocked legitimate traffic and abandoned projects.
How should organizations govern non-human identities like service accounts and AI agents?
Separately from human identity management. Service accounts, API keys, bots, and AI agents need their own inventory and governance model — tools built around passwords, MFA prompts, and session timeouts don't map cleanly onto machine-to-machine traffic, and autonomous agents can pass identity checks while taking actions nobody explicitly approved.
Key Takeaways
- Most ZTNA failures show up in deployment — broken app dependencies, latency-driven workarounds, and unmanaged non-human identities — not in the strategy phase.
- Microsegmentation without dependency mapping and policy testing is one of the most common, and most avoidable, causes of production breakage.
- Non-human identities and IoT/OT devices are routinely left out of ZTNA design because existing tooling assumes a human logging in.
- Organizational gaps (no plan, no ownership, skills shortages) don't cause failure directly — they remove the capacity to catch and fix the technical issues before they cause damage.
Further Reading
- How Does ZTNA Work? Zero Trust Explained for Business Security
- ZTNA vs. VPN: What's the Difference?
- The ZTNA Life Cycle Approach
- What to Know Before Choosing a ZTNA Approach or Provider
- CloudConnexa Cyber Shield
Sources
- Gartner Predicts 75% of U.S. Federal Agencies Will Fail to Implement Zero Trust Security Policies Through 2026 — Gartner Newsroom
- Zero trust isn't broken, but most companies are doing it wrong — Network World
- Zero trust isn't broken. Most companies just do it wrong. — CSO Online
- Zero Trust Adoption Statistics and Trends in 2025 — Expert Insights
- Identity Security: Cloud's Weakest Link in 2025 — Cloud Security Alliance
- NIST Special Publication 800-207: Zero Trust Architecture — National Institute of Standards and Technology
- 5 Real Reasons Why Microsegmentation Projects Fail — Zero Networks
- Reduce ZTNA latency: tactical fixes for faster secure access — Zero Trust Explained
- VPN Fatigue: The Cost to Productivity & How ZTNA Fixes It — TerraZone
- Outnumbered and Underprotected: The Hidden Risk of Non-Human Identities — Identity Defined Security Alliance
Note: Some figures above (e.g., help desk ticket share, latency-overhead breakdown) are drawn from vendor field research and industry surveys rather than a single peer-reviewed study; they're representative of commonly reported patterns, and readers citing this for a formal risk assessment should verify against a primary study for their sector.