VPN or ZTNA: which remote access model fits your company

A VPN puts a device on a network and lets it reach whatever that network allows. Zero trust network access, or ZTNA, grants a verified user and device access to specific applications only. Small teams with a few internal systems can stay on a well run VPN. Teams with many apps and contractors usually gain from ZTNA.

The core difference

Think of a VPN as a long cable into the office. Once connected, the device has an address on the internal network, and what it can touch is decided by firewall rules.

ZTNA works the other way around. The user asks for an application, a broker checks who they are and the state of their device, and it opens a path to that one application. The rest of the network is not reachable, and often not visible.

NIST describes the idea behind this in its Zero Trust Architecture publication, SP 800-207: no implicit trust is granted to assets or user accounts based only on their physical or network location, and protection centers on resources rather than network segments.

Where a VPN is still reasonable

• You have a handful of internal systems and a small, stable team.
• Applications use odd protocols that proxy based tools handle poorly.
• You already run a gateway with MFA, patching discipline and segmented firewall rules.

A VPN is not a failure. A VPN with narrow rules and strong login is better than a half deployed ZTNA product nobody finished configuring.

Where ZTNA earns its keep

• Contractors and vendors need access to one system, not a network.
• You are tired of firewall rule sprawl.
• Most apps are web based or can sit behind an identity aware proxy.
• You want per request decisions based on device state.

The honest trade is effort. ZTNA means inventorying applications, mapping who needs what, and fixing identity first. If your identity provider is a mess, ZTNA will expose that.

Migration without a big bang

You do not have to choose once. A common path:

1. List internal applications and their owners.
2. Move web apps behind the new model first.
3. Keep the VPN for legacy protocols with narrow rules.
4. Remove VPN access group by group as apps move.
5. Close the old gateway when usage reaches zero.

The pilot plan for one app first walks through the first step.

What neither model fixes

Neither one fixes a compromised endpoint that already has a valid session, weak passwords, or an unpatched gateway. Edge devices are targeted often, which is why patching VPN gateways first matters in both worlds.

Quick check

Sources

• NIST SP 800-207, Zero Trust Architecture

Last reviewed: 19 October 2026.