Migrating Corporate VPN to Zero Trust: A Practical Checklist for Enterprise IT Teams

The signals that corporate VPN has stopped working rarely show up as a single failure. They show up as a slow accumulation: a help desk that spends a growing share of its time on VPN client issues, an access-review process that can no longer explain why a given user’s account can reach dozens of internal systems they’ve never used, and a workforce that’s now more remote and more cloud-dependent than the VPN’s perimeter model was ever designed for. This checklist is written for the IT teams standing in that accumulation, not for a green-field zero trust build.

None of this requires ripping VPN out overnight, and teams that try tend to produce the exact kind of outage that sets the whole initiative back a budget cycle. The migration below is written as a sequence of checklist items precisely because sequencing, not technology selection, is what determines whether it succeeds.

The Signals VPN Is No Longer Enough

A traditional VPN’s failure mode is architectural, not a bug to patch. It authenticates once at the network perimeter, and once a session is established, the user typically has broad reachability across whatever the VPN segment exposes — access is granted to a network, not to a specific resource. Three symptoms tend to show up together when that model is under strain: over-broad access that an access review can’t fully justify, because VPN grants were made incrementally over years without a corresponding revocation discipline; remote-first workforces where most traffic is now VPN traffic by default rather than the exception the architecture assumed; and a widening compliance gap, where auditors increasingly expect per-resource access evidence that a perimeter-based VPN log simply can’t produce.

NIST SP 800-207 names the underlying problem directly: zero trust architecture removes implicit trust granted by network location, affiliation, or ownership, and instead requires that access to individual resources be evaluated per-session against a dynamic policy — one that accounts for the observable state of the requesting identity, device, and application, not a one-time perimeter credential¹. A VPN, by design, grants exactly the kind of standing, location-based trust that framework is built to eliminate.

What ZTNA Changes, and What It Doesn’t

Zero trust network access replaces “connect to the network” with “request access to a specific resource,” evaluated each time against policy. Per NIST SP 800-207’s tenets, that policy decision draws on identity, device posture, and other contextual signals, and enforcement happens dynamically and continuously rather than once at connection time¹. Concretely, that means a user’s access to one internal application doesn’t imply access to any other, and a change in device posture — a failed patch check, a jailbroken device — can revoke access mid-session rather than waiting for the next login.

What doesn’t change: identity and device management still have to exist and be accurate. ZTNA is an enforcement layer on top of identity and device signals your organization already needs to maintain — it doesn’t generate that data itself. CISA’s Zero Trust Maturity Model is useful here because it frames the migration as movement across five pillars — identity, devices, networks, applications and workloads, and data — each progressing through four maturity stages from Traditional to Optimal, rather than a single binary switch². A realistic migration plan should expect uneven progress across those pillars: identity and device management maturity often has to advance before network access policy can meaningfully tighten.

Migration Checklist

1. Inventory applications and access paths, not just VPN configs. Export current VPN access-group memberships and cross-reference them against an actual application inventory — most organizations find grants that predate the employee’s current role, or third-party access nobody remembers approving. You cannot write per-resource policy for a resource that isn’t cataloged.

2. Define the access policy model before evaluating any product. For each application, specify who should reach it and under what identity and device conditions — independent of which tool will enforce that policy. Skipping this and moving straight to a ZTNA product evaluation tends to reproduce the VPN’s broad-access pattern inside a new interface, because the underlying policy questions were never actually answered.

3. Classify applications by migration order, not by convenience. Start with applications that have a clean, well-understood access pattern and a contained blast radius if something goes wrong during cutover — not necessarily the highest-value systems. Save applications with legacy authentication or undocumented dependencies for later waves, once the coexistence process has been proven on lower-risk traffic.

4. Design the coexistence period explicitly, including a target decommission date per application segment, not an open-ended “VPN stays until further notice.” Without an explicit end state, VPN and ZTNA tend to run in parallel indefinitely, doubling the maintenance and audit burden rather than reducing it.

5. Build logging and access review around per-resource events, not perimeter connection logs. A VPN log answers “did this user connect to the network”; the audit evidence a zero trust model and most compliance frameworks actually need is “did this user access this specific resource, under what device and identity conditions.” If your logging pipeline can’t answer the second question yet, that’s a prerequisite to fix before cutover, not an afterthought.

6. Validate each segment before decommissioning its VPN path. Confirm ZTNA-enforced access matches the intended policy — including for edge cases like service accounts, contractors, and break-glass access — before turning off the VPN route for that application group. Decommissioning ahead of validation is how migrations create outages that erode organizational trust in the whole project.

Running the Coexistence Period Without Gaps

The riskiest window in this migration isn’t the start or the end — it’s the middle, when some applications are ZTNA-enforced and others are still VPN-reachable, and users are operating under two different access models depending on what they’re trying to reach. Two practices reduce the risk in that window specifically: keep a single source of truth for identity and device posture that both VPN and ZTNA enforcement points read from, rather than letting the two systems maintain separate device-trust records that can drift out of sync; and communicate migration waves to end users by application, not just to IT, since a support ticket volume spike from confused users switching between two access models is one of the more common reasons a coexistence period gets extended past its planned end date.

Common Failure Patterns Worth Naming in Advance

A handful of failure patterns show up repeatedly enough across VPN-to-ZTNA migrations that naming them before starting is cheaper than discovering them mid-project. The first is treating the migration as a single product swap — replacing the VPN client with a ZTNA agent while leaving the underlying access-policy model untouched. Without step 2 of the checklist actually done first, this just moves the VPN’s broad-access pattern into a new interface with a different login screen, and the organization gets none of the per-resource audit benefit it set out to capture. The second is underestimating legacy application dependencies: applications with hardcoded IP allowlists, older authentication protocols that don’t support modern identity assertions, or undocumented service-to-service traffic that was quietly riding along inside the VPN tunnel tend to surface only when that application’s migration wave actually starts, which is why classifying by contained blast radius in step 3 matters more than classifying by business priority. The third is an access-review process that doesn’t get redesigned alongside the technology — a per-resource access model needs a per-resource review cadence, and continuing to run an annual, VPN-group-based access review against a ZTNA-enforced environment leaves the review answering a question the new architecture no longer asks.

What the Migration Changes for Contractors and Third Parties

Contractor and third-party access deserves separate treatment in this checklist, because it’s often the segment where VPN’s broad-access pattern is most pronounced and most stale — a contractor engagement that ended eight months ago but whose VPN credential was never revoked is a common finding in access reviews, precisely because VPN access grants and offboarding processes are rarely wired together tightly. A zero trust model’s per-resource, per-session policy evaluation is a genuine improvement here: third-party access can be scoped to the exact application a contractor needs, time-boxed to the engagement, and revoked centrally without having to track down which VPN group membership needs to be pulled. Building that scoped access model for third parties is worth sequencing early in the migration rather than treating it as a cleanup task for later, since it’s also one of the clearest, most demonstrable wins to show stakeholders that the migration is delivering something a VPN structurally couldn’t.

Setting a Realistic Timeline

The checklist above is sequential, but it isn’t fast, and setting an unrealistic timeline at the outset is its own failure mode — a migration budgeted for a single quarter tends to produce exactly the “product swap without policy redesign” pattern described above, because there isn’t enough runway to do the inventory and policy work properly. For a mid-sized enterprise with a few hundred internal applications, a full inventory and access-policy definition (checklist items 1–2) realistically takes six to ten weeks before the first application migrates. The migration waves themselves (items 3–6) then run in parallel with normal operations over several quarters, gated by validation rather than a calendar date, with the coexistence period narrowing progressively as each wave’s VPN path is decommissioned. Treating the entire program as a single project with one end date, rather than a rolling set of application-level migrations each with its own validation gate, is a reliable way to either rush the risky ones or let the coexistence period run indefinitely — the two failure modes this checklist is built to avoid.

How This Fits a Broader Zero Trust Program

This checklist covers the network-access migration specifically. For the architectural and policy foundation this migration sits on top of, see the zero trust architecture hub, which covers identity, device posture, and policy design as a set — this checklist is the execution path once that architecture is defined, not a substitute for it. For the identity side of the same migration, particularly for organizations tightening authentication as part of the same initiative, the enterprise passkey adoption roadmap covers moving off password-based authentication with the same staged-rollout discipline. And for the cloud-specific access-control knowledge that underlies ZTNA policy design, the CCSP zero trust and cloud security guide covers the domain in more depth for teams building this out as part of a broader cloud security program.

One practical rule of thumb that holds across most of the migrations this checklist is drawn from: if a given application’s access-policy definition takes longer to write than the ZTNA configuration itself, that’s usually a sign the application’s access pattern was never well understood under VPN either, and the migration is doing useful work by forcing that clarity — not a sign the checklist is over-engineered for that application.

Sources

• NIST SP 800-207 — Zero Trust Architecture
• CISA — Zero Trust Maturity Model