ZTNA vs VPN: Remote Access Architecture Comparison

A classic remote-access VPN puts an authenticated user on the corporate network and then relies on segmentation to limit where they can go. Zero Trust Network Access replaces that with per-application brokering: the user authenticates to an identity provider, a policy engine evaluates device posture and context, and the connection terminates at the application rather than at the network edge. This article compares the two models on the dimensions that decide real deployments — trust boundary, attack surface, and operational overhead.

The trust boundary

The shift is not "more encryption"; it is removing the implicit trust that follows from being on the network.

Why the brokered model changes the failure modes

# VPN model: reachability test after connecting
ip route get 10.20.30.10          # routed via tun0
nmap -Pn -p 22,445 10.20.30.10    # works - user is on the network

# ZTNA model: the same host is not routable at all
ping 10.20.30.10                  # request timeout
# access is via the connector path: app.example.net -> connector -> 10.20.30.10:443

The second behaviour is the security benefit and the operational headache: traditional troubleshooting ("can you ping it?") no longer applies, and troubleshooting moves to the identity provider's logs, the policy engine's decision log, and the connector's connectivity status.

Migration pattern that works

1. Inventory the flows. From VPN logs, extract which users reach which applications. Most estates find 60–80% of traffic goes to a handful of HTTP(S) applications.
2. Move web and SaaS first. Browser-based applications migrate with the least user impact and give the fastest proof of value.
3. Keep VPN for the remainder. Database clients, legacy thick clients, ICMP-based monitoring and anything UDP-heavy usually stay on VPN.
4. Harden what remains. If VPN cannot be removed, add device certificates, per-group address pools and tighter internal ACLs rather than treating it as unchanged.

Decision inputs

• Contractors and BYOD — ZTNA wins decisively; no client software on personal devices beyond a browser.
• Third-party maintenance access — ZTNA with time-bounded, approval-based entitlements beats a standing VPN account.
• OT/industrial and legacy protocols — expect VPN to remain; brokers rarely handle raw L2 or unusual UDP well.
• Cost — per-user ZTNA licensing versus concentrator capacity plus the staff time to keep segmentation accurate. Compare on the flows that actually move, not on headcount.

Definition of done for a pilot

1. Identity provider is the single source of truth for group membership
2. Zero standing access: entitlements expire, MFA is enforced for admin apps
3. Connector health is monitored and alerted like any other production service
4. VPN logs and ZTNA decision logs land in the same SIEM index for correlation
5. A documented break-glass path exists for the day the identity provider is down

Related reading: Tailscale WireGuard mesh VPN operations, Cloudflare Access with Entra ID, and OPNsense VLAN interfaces and firewall rule processing.

原文链接：https://www.nist.gov/publications/zero-trust-architecture