How to replace VPN with Symantec ZTNA: a 90-day deployment plan

Most enterprises today still run legacy VPN - Cisco AnyConnect, Palo Alto GlobalProtect, Fortinet FortiClient, Pulse Secure. The infrastructure works, the users are trained, the help desk knows it. But it has well-documented problems: flat network access (a compromised VPN credential is a network-wide problem), poor user experience on mobile and remote work scenarios, scaling challenges during incidents, and incompatibility with the Zero Trust principles regulators increasingly want to see.

Symantec ZTNA - historically named Secure Access Cloud - is the natural replacement in a Symantec-aligned environment. It gives users application-level access instead of network-level access, integrates with your existing IdP, and runs as a managed cloud service with no inbound firewall ports. The catch: implementing ZTNA is mostly application inventory and identity discipline, not technology. The 90-day plan in this article focuses on that. For the product overview, see our Symantec ZTNA implementation page.

Days 1-15: Discovery

You cannot retire VPN if you don't know what users do through it. Most organizations don't have an accurate list of internal applications. Discovery is the bottleneck for every ZTNA project.

Sources to mine for application inventory:

• VPN session logs - destination IPs and ports show what users actually reach. Aggregate by destination, sort by volume.
• DNS query logs - internal DNS shows what hostnames users resolve. Often surfaces apps that don't appear in firewall data.
• Firewall east-west logs - what apps talk to each other internally. Useful for dependency mapping.
• Asset / CMDB - official inventory, usually incomplete but a starting point.
• Stakeholder interviews - security, IT, application owners. Tedious but essential.

Output: a list of 50-200 internal applications with owner, user population, criticality, and protocol type. Most organizations are surprised by the count. We have done discovery for a 5,000-user enterprise and found 180 distinct internal apps, half of which security had never tracked.

Days 10-20: Identity readiness check

ZTNA requires a functioning IdP. Run an identity audit in parallel with application discovery:

• Is AD / Entra ID sync clean? Are stale accounts disabled? Are group memberships accurate?
• Is MFA universal? If not, which user populations are gaps?
• Are contractors and third parties in the same IdP, or are they managed separately?
• Are application-specific groups in place, or does everyone have access to everything?
• How are device posture signals available (Intune compliance, Jamf, CrowdStrike, etc.)?

If you find significant identity gaps - broken Entra sync, inconsistent MFA, no clean group model - fix them before the ZTNA pilot. Trying to launch ZTNA on broken identity creates support nightmares.

Days 15-30: Pilot app selection

Pick 5-10 applications for the first wave. Selection criteria:

• Web-based applications first. They are the simplest to wrap in ZTNA via clientless mode.
• Internal SaaS replacements (internal Wiki, internal status page, internal directory).
• Applications with clear ownership and willing application teams.
• Applications used by a known, smallish user population (IT, security, engineering).
• Avoid mission-critical or production-customer-facing apps. Save those for waves 4-6.

For each pilot app, document: app name, protocol (HTTP/S, RDP, SSH, database), authentication method, user / group access policy, posture requirements, planned launch date.

Days 25-45: ZTNA tenant configuration and pilot deployment

Once Broadcom provisions the ZTNA tenant, the technical configuration is fast - typically 2-3 days for the initial tenant setup, IdP integration, and connector deployment. The connector is a small VM or container deployed inside your network (or in cloud) that provides outbound-only connectivity to the ZTNA cloud and inbound proxy to your internal apps.

Deploy:

1. One ZTNA connector in your primary data center / cloud region. (Two for redundancy.)
2. IdP integration (Okta SAML, Entra SAML, Ping). Test SSO and group claims.
3. First pilot app: configure the app entry, assign user group, set posture requirements.
4. Test access yourself, then with 3-5 friendly pilot users.

Common issue: SAML attribute mapping. ZTNA expects specific user attributes; your IdP may emit them differently. Resolve during pilot.

Days 40-60: Pilot user wave 1

Move the first user wave (typically IT and security teams - internal, technical, forgiving of issues) onto ZTNA for the pilot apps. Leave VPN in place; users have both methods available. Watch:

• Connection time - should be 2-5 seconds for web apps via ZTNA. Compare with VPN.
• Latency - depends on user location to ZTNA cloud node. Test from each major region.
• Auth flow - SSO should be seamless. Step-up auth should fire on risky access.
• Help desk tickets - which issues are real, which are user adjustment.

Goal: 2 weeks of stable pilot, then expand to wave 2.

Days 55-75: Add RDP/SSH and second app wave

Now that web apps work, add the harder protocols. Symantec ZTNA supports clientless RDP and SSH (browser-based) and agent-mode native RDP/SSH (through ZTNA tunnel). The clientless mode is easier to deploy but limits feature set; admins typically want native clients.

Deploy:

1. 5-10 internal RDP / SSH targets (jump hosts, admin servers).
2. Define recording / session logging policy. (ZTNA can record admin sessions for audit.)
3. Test from each user platform: Windows, macOS, Linux.

Add the second app wave (15-30 more apps) over 2 weeks. Each app gets the same scope: identity / group, posture, connection method, owner sign-off.

Days 70-90: First user population fully off VPN

By day 75, IT and security have been on ZTNA for ~30 days. They are the proof-of-concept population. Now migrate the first business user wave - typically a department of 100-300 users with manageable app needs (sales operations, finance back-office, HR generalists).

The migration sequence per user:

1. Install ZTNA agent via SCCM / Intune / Jamf.
2. Provide brief training: "Open this app via ZTNA, not VPN."
3. Remove user from VPN group (but keep VPN running for any missed apps).
4. Monitor help desk for 7 days.
5. Decide whether to bring the next 100 users.

At day 90 you should have:

• ~30-50 apps live on ZTNA.
• ~10-20% of users fully on ZTNA, no longer using VPN.
• Operational runbooks for adding apps and onboarding users.
• Clear gap list - apps that can't be moved to ZTNA, edge cases, residual VPN requirements.

What comes after 90 days

Months 4-9 are the long tail. More apps, more users, gradual VPN retirement. We typically see:

• Month 4-6: All business apps migrated, second half of user population on ZTNA.
• Month 6-9: Edge cases addressed - legacy protocols, contractor access, partner integrations.
• Month 9-12: VPN reduced to small footprint for residual cases. Decommission begins.

Some enterprises end up keeping a small VPN footprint indefinitely for niche legacy protocols. That's fine - the goal is to reduce VPN scope by 90-95%, not necessarily to zero.

Common pitfalls we have walked into

Application owners say "no." Some app teams resist ZTNA because they think VPN is "working fine." Build the security case (compromised VPN credentials are network-wide problems) and the user experience case (ZTNA is faster for users).

Posture signal gaps. ZTNA can enforce device posture (encryption on, AV updated, OS version current). But your posture signal source has to actually report this. If your endpoint management doesn't expose posture cleanly, the ZTNA policy is weaker than it could be. Fix endpoint posture exposure early.

Underestimating contractor / third-party complexity. Contractors have different identity sources, different device states, different access needs. Plan a separate ZTNA app entry pattern for them.

Forgetting the "VPN is also a NAT" problem. Some internal apps require requests to come from "inside" the network. ZTNA presents traffic differently. Validate apps from a ZTNA-routed source during pilot - surprises here are time-consuming to fix.

What this looks like with CyberKIS

CyberKIS runs the 90-day plan as a defined scope: discovery, identity readiness, pilot deployment, first user wave migration. Output: a fully operational ZTNA tenant with 30-50 apps live, first user populations migrated, and a documented roadmap for the remaining 6-9 months of VPN retirement. We bring the playbook; you bring the access and the application teams.

Want to scope this for your environment? Talk to a CyberKIS engineer or read the Symantec ZTNA deep-dive. Related: SEPM to SES Complete, ProxySG to Cloud SWG.