ZTNA Pilots Fail for Three Predictable Reasons. Here Is the Phased Path That Works

Cybersecurity

Most ZTNA replacements stall after six months. Teams try to retire the VPN day one, ignore legacy apps, and underbudget identity work. A phased rollout that runs both stacks for 12-18 months ships successfully.

By Arjun Raghavan, Security & Systems Lead, BIPI · January 21, 2024 · 7 min read

An insurance customer signed a three-year deal with a major ZTNA vendor in 2023. The plan was to retire their global SSL VPN within 12 months. Eighteen months in, both stacks were still running, the ZTNA covered 40% of apps, and the security team was burned out from the migration politics. They called us to figure out why the program had stalled. The answer was: it never could have shipped on the original timeline. The plan ignored three structural realities.

Reality one: legacy apps do not speak modern protocols

ZTNA solutions assume your apps are reachable via HTTPS, RDP, SSH, or a documented protocol the connector understands. About 60-80% of enterprise apps qualify. The rest are:

• Thick clients that ship with a vendor-specific protocol (think Bloomberg Terminal, old Citrix XenApp, mainframe emulators)
• Apps that need broadcast/multicast on the local subnet (Avaya phones, some manufacturing OT)
• Server-to-server flows that depend on bidirectional connectivity (legacy databases, file replication)
• Apps that hardcoded private IP addresses in their config files and have not been touched in a decade

These apps need either a continued VPN tunnel, an app modernization project, or an architectural workaround like a jump host. None of those are quick. They are 6-18 month efforts each. If your ZTNA plan does not enumerate them up front, you will discover them at month 4 and the timeline collapses.

Reality two: your identity is not ready

ZTNA is identity-driven. Every access decision is 'who is this user, what device are they on, what is their risk score, what app do they want, do the policies allow it'. That requires:

• A clean directory with accurate group membership (most aren't)
• App-to-group mappings that reflect actual access patterns (most don't exist)
• Device posture signals (MDM enrollment, EDR healthy, OS version, disk encryption)
• Conditional access policies that match your security risk tolerance

If your identity foundation is shaky, ZTNA exposes every gap. Users get blocked because they are in the wrong group. Admins create exception groups to unblock them. Six months later you have 200 exception groups and no real policy enforcement. This is the most common failure mode we see.

Reality three: VPN is hard to retire because it is the universal answer

VPN works for everything because it puts the user on the network. ZTNA works for specific apps. Users who need 'just connect me to the network so I can troubleshoot' are not satisfied by ZTNA. Network engineers, IT operations, and any role that does ad-hoc network work need network-layer access for at least some scenarios.

The phased path that ships

Run ZTNA and VPN side by side for 12-18 months. Move workloads off VPN onto ZTNA in waves:

1. Wave 1 (months 1-3): SaaS and modern web apps. Fast wins, high user satisfaction. Users notice the better UX (no VPN connect step).
2. Wave 2 (months 3-6): Internal web apps. Most enterprises have 50-200 of these. Connector-friendly, identity-friendly.
3. Wave 3 (months 6-12): Thick client apps that work via ZTNA tunnel mode. RDP, SSH, database clients.
4. Wave 4 (months 12-18): Edge cases. Legacy thick clients, OT environments, server-to-server flows. Some stay on VPN permanently or move to dedicated jump infrastructure.
5. Wave 5 (post-18): Decommission VPN for general user population. Keep a small VPN footprint for break-glass and edge cases.

What success looks like

For one financial services client, the 18-month rollout ended at:

ZTNA is a 12-18 month identity and architecture project that happens to include a network access product. Treat it like network gear and you will fail. Treat it like an identity transformation and you will succeed.

Before you sign the ZTNA contract, run an app discovery exercise. Tag every app by its ZTNA readiness: easy, medium, hard, or never. The 'never' bucket is your residual VPN footprint. If that bucket is more than 15% of apps, your timeline is wrong and your ROI math is wrong. Better to know on day zero than month four.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.