The short answer
Zero trust network access gives each person access to specific applications after checking identity and device health. A VPN puts the person on the network, then trusts the network to limit what they reach. That difference drives most of the choice.
For remote staff who use cloud apps, contractors, and personal laptops, zero trust network access usually fits better. It reduces the exposed network and gives per-app logs. For a small team with a few on-prem servers and stable devices, a VPN can be simpler and cheaper to run.
A practical pattern is to use both. Use zero trust network access for new cloud apps and third parties. Keep a VPN for legacy systems, site-to-site links, or protocols that do not proxy well. Decide per use case, not as a company-wide rule.
| Aspect | Zero trust network access | VPN |
|---|---|---|
| Access model | Per-app access through an identity-aware proxy | Network-level tunnel into internal subnets |
| Authentication | SSO, MFA, device posture, and group policy | VPN credentials, certificates, and optional MFA |
| Internet exposure | Outbound connector, no inbound firewall ports | Public VPN gateway reachable from the internet |
| Lateral movement risk | Lower because each app is separated by policy | Higher if the tunnel reaches broad subnets |
| User experience | Browser or client per app, often no full tunnel | One tunnel for all allowed network traffic |
| Legacy protocol support | Good for web and TCP apps, weaker for UDP and broadcast | Broad IP support, including fixed-address and old clients |
| Operations | Policy design, identity hygiene, connector health | Gateway patching, capacity, routes, certificates |
| Visibility | Per-app session logs tied to identity | Connection logs, with less app context |
How zero trust network access works
A zero trust network access setup has three parts: an identity provider, a policy engine, and a connector inside the private network. The connector makes outbound connections to the vendor cloud. You do not open inbound firewall ports to the internet. Staff open an app or a client, sign in through SSO with MFA, and the policy engine checks group, device posture, location, and time.
The policy names the app, not the subnet. For example, finance can reach the payroll app but not the file server. Contractors can reach one project tool for 30 days. The connector proxies the session and logs who reached what. Many products check disk encryption, OS patch level, and EDR status before allowing access.
Plan the app inventory first. Legacy clients that use fixed IPs, broadcast, or odd UDP ports may need a different path. Run connectors in pairs for redundancy. Test latency through the nearest point of presence. Clean up identity groups, because bad group data becomes bad access policy. Watch for DNS and certificate issues during rollout.
How a VPN works
A VPN builds an encrypted tunnel from the device to a VPN gateway. The gateway authenticates the user, assigns an internal IP address, and routes traffic to internal subnets. Common forms are IPsec, WireGuard, and SSL VPN portals. Many firewalls include a VPN server, so the entry cost is low.
With full tunneling, all traffic goes through the gateway, including personal browsing. With split tunneling, only traffic for internal ranges uses the tunnel. Split tunneling saves bandwidth but can weaken control if the device is compromised. The gateway must be reachable from the internet, so it needs patching, MFA, and monitoring.
A VPN is protocol agnostic. It carries file shares, printers, IP phones, database clients, and old client-server apps. That is its strength. The risk is broad access. Once connected, a user often reaches many subnets. A stolen laptop with an active session can move laterally unless you add firewall rules and segmentation.
When to choose zero trust network access
Choose zero trust network access when most work happens in browsers and SaaS. It fits remote-first teams, contractors, and BYOD programs because you can require device checks and limit each person to named apps. It also helps when you want to retire a public VPN gateway.
It is a good fit when you need per-app logs for audits, fast onboarding for partners, or access across several clouds. You can publish an internal app without flattening networks. It also supports acquisition cleanup: map apps, connect them, then remove broad network trust.
Check the gaps. Some zero trust network access products handle web and TCP apps well but struggle with UDP, multicast, or custom protocols. Voice, video, and industrial systems may need a VPN or a direct private link. Confirm client support for your operating systems and your identity provider. Pilot with one app and one group before a wide rollout.
When to choose a VPN
Choose a VPN when you have a small, stable group and a short list of on-prem systems. A firewall VPN with MFA may be enough. It is also the right tool for site-to-site links between offices, data centers, and cloud networks.
Keep a VPN for protocols that need full network access. Examples include old client-server apps, network printers, IP phones, and admin tools that use fixed addresses. If your team must reach many internal hosts with arbitrary ports, a VPN with tight firewall rules is simpler than publishing each app.
A VPN also fits when IT capacity is limited and the current firewall already handles it. The trade-off is operational discipline. Patch the gateway, enforce MFA, remove stale accounts, review routes, and log sessions. Without those steps, a VPN becomes a flat network door.
Costs and effort to consider
Compare total effort, not just the license. A VPN may look cheap because the firewall already includes it. Add staff time for patching, capacity planning, certificate renewal, and split-tunnel support. A zero trust network access project adds identity cleanup, app mapping, connector design, and policy tuning.
Count the hidden work. Zero trust network access often needs a strong identity provider and device inventory. A VPN needs firewall rules and network segmentation to reduce blast radius. Both need logging, alerting, and a rollback plan. Both need user training so people know when to use which path.
Run a pilot with one app, one group, and one measure of success, such as fewer support tickets or faster onboarding. Document the decision per app. Keep a legacy path for systems that cannot move. One option among others is the Expert architecture session, $450 one-time, from Cloudverg, which gives a 90 minute review and a written summary.
Frequently asked questions
Is zero trust network access a replacement for VPN?
It can replace a VPN for web and TCP apps that you can publish through a connector. It is not a full replacement for every protocol or for site-to-site links. Many teams keep a VPN for legacy and network-level access.
Can a company use a VPN and zero trust network access together?
Yes. A common split is zero trust network access for SaaS and internal web apps, and a VPN for old client-server systems or office links. Keep the policies and logs separate so you can see which path each user takes. Review both paths during onboarding and offboarding.
What does a VPN do that zero trust network access does not?
A VPN carries arbitrary IP traffic over one tunnel, so it handles broadcast, multicast, fixed-address clients, and many legacy protocols. Zero trust network access usually publishes specific apps and may not support those cases well. Test your required protocols before you remove a VPN.