One gives you the network. The other gives you an application.
December 9, 2025
A VPN puts a remote user on the network. Once connected, they can generally reach whatever that network segment can reach, which is usually far more than they need.
Zero trust network access gives a user a connection to one specific application, after checking who and what they are, and gives them nothing else.
The VPN was designed for a world where a small number of employees occasionally worked from elsewhere, and everything they needed was inside one building.
Now most employees are remote at least some of the time, and the applications they need are spread across data centers and several cloud providers. Backhauling all of that traffic through a concentrator is slow, expensive, and does not match where anything actually lives.
The security problem is broader access than necessary. A compromised laptop on a VPN is a compromised device with a network route to everything on that segment, which is exactly the lateral movement path attackers want.
There is a second, harder problem. Remote access appliances are internet facing by definition, they hold credentials, and they sit at a trusted position in the network.
Over the past several years, critical vulnerabilities in remote access and firewall appliances from multiple major vendors have been actively exploited in the wild, appearing repeatedly in the CISA Known Exploited Vulnerabilities catalog. Several large intrusions began exactly this way.
That does not make VPNs uniquely bad, and ZTNA products are software with vulnerabilities too. It does mean any internet facing access appliance needs to be patched with real urgency and monitored closely.
The user authenticates to a broker, usually through your identity provider with multi factor authentication. Device posture is checked. Policy decides which specific applications this identity, on this device, in this context, may reach.
A connection is then brokered to that application only. In the common outbound only model, a connector inside your network makes an outbound connection to the broker, which means the application does not need to be published to the internet at all.
That last detail is the biggest practical security win. There is no listening service for an attacker to scan, fingerprint, and attack.
Blast radius. A compromised account or device reaches a defined list of applications instead of a network range.
Visibility. Access decisions are per application and logged, so you can answer who accessed what, which is much harder with a network tunnel.
Contractor and third party access, which is one of the strongest use cases. Giving a vendor access to one application is far easier to reason about than putting them on a segment.
And attack surface, because internal applications stop being internet facing.
If the application itself is vulnerable, ZTNA delivers the attacker to it more cleanly. Access control is not application security.
Legacy protocols and thick client applications are frequently awkward or unsupported, which is why most organizations run both models for years.
It is a single point of failure in the access path, so the availability design matters.
And it centralizes access decisions on the broker, which makes the broker itself a very high value target that needs to be protected accordingly.
Zscaler Private Access, Palo Alto Prisma Access, Cloudflare Zero Trust, Netskope, Microsoft Entra Private Access, and Tailscale all occupy this space with different architectures.
Most are sold as part of a broader SASE or SSE platform rather than as standalone products.
Start with the highest risk access, which is usually third parties and administrative access to production, rather than trying to move all employees at once.
Run both in parallel during transition and shrink the VPN scope progressively rather than planning a cutover date.
Keep patching the VPN aggressively the entire time it exists, because it stays internet facing until the day it is switched off.
Understanding what a VPN actually does to a routing table is why the mentorship spends Week 2 on Linux routing before any of this comes up.