From Subnets to Least Privilege — A Practical Migration to Application-Level Access

Because that's the real reason Zero Trust projects stall. Almost nobody disagrees with the principles. What they lack is a path that doesn't require ripping out working connectivity, re-platforming legacy apps, or flipping a switch and hoping. The most useful property of a service that can operate in both modes is that the migration can be gradual — you move resource by resource, on your own timeline, with both models running side by side.

The short answer: A VPN to ZTNA migration doesn't need a big-bang cutover. Move to a platform that runs both models at once, keep your existing subnet access, turn on visibility, convert high-value resources to per-application access one at a time, then switch to deny-by-default once the data shows it's safe. With CloudConnexa, the OpenVPN transport stays constant the whole way; only the access architecture changes.

Why "big bang" migrations fail

The instinct, when guidance says "replace the VPN," is to imagine a cutover: old VPN off, new ZTNA on, one weekend, fingers crossed. In practice, this rarely survives contact with a real environment.

Real environments have a long tail. There are applications that expect flat network reachability. There are IP-based services and appliances that were never designed to sit behind a domain name. There are dependencies nobody fully documented. There are teams who will not accept "we'll find out if it works on Saturday night" as a rollout plan. A cutover forces you to solve all of this at once, which is why so many Zero Trust initiatives get to the pilot and then quietly stop.

A migration that lets the old and new models coexist removes the forcing function. You don't have to be done; you only have to make progress.

The starting point: full network, ACL-governed

Most organizations begin in the world the earlier posts described as full-network mode. Resources are reachable as IP Services — subnets and routes. Access is governed by network constructs: who can route where, mediated by ACLs. Users authenticate and gain reachability into ranges of internal IP space.

This works, and CloudConnexa supports it directly, so step one is usually not a re-architecture at all. It's a like-for-like replacement of legacy connectivity: bring sites and users onto the overlay using Network Connectors and IP Services, keep your existing network-level access model, and get the operational benefits — a cloud-delivered control plane, integrated security, centralized visibility — without changing how access is expressed yet. You've moved platforms, not paradigms. Nothing has broken, and you now have a foundation to tighten from.

The destination: per-application, default-deny

The end state is the one the guidance describes. Resources are modeled as Applications, reached through Application Domain-based Routing, with real IPs and routes cloaked behind intermediary addresses. The topology is set to Custom, so the posture is default-deny. Access Groups express least privilege directly: this identity, this application, nothing more. Device posture, location context, and Device Identity Verification and Enforcement (DIVE) add continuous, contextual verification on top.

The gap between start and destination looks large. The point of a dual-mode service is that you cross it in steps, not in one leap.

A staged VPN to ZTNA migration path that doesn't break things

Here is a migration shape that works in practice. The exact order depends on your environment, but the principle — incremental, reversible, evidence-driven — holds.

1. Land on the platform in full-network mode. Replace legacy VPN connectivity first, keeping your current IP Services and access model. Prove parity. This de-risks everything that follows because you're now operating on the target platform with no behavioral change.
2. Turn on visibility before you turn on enforcement. Use Access Visibility and the DNS logs to learn what's actually being accessed — which applications, by whom, how often. This is the step teams most often skip and most often regret. You cannot write least-privilege policy for traffic you can't see, and the logs surface internal applications you didn't know to account for.
3. Convert high-value, well-understood resources to Applications first. Pick the resources where the security upside is highest and the behavior is best understood — an admin console, a sensitive internal app, a system that should never have been broadly reachable. Model each as an Application, so it's reached by name with its IP cloaked, and write a scoped Access Group for it. Both models are running at once: the converted resources are now identity-aware-proxied while the rest of the estate stays on IP Services.
4. Introduce default-deny deliberately. Moving the WPC topology from Full Mesh to Custom is what puts your explicit Access Groups in charge. CloudConnexa keeps a Default Full Mesh Access Group in place as a safety net, so access doesn't vanish the moment you switch; once your scoped Access Groups are ready, you delete that default group and the posture becomes deny-by-default. Sequence this carefully and lean on the visibility from step 2, because this is the change that turns "allowed unless blocked" into "blocked unless allowed." Done with good data, it's an anticlimax; done blind, it's an outage.
5. Layer on continuous verification. Add device posture policies (OS, antivirus, disk encryption, client certificate), location context, and DIVE. These don't change what a user can reach; they raise the bar on who and what qualifies to reach it, satisfying the continuous-verification tenet of the Zero Trust models.
6. Work down the long tail — and accept that some of it stays. Convert the remaining tractable resources to Applications over time. For the genuinely IP-bound ones that can't be expressed as named applications, it's legitimate to leave them as tightly scoped IP Services. Pragmatic least privilege beats a stalled purist project.

The throughline: at every step you've improved your posture, nothing required a flag day, and you could pause at any stage and still be better off than when you started.

The six steps at a glance

On the "OpenVPN protocol means it isn't real ZTNA" objection

In a migration context, this objection takes a slightly different and more practical form: "If we're still running OpenVPN tunnels the whole way through, have we actually migrated to ZTNA, or just rebranded our VPN?"

The answer is to watch what changes during the migration — and what doesn't. What doesn't change is the transport: OpenVPN carries the encrypted session from start to finish, in full-network mode and in pure-proxy mode alike. What does change is everything that defines the security model: resources go from exposed subnets to cloaked, named applications; access goes from network-level reachability to per-application policy; the posture goes from allow-by-default to deny-by-default; verification goes from one-time login to continuous.

That's the proof, made visible by the migration itself. If ZTNA were a property of the protocol, nothing could change while the protocol stayed constant — yet your security posture transforms completely without the transport moving at all. The migration is, in effect, a live demonstration that architecture and transport are independent. You are not rebranding a VPN; you are re-architecting access over a stable, proven encrypted transport. Keeping the data plane constant while the control plane evolves is a feature — it's what makes the migration low-risk in the first place.

So when an auditor or a board member asks "is this really ZTNA, given it uses OpenVPN?", the defensible, evidence-based answer is: judge the deployment by what a user can reach and how that was decided. For converted resources under default-deny with cloaked, per-application access and continuous verification, the answer is yes — and the protocol underneath is no more relevant to that verdict than TCP is to whether your bank's website does proper authorization.

The takeaway

The reason a dual-mode service matters isn't theoretical elegance. It's that the gap between a legacy, subnet-and-ACL VPN and a least-privilege, identity-aware architecture is exactly the gap most organizations need to cross — and crossing it incrementally, with both models coexisting, is the difference between a Zero Trust program that ships and one that stalls in pilot.

CloudConnexa lets you start by replacing what you have, gain visibility, convert resources to cloaked applications at your own pace, flip to default-deny when the data says it's safe, and layer on continuous verification — all over one consistent, encrypted transport. The OpenVPN protocol is constant throughout; the architecture is what moves. And the architecture is what Zero Trust was always about.

Get started with CloudConnexa for free and take step one without changing a single access rule.

Frequently asked questions

Can you run a VPN and ZTNA side by side during a migration?

Yes, and that's the point of a staged approach. CloudConnexa can serve resources as IP Services (subnets and routes, like a traditional VPN) and as Applications (named, IP-cloaked, per-app access) at the same time, so converted resources get Zero Trust treatment while everything else keeps working. Part 2 of this series explains how the two modes coexist.

How long does a VPN to ZTNA migration take?

There's no fixed timeline, because a staged migration doesn't need a finish date to deliver value. Each step improves your posture on its own, and you can pause at any stage. That matches how CISA's Zero Trust Maturity Model frames progress: moving from Traditional through Initial and Advanced toward Optimal, rather than one cutover.

What does "deny by default" mean in ZTNA?

Deny by default (or default-deny) means nothing is reachable unless a policy explicitly allows it. In CloudConnexa, setting the WPC topology to Custom puts Access Groups in charge: each group maps specific users, hosts, or networks to specific applications or services, and anything not covered is blocked.

Why should you turn on visibility before enforcement?

Because you can't write least-privilege policy for traffic you can't see. Access Visibility shows what's accessed and by whom and helps you discover internal services you didn't know about. Skipping a monitoring phase is one of the most common reasons ZTNA projects fail.

What happens to legacy apps that only work by IP address?

Not everything converts cleanly to a named application, and that's fine. Genuinely IP-bound systems can stay as tightly scoped IP Services governed by narrow Access Groups under default-deny. Pragmatic least privilege is better than a migration that stalls waiting for every last system.

Is it really ZTNA if the traffic still runs over the OpenVPN protocol?

Yes, when it's configured that way. ZTNA is defined by the access architecture — what a user can reach and how that was decided — not by the transport. The migration itself shows this: your security model changes completely while the encrypted transport stays the same. Part 1 of this series covers the argument in depth.

Can I follow the same approach with a self-hosted VPN?

The principles carry over. If you run OpenVPN Access Server on your own infrastructure, domain-based routing gives you a similar path from subnet access to per-application access. See how self-hosted ZTNA domain routing works in Access Server.

Further reading

• What Is ZTNA? Why the Transport Protocol Isn't the Point (Part 1)
• One Service, Two Modes: How CloudConnexa Operates as Both an Identity-Aware Proxy and a Full Network VPN (Part 2)
• Why Zero Trust Network Access (ZTNA) Implementations Fail
• Why ZTNA Isn't a Switch You Flip — And How the Life Cycle Approach Makes It Work
• Not a Flip of the Switch: How IT Managers Implement Zero Trust Models
• Self-hosted ZTNA with domain routing in Access Server

This concludes the three-part series "CloudConnexa and Zero Trust." Start from Part 1 for the framing, Part 2 for the architecture.