In Zscaler’s ThreatLabz 2025 VPN Risk Report, based on a Cybersecurity Insiders survey of 632 IT and cybersecurity professionals, 65% of organizations said they planned to replace their VPNs within the year, and MarketsandMarkets projects the ZTNA market will grow from $1.34 billion in 2025 to $4.18 billion by 2030. Those numbers tell you where the industry expects to go. They do not tell you how to get there, because vendors mostly publish their own half of the story: the onboarding guide for their product, never the long stretch when VPN and ZTNA run side by side and your help desk fields tickets for both.
This is the missing middle: a phased playbook for a VPN to ZTNA migration that survives contact with legacy applications, plus honest mechanics for three platforms that appear on many enterprise shortlists: Zscaler Private Access, Palo Alto Networks Prisma Access, and Microsoft Entra Private Access.
The honest starting point: VPN won’t hit zero
Every ZTNA pitch deck ends with the VPN concentrator in a dumpster. Real migrations don’t. Legacy applications that lack modern authentication (thick clients speaking proprietary protocols, server-initiated connections, unauthenticated printer and scanner traffic, that ERP module nobody has touched in years) will resist brokered, identity-centric access. Plan for a residual VPN footprint for years, sized from your own inventory, or budget the application-remediation work to eliminate it.
The takeaway for the steering committee: the goal is not “zero VPN.” The goal is shrinking the flat-network blast radius from everything to a short, named list of exceptions with an owner and a review date. Frame it that way on day one and the project survives its first awkward legacy app. Frame it as VPN elimination and you will be explaining a “failed” migration to the board long before the project ends.
Phase 1: Inventory apps and their auth
You cannot broker access to applications you cannot name. Start with a dedicated discovery phase: pull VPN logs, NetFlow, and firewall data to build the real application list, not the CMDB fiction. Expect to find more internal apps than the CMDB lists. Then classify each app on two axes:
- Auth readiness: does it speak SAML/OIDC, can it sit behind a proxy with header-based auth, or is it hard-coded to NTLM, Kerberos-only, or nothing at all?
- Traffic pattern: client-initiated web or TCP (easy), long-lived sessions and VoIP (harder), server-initiated or peer-to-peer like remote support tools and softphones (hardest; check your vendor’s connector support explicitly).
The major platforms now help here. Zscaler says ZPA can “discover applications automatically” and offers “AI-generated recommendations on app segments and policies.” Palo Alto says its ZTNA Connector can “automatically discover and onboard private applications” into Prisma Access. Microsoft’s Quick Access lets you tunnel a primary group of FQDNs, IP addresses and IP ranges first, then carve out per-app Global Secure Access apps with their own Conditional Access policies. Use the tooling, but keep a human owner per application. Discovery output is your migration backlog; treat it like one.
Phase 2: Run ZTNA and VPN in parallel
Parallel running is where migrations quietly die, so set rules before you start. Deploy the ZTNA client alongside the VPN client to a small pilot ring of users, and include your loudest power users deliberately, because they find breakage fast. Route only pilot apps through the broker; everything else stays on VPN. Critically, make the routing decision in the client, not the user: if users have to choose which tunnel to use, they will choose wrong and blame the new thing.
Two rules worth adopting. First, hold each app in parallel long enough to cover its full business cycle, including month-end batch behavior, before cutting VPN routes to it. Second, set a firm end date for the parallel period at the start of the project. Without one, you pay double licensing, double client overhead, and double help-desk training indefinitely, and the migration becomes a lifestyle.
Phase 3: Migrate app-by-app, not user-by-user
The instinct is to migrate by department. Resist it. Migrating user-by-user means every user needs every app working on day one: one broken legacy app rolls back the whole cohort. Migrating app-by-app means an application is either served by the broker for everyone or it isn’t, and your exception list shrinks visibly week over week. It also forces the conversation that matters: for each app, either it gets a connector and a policy, it gets remediated to modern auth, or it goes on the residual-VPN exception list with a named owner.
Sequence by risk and ease: start with internal web apps behind SSO (fast wins, visible progress), then TCP thick clients, then the awkward tail. And write policy for non-human identities as you go. Service accounts, RPA bots, and increasingly AI agents need scoped access paths too, a problem Enterprise Techie covers in its AI agent identity governance guide. Bolting that on after the human migration means doing discovery twice.
Phase 4: Decommission before full coverage
Do not wait for full coverage. Once most internal applications are served through the broker, and every remaining app has a named owner and a plan, start pulling VPN infrastructure: shrink concentrator capacity, cut licensing tiers at renewal, and move the residual VPN to a segmented enclave that reaches only the exception-list apps, not the flat network. That last step is the easiest to skip, and it is the whole point. A legacy VPN that lands users in a small enclave is a contained risk; one that lands them on the old flat network means you ran a multi-year project without changing your blast radius.
The VP-ready takeaway: agree the decommission trigger in advance as a coverage target you set, and make the residual VPN terminate in an enclave, not the core.
Vendor mechanics: Zscaler, Palo Alto, Microsoft
| Zscaler Private Access | Prisma Access (Palo Alto) | Entra Private Access (Microsoft) | |
|---|---|---|---|
| Model | Cloud broker; endpoint client plus outbound-only App Connectors | SASE service with inline threat prevention and DLP on the private-app path | Identity-first; Conditional Access extended to private apps |
| Strongest at | Broker at scale; AI-generated app segmentation recommendations | Inline threat inspection of private-app traffic; PAN-OS and Panorama shops | Entra ID-standardized orgs; included in Microsoft Entra Suite |
| Watch for | Quote-based pricing; platform lock-in as scope grows | Module and license-tier complexity, including connector limits by license | Requires Entra ID P1 or P2; deepest value assumes a Microsoft stack |
| Good fit | Large enterprises with aggressive segmentation goals | Security-first shops wanting one inspection stack everywhere | M365-heavy mid-to-large orgs optimizing spend |
Zscaler Private Access
Zscaler calls ZPA “the world’s most deployed ZTNA solution.” It brokers one-to-one connections between authorized users and specific apps, and Zscaler’s own App Connector listing says “Connectors only connect outbound; they do not need any inbound open ports to operate correctly.” Its AI-generated segmentation recommendations can shorten Phase 1. Where to be careful: pricing is quote-based, so model how cost scales as you extend coverage from remote workers to office users and third parties, and you are committing to Zscaler’s cloud as the control plane for everything. Good fit for large enterprises that want segmentation depth.
Prisma Access (Palo Alto Networks)
Prisma Access’s differentiator is inspection on the private-app path: Palo Alto says ZTNA Connector traffic gets “AI/ML-powered in-line protections” and “full DLP support.” Connector virtual machines automatically connect to the closest Prisma Access location, so you don’t hand-build IPsec tunnels to each data center. The trade-off is complexity: multiple modules and license tiers (the base ZTNA or Enterprise license includes 10 connectors, and the Private App Access add-on up to 200), though Panorama-managed shops recover much of that in operational familiarity. Enterprise Techie compares the two SASE heavyweights directly in its Zscaler vs Palo Alto SASE brief.
Microsoft Entra Private Access
Microsoft’s entry, part of Global Secure Access, extends the Conditional Access policies you already run for SaaS to private applications; Microsoft says it “builds on the capabilities of Microsoft Entra application proxy and extends access to any private resource, port, and protocol.” It is the value play if you already pay for Microsoft Entra Suite, which includes it, or Microsoft 365 E7, which Microsoft says includes Entra Suite. Standalone, Microsoft lists Entra Private Access at $5.00 per user per month, paid yearly, as of October 2026, and users also need Entra ID P1 or P2. Inspection depth on private-app traffic is the area to test hardest against Prisma Access and ZPA. Microsoft-centric organizations should shortlist it first; heterogeneous shops should pilot it hardest.
Frequently asked questions
Can ZTNA completely replace a VPN?
For most enterprises, not entirely, and not soon. Client-initiated web and TCP applications migrate cleanly; server-initiated traffic, legacy auth, and some VoIP or thick-client workloads do not. Plan for a residual VPN footprint confined to a segmented enclave, and treat every app on that list as remediation debt with a named owner.
How long does a VPN to ZTNA migration take?
It depends on how many internal apps you have and how many still rely on legacy authentication, so build the timeline from your Phase 1 inventory rather than a vendor’s onboarding guide. Sequence it as discovery, then a pilot, then app-by-app waves, with a firm end date for parallel running. An open-ended parallel phase means you are paying for two access stacks indefinitely and should force the exception-list decision.
Which applications don’t work well with ZTNA?
The usual offenders: server-initiated connections (remote support, some management tools), peer-to-peer traffic like softphones, unauthenticated device traffic such as printing and scanning, and anything hard-wired to legacy network auth. Vendor support varies, so verify your specific protocols against each platform’s connector documentation before you commit to a decommission date.
Is ZTNA cheaper than a VPN?
Not in the first year: you pay for both during the parallel phase. Pricing models differ. Microsoft lists Entra Private Access at $5.00 per user per month (paid yearly, with Entra ID P1 or P2 required) and includes it in Microsoft Entra Suite, while Zscaler and Palo Alto do not publish list prices on their websites. The savings arrive later: retired concentrators, a smaller breach blast radius, and, for Microsoft-licensed shops, ZTNA bundled into suites you may already buy. Model it over three years, not one, and get quotes from all three.
Enterprise Techie sends vendor-honest analysis like this once a week: get the brief by email, free.
Buying? Start from RFPhub’s free ZTNA RFP template.