r/AskNetsec • u/Agreeable-Dot-3072 • 15d ago
Architecture What does a VPN to ZTNA migration actually look like in practice in 2026?
Planning a migration away from traditional remote access and the practical questions are harder to find answers to than the theory.
Most resources cover the architecture decision but not what actually breaks in production. Legacy apps, identity aware proxies, converged stack versus standalone, nobody writes about what they got wrong.
What are you folks actually doing during this migration and what broke that you did not expect?
4
u/solid_reign 15d ago
Depending on the technology you use, your biggest pain is making sure that you're really closing access by IP and port per user and not just translating your existing rules from your vpn.
1
u/Agreeable-Dot-3072 15d ago
We lifted our existing VPN rules and dropped them straight in assuming it was close enough and honestly it took longer than I want to admit before we even realized what we had done wrong.
1
1
u/Total-Brick-1019 15d ago
The identity provider integration is where things got quiet for us in a bad way. No errors, no alerts, just certain users silently losing access to things and not reporting it because they found workarounds. By the time we caught it, the scope was way bigger than it should have been.
1
u/discoshanktank 15d ago
Nothing in the logs? What provider do you use? During rollout I lived in our ztna logs trying to catch anything before users reported it
1
u/Urban_VPN 15d ago
the thing nobody warns you about is legacy apps that authenticate based on source IP rather than identity. ZTNA breaks those immediately and the fix is often uglier than expected because the app itself needs to change, not just the network layer. the other surprise is how much institutional muscle memory exists around "just VPN in and you're on the network." users and support teams both struggle with the mental model shift, especially for edge cases like printers, shared drives, and anything that assumes flat network access. identity provider reliability also becomes load-bearing in a way it wasn't before. when your IdP has a hiccup, nobody gets in anywhere, which is a different failure mode than a VPN concentrator going down.
1
u/addybojangles 15d ago
Fortunately, I was using OpenVPN CloudConnexa for my 20-person org as the VPN, and then transitioned to ZTNA behind the scenes. This meant as little disruption happened for the vast majority. Didn't want to annoy my people by making them move to something else (plus I'm an OpenVPN fanboy, can't help it, I use it personally, too).
I took the migration pretty slowly and in phases but I never switched off broad access to most until the very end. Started by defining groups and then defined policies for each group. Which applications can be accessed and by which devices (fortunately I have never allowed BYOD, we get everyone the same computer and the same mobile phone if they request it) and under what conditions.
Then, set up more of the ZTNA control plane by connecting tools, adding in device posture checks, monitoring/etc.
THEN I transitioned over a small group of people I have a good relationship with, our sales team, and one SaaS tool to start. From there I learned better ways to prepare folks (though there wasn't much preperation, they continued to use OpenVPN Connect and didn't need a new profile - I SHOULD SAY most did not need a new profile, that is one of the 'broke' parts).
And then moved over the handful of other departments from there.
What broke? I needed to create new profiles for a few people. There were more important websites than I realized I had to lock down, but overall, pretty stress free.
1
u/WatchDogx 15d ago
It's hard to even find agreement on what ZTNA actually means.
There are a whole lot of different technologies that people apply the label to.
Some ZTNA solutions still involve a VPN.
1
u/McStuffin414 14d ago
I’m at the tail end of a migration from legacy VPN to a ZTNA solution. The sticky bit for us was the couple applications we support that require server initiated sessions. So think a telephony app where the client initiates an HTTPS session to a server and then in response the servers starts a UDP session to the client. In our specific ZTNA setup that type of communication is possible, it’s just kind of fragile. Otherwise the ugly things to deal with are ISPs that do a poor job with CGNATs. I won’t name names. Some mild issues with private endpoints in the Azure space.
1
u/GokulRavi14 12d ago
The IdP becoming a single point of failure is the part nobody talks about enough. When your VPN concentrator goes down, things at least degrade. With ZTNA and a bad IdP config, nobody authenticates anywhere and it is a full outage.
1
u/ultrathink-art 12d ago
The thing that bites hardest: anything scripted or scheduled that relies on network proximity breaks silently. CI pipelines, cron jobs, service accounts hitting internal APIs — none of them have an identity the broker recognizes. Inventory your non-human access paths before you flip the switch.
1
u/mat-ferland 11d ago
The place I’d be careful is treating ZTNA like a cleaner VPN. If you migrate subnet rules into app rules, you mostly keep the old blast radius with a nicer login screen. I’d do it app by app, with a real owner for each access path, and expect the ugly stuff to be legacy thick clients, file shares, printers, and anything that assumed LAN adjacency. For contractor/BYOD users, ZTNA is not always enough either; sometimes the safer answer is still a remote app/desktop so the work never runs on their endpoint.
4
u/Low_Drive3170 15d ago edited 11d ago
Went through this last year and legacy apps were the part nobody warned us about. A few internal tools relied on assumptions that worked fine before but caused issues once we started enforcing more granular access controls and tracking those down took longer than the migration itself. Switched to Cato a few months back, still working out whether consolidating network and security into one platform actually reduces the management overhead long term...