--- title: "VPN to ZTNA Migration: A Phased Path You Can Fund | OpenVPN Blog" description: "\"Rip out the VPN\" isn't a fundable project. A five-phase path from network-level access to application-level Zero Trust, on the Access Server you already run." image: https://blog.openvpn.net/hubfs/Copy%20of%20OV010_AccessServer_ZTNA_BlogHeader_4_V1.png --- - [Blog](https://blog.openvpn.net) - [Zero Trust](https://blog.openvpn.net/tag/zero-trust) - [self-hosted](https://blog.openvpn.net/tag/self-hosted) - [ztna](https://blog.openvpn.net/tag/ztna) # From VPN Access to Zero Trust on the Platform You Already Run Oct 9, 2026 • 15 min read ![ztna bubble workspace](https://blog.openvpn.net/hubfs/Copy%20of%20OV010_AccessServer_ZTNA_BlogHeader_4_V1.png) Share - - - - VPN to ZTNA Migration: A Phased Path You Can Fund | OpenVPN Blog 18:02 By Heather Walters ## Getting your whole team on ZTNA without causing chaos. The standard advice is to replace your VPN with ZTNA. As a description of where the industry is going, that's correct. As a project plan, it's close to useless — because "replace the remote access system every employee depends on, all at once, with a product we haven't operated before" is not a proposal that survives a change advisory board, and it isn't how any of the successful transitions we've seen actually went.  It also misdescribes the destination. The end state for almost every organization isn't *all* Zero Trust. It's a deliberate mix: **application-level access for the great majority of users, and network-level access retained on purpose for the things that genuinely need it** — administrators, protocols that won't proxy, equipment that can't run an agent. Framing the project as "replace the VPN" makes that remainder look like failure, when it's actually the correct answer. This post is written for a specific reader: **someone already running Access Server as a** [**secure remote access**](https://openvpn.net/use-cases/secure-remote-access/) **VPN**, who wants to operate it as a Zero Trust access solution instead — and who'd rather do that on infrastructure their team already runs competently than learn a new platform under deadline. The shape applies to most mature VPN deployments, so it's useful more broadly. But the concrete steps assume Access Server, and it keeps both the control plane and the data plane on your infrastructure throughout — which is what a move to a SaaS platform gives away on day one, and it gives away both, not just the decisions. [![Subnet Calculator Blog Image CTA ](https://no-cache.hubspot.com/cta/default/43411546/d6dc0237-1a8c-4671-8c67-4261b3f56777.png)](https://cta-redirect.hubspot.com/cta/redirect/43411546/d6dc0237-1a8c-4671-8c67-4261b3f56777) ## **Why rip-and-replace stalls** Four reasons, and they're all organizational rather than technical. **Funding.** A migration with no deliverable until month nine is competing against projects that ship something in month two. It loses. **Risk concentration.** Cutting over remote access in a single window means one bad evening locks out the entire workforce. Sensible change control will not approve it, and shouldn't. **The awkward remainder.** Every network has things that don't fit the ZTNA model cleanly: an administrator who genuinely needs broad network access, a legacy protocol that won't proxy, a piece of equipment that can't run an agent, a vendor connection governed by a contract nobody wants to reopen. These are usually 5–10% of use cases and they consume most of the project's political capital. A phased approach lets them stay on the VPN indefinitely while everything else moves. **Skills.** Your team knows the VPN. Building Zero Trust on top of infrastructure they already operate competently is a much shorter learning curve than operating an unfamiliar platform. ## **The reframe** Zero Trust isn't a product you install. It's a set of properties: verify identity explicitly, verify the device, grant the minimum access needed, and re-evaluate continuously. Access Server operated the way most deployments start out has one of those properties and three gaps. It authenticates a user — often with a single credential and no second factor — then puts them on a network segment where they can reach everything the segment reaches, for as long as the session lasts, without further checks. None of that is a limitation of the software. Every capability the phases below use is already in the product; it's a question of how you've configured it. Which is the useful part: you aren't migrating platforms, you're changing how you operate the one you have — and you can close those gaps one at a time, in an order where each step is independently defensible. [![openvpn\_ztna-research-report\_email\_800x200](https://blog.openvpn.net/hs-fs/hubfs/openvpn_ztna-research-report_email_800x200.png?width=2500&height=625&name=openvpn_ztna-research-report_email_800x200.png)](https://go.openvpn.net/ztna-research-report-2026) ## **Phase 0: Find out what you actually have** Unglamorous and non-optional. Before changing anything: - **Who connects, and what do they actually reach?** Most organizations discover their VPN grants access to substantially more than anyone intended, because the rules were written when the network was smaller. - **What's on the far end?** An inventory of resources reachable over the VPN, and who legitimately needs each. - **Which cases won't fit?** Identify the awkward remainder now so it doesn't derail you in phase 3. - **What do your logs currently prove?** Usually "this user held a session from 09:12 to 17:40," which is not an access record. Knowing that gap exists sets up phase 4's value. Expect this to take longer than you planned and to surface at least one genuinely alarming discovery. That discovery is your funding argument for everything that follows. ## **Phase 1: Move authentication to your identity provider** **What changes:** the VPN stops holding its own user list and authenticates against your existing directory — [LDAP, Active Directory, RADIUS, or SAML](https://openvpn.net/access-server/features/authentication-systems/). **Why it's first:** it's low-risk, it's usually a configuration change rather than a project, and it establishes the thing every later phase depends on: a single authoritative answer to "who is this person?" It also immediately fixes a real problem — VPN accounts that outlive employment, because the VPN's user list was a separate system nobody remembered to update at offboarding. **What you get:** joiner-mover-leaver handled centrally. Disable the directory account and VPN access dies with it. **Zero Trust property gained:** verify identity explicitly, properly, from one source of truth. ## **Phase 2: Enforce MFA, by group** **What changes:** a second factor becomes mandatory. TOTP, or hardware tokens for privileged users. **Why not everyone at once:** because a global MFA mandate is a helpdesk event and a political fight. Enforce it per group — start with administrators and anyone reaching production, then expand. Each group is a small, reversible change with a clear risk rationale, which is much easier to get approved than a blanket policy. **Worth noting:** this is available on community-edition OpenVPN as well as Access Server, though on the community edition you'll be writing the authentication logic yourself. We[published the script](https://claude.ai/cowork/cse_01T35qKrAvFLZgU212KNunTE#) so the effort is visible before you commit to it. **Zero Trust property gained:** authentication strength proportional to what the credential can reach. ## **Phase 3: Replace flat access with scoped access** **What changes:** users stop landing on one shared subnet with a route to everything. Instead each group gets its own address range and firewall rules that permit only what that group needs. **Why it's the hard one:** this is where you turn phase 0's inventory into policy, and it's genuinely the most work in the whole migration. It's also where you'll get pushback, because someone will lose access they'd grown used to and hadn't strictly needed. **How to survive it:** run permissive rules in log-only mode first, so you can see what each group actually touches before you deny anything. Migrate one group at a time, starting with the smallest and best-understood. Keep the old flat access available as a documented fallback for a couple of weeks per group. **Zero Trust property gained:** least privilege at the network layer. This is the single biggest reduction in blast radius in the sequence — one compromised credential now reaches one group's resources rather than the whole network. Worth knowing that this phase is a staging post rather than the destination. Group-scoped subnets are a large improvement on flat access and they're still subnet rules — which means they still grant everything on the subnet. Phase 4 is where that gets fixed properly, and we cover why authorizing a name beats authorizing a network in more detail separately. ## **Phase 4: From network paths to application paths** **This is the phase that makes it Zero Trust rather than a well-configured VPN**, so it's worth more detail than the others. **What changes:** instead of routing a group to a subnet, you authorize a user to a named application. Access Server intercepts the DNS query, returns an address from its own internal pool rather than the real destination, and performs the translation itself — so the client never learns or routes toward the actual address. Rules are evaluated against hostnames instead of subnets. **Why that's the important distinction:** subnet-based access authorizes everything on the subnet, whether you meant to or not. Domain-based access leaves no residual network path to sibling systems. Someone authorized for one internal application cannot reach the machine next to it, because they were never given a route there — not because a firewall rule denies it. **Why it's phase 4 and not phase 1:** it depends on the identity work in phase 1 and the inventory in phase 0, and it's far easier to reason about once access is already group-scoped. **The migration gotcha:** if your existing configuration has IP subnets representing the network Access Server sits on, those need removing and replacing with domain names. Leave them in place and clients keep the old network path, and you've added application-layer rules on top of network-layer access rather than replacing it. This is the step most likely to leave you thinking you've done phase 4 when you haven't. **Also worth knowing:** this needs Access Server 3.1.0 or newer and depends on the DNS proxy (on by default from 3.1.0), with deny rules requiring 3.2.0. And domain routing can't resolve overlapping IP addresses, so destinations need to be on different subnets from the Access Server deployment itself — worth checking against your address plan before you commit to this as phase 4. **What you get:** access decisions at the application layer, and logs that finally say something useful — "this user reached this application at this time" rather than "this user was connected for six hours." There's a[technical walkthrough of the mechanism](https://claude.ai/cowork/cse_01T35qKrAvFLZgU212KNunTE#), including how to verify the NAT chain is doing what you think. **Zero Trust property gained:** resource-level rather than network-level authorization, with both planes still yours. This is the phase where "we're doing ZTNA" becomes defensible rather than aspirational. ## **Phase 5: Continuous verification** **What changes:** access stops being a one-time decision. Device posture becomes an input — is the disk encrypted, is the OS patched, is endpoint protection running — and sessions get re-evaluated rather than trusted for their duration. **Why last:** it's the most operationally demanding, it needs the previous phases in place to be meaningful, and it's the one most likely to generate false-positive lockouts if you rush it. Roll it out in monitor-only mode for weeks before enforcing. **Zero Trust property gained:** continuous verification, the property most deployments never actually reach. ## **What you've got at the end — and it isn't "all ZTNA"** Identity verified against one authoritative directory. MFA proportional to privilege. Access authorized per application rather than per network. Device posture as a condition. Per-application audit logs. **And, deliberately, some network-level access still in place.** The administrator who needs the whole subnet still has it. The legacy protocol that won't proxy still works. The embedded device that can't run an agent still connects. Those aren't leftovers from an unfinished migration — they're the cases where network-level access is the right tool, now scoped tightly to the people and systems that need it instead of being the default for everyone. That mix is the realistic end state, and one platform serving both models is the thing a rip-and-replace to a SaaS ZTNA product can't give you — you'd be running two access systems and paying for both. Every component of it — the data plane, the policy engine, the certificate authority, the policy store, and the logs — is on infrastructure you operate. No third party holds your access policy, your traffic doesn't cross anyone else's network, no vendor's outage prevents you issuing a new session, and your audit evidence is a record you hold rather than an export from someone else's tenant. ## **What you're not getting** We want to be clear about this, because the phased path isn't free. **You're operating it.** Patching, capacity, [certificate lifecycle](https://openvpn.net/access-server/features/certificate-management/), availability. A cloud-delivered platform absorbs all of that, and for a small team that's worth real money. **No global edge.** A vendor with points of presence in thirty countries serves a distributed workforce better than your server in one region. Multi-region deployment is the answer and it's more infrastructure. **You need a reachable address.** Straightforward in a data center or cloud VPC, genuinely awkward on some networks — and if you're behind carrier-grade NAT, a cloud-delivered option is the answer rather than a compromise. **The policy design work is the same either way.** Worth saying plainly, because it's where people misjudge the effort: phase 3 is the bulk of this project, and moving to a SaaS platform wouldn't shorten it. You'd still have to work out who should reach what. Deployment is fast on either path; deciding your access model is not. If none of those trade-offs bother you, cloud-delivered ZTNA is a good answer — we sell one — and we'd rather you chose it deliberately than ended up self-hosting because a vendor talked you into it. ## **Timeline, realistically** For a mid-sized organization: | **Phase** | **Effort** | **Elapsed** | | --- | --- | --- | | 0 — Inventory | 2–4 weeks | Do not skip | | 1 — Identity provider | Days | 1–2 weeks with change control | | 2 — MFA by group | Days per group | 4–8 weeks rolling | | 3 — Scoped access | The bulk of the project | 2–6 months | | 4 — Application-layer access | Moderate | 4–8 weeks | | 5 — Continuous verification | Moderate, plus tuning | 4–12 weeks |   The useful property of this table isn't the totals. It's that you can stop after any row and be better off than you were, which is what makes it fundable. ### Ready to see how OpenVPN can help protect your organization from attacks? Try the self-hosted Access Server solution or the managed CloudConnexa service for free, no credit card required. [See Which One is Right for You](https://openvpn.net/product-comparison/?_gl=1*1hi46u*_ga*NDgyODEwNDkyLjE3NzIxMjIzNDE.*_ga_E45Z33NTV7*czE3Nzc5ODY2ODIkbzExMiRnMSR0MTc3Nzk4ODMyMSRqNTUkbDAkaDE4NzIyNTczNDc.*_fplc*dVltNzJ6YmZ0bFZTdld4NjRtWVpVWXclMkJEV3AzZGhPUlRZaUppdWNxQkRjOER3MFN0VW84JTJCdEJGdnRDTmVYNlI5NlJBdTRLZ0VGOTNHMHc0U3l3bVFsR3NzQXk5RzJIQVdzNHE0QVJHcSUyQlVKUlRsNTM0S1RWZERyZ0V4NDNnJTNEJTNE*_gcl_au*MTM5NjEwNTIxNy4xNzcyMTIyMzQx*_ga_SPGM8Y8Y79*czE3Nzc5ODY2ODEkbzExMyRnMSR0MTc3Nzk4ODMyMyRqNTMkbDAkaDA.) ## Frequently asked questions ### **How do you migrate from a VPN to ZTNA?** Incrementally, and ideally on the VPN infrastructure you already run. A workable sequence: inventory who reaches what today; move authentication to your identity provider; enforce MFA group by group; replace flat network access with group-scoped access and firewall rules; move from network-level routing to application-level authorization; then add device posture and continuous re-evaluation. Each step delivers value independently, which matters more than it sounds — it's what makes the project survivable in budget and change-control terms. ### **Can ZTNA fully replace a VPN for a hybrid workforce?** For most users, yes. For all of them, usually not — and that's the detail most migration plans underestimate. Administrators needing broad network access, protocols that don't proxy cleanly, unmanaged or embedded devices that can't run an agent, and contractually fixed third-party connections tend to remain better served by VPN access. Most mature deployments run both, with ZTNA covering the great majority of users and VPN access retained deliberately for a documented remainder. ### **Can you use ZTNA and a VPN at the same time?** Yes, and it's the normal state during migration rather than a compromise. Running both lets you move user groups across as their access policy gets defined, keeps a fallback while each group settles, and leaves a path for the cases ZTNA handles awkwardly. If both are built on the same platform you also avoid operating two separate access systems, which is the hidden cost of a parallel-stack migration. ### **Is Zero Trust more secure than a VPN?** The model is, in the specific sense that matters most: it reduces blast radius. A compromised VPN credential typically yields access to a network segment; a compromised ZTNA credential yields access to the resources that identity was authorized for. But a well-configured VPN with MFA, certificate authentication, and tight per-group firewall rules is considerably more secure than a poorly configured ZTNA deployment. The architecture raises the ceiling; it doesn't guarantee the outcome. ### **What's the most secure method of remote access?** There's no single answer, but the properties that matter are consistent: strong authentication with a phishing-resistant second factor, credentials tied to a device rather than only to a person, access scoped to individual resources rather than networks, device posture as a condition of access, continuous re-evaluation, and per-resource audit logging. Whether that's delivered by a VPN platform or a ZTNA platform matters less than whether those properties are actually present. ### **How long does a VPN-to-ZTNA migration take?** For a mid-sized organization, six to eighteen months to complete all phases — but the first meaningful security improvement can land within a fortnight. Most of the time goes into replacing flat network access with scoped access, because that's policy design work that depends on understanding what people actually reach today. Organizations that try to compress this phase typically end up either granting too much or blocking legitimate work. ### **Do you have to give up control of your infrastructure to adopt ZTNA?** No, though most of the market is structured that way. Nothing in the Zero Trust architecture requires the policy engine *or the data path* to run in a vendor's cloud — that's a delivery-model choice, not an architectural necessity. Self-hosted ZTNA means both planes stay inside your trust domain: the data plane and the control plane, along with the certificate authority, the policy store, and the logs. The trade is that you operate the infrastructure and you don't get a vendor's global network. [Heather Walters](https://blog.openvpn.net/author/heather-walters) Heather is a writer for OpenVPN. ## Related posts from OpenVPN ### Subscribe for Blog Updates ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Heather Walters", "url" : "https://blog.openvpn.net/author/heather-walters" }, "dateModified" : "2026-10-09T16:15:00.091Z", "datePublished" : "2026-10-09T16:15:00.000Z", "headline" : "VPN to ZTNA Migration: A Phased Path You Can Fund | OpenVPN Blog", "image" : [ "https://blog.openvpn.net/hubfs/Copy%20of%20OV010_AccessServer_ZTNA_BlogHeader_4_V1.png" ], "mainEntityOfPage" : { "@id" : "https://blog.openvpn.net/vpn-to-ztna-migration-phased-self-hosted", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://blog.openvpn.net/hubfs/Dark=True%20Medium.png" }, "name" : "OpenVPN" } } ```