ZTNA Rollout Playbook: From Pilot to Full Deployment

Start with 3-5 low-risk internal web apps, prove sub-second access and user satisfaction, then expand to business-critical apps in 4-week waves. Define 3 posture tiers (basic, elevated, admin). Track three metrics: time-to-access, helpdesk tickets per wave, and VPN usage decline. Cut VPN when usage drops below 5% of total sessions.

ZTNA is the single most impactful security project most organizations can deploy in 2026. It replaces VPN, eliminates lateral movement risk, and delivers a user experience so much better than legacy VPN that users become advocates instead of resistors. But the deployment has to be sequenced correctly. I have seen ZTNA rollouts fail not because the technology did not work, but because the team tried to migrate 200 applications simultaneously and drowned in edge cases. This playbook breaks the deployment into four waves over 16 weeks, with clear go/no-go criteria between each wave.

Prerequisites before you start

1. Modern identity provider with MFA enforced. Okta, Microsoft Entra ID, or Ping Identity — any SAML 2.0/OIDC-compliant IdP works. If you are still running on-premises ADFS without cloud sync, fix that first. ZTNA without strong identity is pointless.
2. Application inventory. You cannot migrate applications you have not cataloged. Document every application accessed through VPN: name, URL or IP, protocol (HTTP/HTTPS, SSH, RDP, custom TCP/UDP), user population, criticality tier, and whether it supports reverse proxy or requires network-level access.
3. Endpoint management. You need visibility into device posture: OS version, patch level, EDR status, disk encryption. This comes from your endpoint management platform (Intune, Jamf, CrowdStrike) integrated with the ZTNA vendor. Without posture data, you are deploying identity-only ZTNA, which is better than VPN but leaves a gap.
4. Executive sponsorship. ZTNA touches networking, security, identity, and every application team. You need a sponsor at the VP or CISO level who can break ties when teams disagree on posture policies or migration timelines.

Wave 1: Pilot (Weeks 1-4)

Select 3-5 internal web applications with broad user bases and low risk: intranet portal, HR self-service, internal wiki, ticketing system, or company directory. These applications are accessed daily by most employees, are not business-critical if access is briefly interrupted, and are standard HTTP/HTTPS that work perfectly through ZTNA reverse proxy.

Deploy ZTNA connectors in the same network segment as these applications. Configure IdP integration with SAML 2.0 or OIDC. Define your first posture policy — keep it simple for the pilot: require managed device (enrolled in your MDM), OS patched within 90 days, and MFA completed. Onboard a pilot group of 50-100 users from mixed departments. These users access the pilot applications through ZTNA while everyone else continues using VPN. Run the pilot for 2 full weeks, collecting metrics on connection time, error rates, and user feedback.

The goal of Wave 1 is not to replace VPN. It is to prove that ZTNA works in your environment, that the user experience is measurably better, and that you can articulate the security improvement to leadership. When a pilot user opens the intranet and it loads in 400ms instead of the 8-second VPN connect-then-load experience, you have your proof point.

Wave 2: Business applications (Weeks 5-8)

Expand to 10-15 business applications: ERP web interfaces, CRM, source code repositories (GitHub, GitLab), CI/CD dashboards, database management tools (pgAdmin, phpMyAdmin), and project management platforms. These applications have narrower user populations and higher business criticality, so this wave tests your change management process as much as the technology.

Introduce tiered posture policies in this wave. Define three tiers: Basic (managed device, OS patched within 90 days, MFA) for general business apps. Elevated (add: EDR active, disk encryption enabled, OS patched within 30 days) for source code and CI/CD. Admin (add: MFA within the last hour, privileged access workstation) for database and infrastructure tools. Documenting these tiers now prevents policy sprawl later. Every new application added in future waves should map to one of these three tiers.

Expand the user base department by department during this wave. IT and engineering first (they understand the technology and can self-troubleshoot), then finance and HR (they handle sensitive data and benefit most from DLP integration), then remaining departments. Continue running VPN in parallel — users access ZTNA-enabled apps through ZTNA and everything else through VPN.

Wave 3: Legacy and thick-client applications (Weeks 9-12)

This is the hard wave. Legacy thick-client applications — proprietary ERP clients, CAD tools accessing license servers, mainframe terminal emulators, and applications with hardcoded IP-based authentication — may not work through ZTNA reverse proxy. You have three options for each application:

1. ZTNA with TCP/UDP tunneling. Most modern ZTNA platforms (Zscaler Private Access, Palo Alto Prisma Access, Netskope Private Access) support non-HTTP protocols through agent-based TCP/UDP tunneling. The ZTNA agent on the endpoint creates a local listener that forwards traffic through the ZTNA tunnel to the target application. This works for 70-80% of thick-client applications.
2. Application modernization. If the application has a web interface option (many ERP systems do), migrate users to the web version and retire the thick client. This is the cleanest long-term solution but requires application team cooperation and user retraining.
3. Restricted VPN exception. For the 5-10% of applications that genuinely cannot work through ZTNA (broadcast/multicast dependencies, certificate-pinned connections, or protocols the ZTNA vendor does not support), maintain a restricted VPN with narrowly scoped ACLs. The VPN should only grant access to the specific application IPs/ports required, not the full network segment.

Track every application that requires a VPN exception and set a modernization deadline for each. The goal is fewer than 5 applications on VPN exceptions by the end of this wave. If more than 10% of your application portfolio cannot migrate to ZTNA, investigate whether you chose the right ZTNA vendor — protocol support varies significantly between vendors.

Wave 4: VPN decommission (Weeks 13-16)

Restrict VPN access to only the exception applications identified in Wave 3. Remove all other applications from VPN split-tunnel ACLs so users cannot bypass ZTNA. Monitor VPN connection logs weekly — plot a graph of VPN sessions per day and ZTNA sessions per day. When VPN sessions drop below 5% of total remote access sessions, you are ready to set a decommission date.

Announce the VPN decommission date 30 days in advance. Send weekly reminders. On decommission day, disable VPN access for all users except the exception list. Keep the VPN infrastructure powered on for 30 days after decommission as a break-glass fallback — if a critical application was missed during inventory, you can temporarily re-enable access while migrating it to ZTNA. After the 30-day grace period, decommission the VPN concentrator hardware and reclaim the public IP addresses.

Metrics that matter

What goes wrong

Sources & further reading

• NIST SP 800-207, "Zero Trust Architecture" — nist.gov/publications/zero-trust-architecture
• CISA, "Zero Trust Maturity Model" — cisa.gov/zero-trust-maturity-model
• Gartner, "Market Guide for Zero Trust Network AccessZero Trust Network Access" — gartner.com/reviews/market/zero-trust-network-access
• Zscaler, "ZPA Deployment Best Practices" — zscaler.com/products/zscaler-private-access

Related on sase.cloud

One email per publish. Unsubscribe anytime.