I’m going to say something that will make some security vendors very unhappy: Zero Trust is, in its current industry manifestation, largely a marketing rebrand of concepts that have existed for decades, and the rush to declare VPN dead is causing real security gaps in real organizations.
Let me be precise about what I mean, because nuance matters here.
What Zero Trust Actually Is (vs. What It’s Sold As)
The Zero Trust model was articulated by John Kindervag at Forrester in 2010. The core principle is sound: never trust, always verify. Don’t assume that traffic from inside your network perimeter is safe. Verify identity and authorization for every request, regardless of network location.
This is a good principle. It’s also not new. Mutual TLS, certificate-based authentication, and least-privilege access controls have been best practices for decades. What Zero Trust as a framework adds is a systematic approach to applying these principles consistently.
But here’s what happened: the security vendor community got hold of “Zero Trust,” declared it a product category, and started selling it as a replacement for everything that came before—especially VPN. Products got rebranded as “ZTNA” (Zero Trust Network Access). Marketing decks appeared proclaiming “VPN is dead.” Enterprise security teams, eager to appear modern, started decommissioning their VPN infrastructure.
And then things started breaking.
What VPN Actually Does
To understand why killing VPN is dangerous, you need to understand what it actually provides that ZTNA solutions don’t (or don’t do well).
Layer 3/4 network access: A VPN client creates a virtual network interface on your device. You’re on the network. Traffic flows through it at the IP/TCP level. This means:
- Legacy applications that use IP-based access controls work without modification
- Network-based monitoring (IDS/IPS) sees all traffic from VPN clients
- RDP, SSH, and other direct protocol connections work naturally
- Subnet-level access to network segments (not just individual applications)
ZTNA solutions, by contrast, are application proxies. They sit in front of specific applications and broker access to them. You’re not “on the network”—you’re connecting to specific applications through a proxy.
This is great for SaaS applications and modern HTTP/HTTPS apps. It’s a problem for:
- Legacy applications that weren’t designed for proxy-based access
- Database connections that need direct TCP access
- Network management tools that need SNMP, ICMP, or other non-HTTP protocols
- Infrastructure management (managing network devices, servers, storage)
- Any application that uses client certificates or IP-based access control
The Infrastructure Problem
Here’s a scenario that plays out regularly in organizations that have “gone Zero Trust” by decommissioning VPN:
Your network team needs to SSH to a core router to make a config change. With VPN, they connect the VPN, and they have Layer 3 access to the management network. SSH works.
With ZTNA-only, the ZTNA solution doesn’t proxy SSH to arbitrary network devices. It brokers access to specific, registered applications. Your routers and switches aren’t “applications” in the ZTNA model. They’re network infrastructure.
Now your network team is either:
- Jumping through a bastion host that does have network access (which is effectively a VPN by another name)
- Physically on-site
- Using an out-of-band management network (which is also effectively a VPN)
You haven’t eliminated the trust boundary. You’ve just made it less explicit and more complicated.
The Monitoring Gap
VPN provides something ZTNA doesn’t: full network traffic visibility. When a VPN client connects, your security team can see all traffic from that client—DNS queries, TCP connections to unexpected destinations, lateral movement attempts.
ZTNA solutions only see traffic going through the proxy. Everything else your device is doing? Not visible. If a compromised device is beaconing to a C2 server over HTTPS, ZTNA won’t show you that. Your EDR might, but you’ve lost a layer of defense.
What Zero Trust Gets Right (and What to Keep)
I’m not arguing against Zero Trust principles. I’m arguing against the replacement of VPN with ZTNA as a complete security solution.
What ZTNA does better than VPN:
- Application-level access control: Grant access to specific applications, not broad network segments. An employee needs Salesforce and Workday? Give them access to those apps. Not access to the entire corporate network.
- Clientless access: ZTNA can broker access through a web browser with no client install. Useful for contractors, BYOD, and external partners.
- Continuous verification: Unlike VPN sessions that establish trust at connection time, ZTNA can continuously verify device posture and identity.
- Split tunneling done right: With VPN, split tunneling is often misconfigured or disabled for compliance reasons. ZTNA is inherently split—only proxied traffic goes through.
The Right Architecture: Both
Here’s the architecture that actually works:
ZTNA for application access:
- SaaS and web applications
- Internal HTTP/HTTPS applications
- Modern cloud workloads
- Contractor and external partner access
- BYOD scenarios
VPN (WireGuard, ideally) for:
- Infrastructure management (network devices, servers, storage)
- Database access requiring direct TCP
- Legacy applications incompatible with proxied access
- Security team network monitoring and incident response
- Development environments requiring network-level access
Both with:
- Identity-aware access controls (not just “connected to VPN = trusted”)
- Continuous device posture checking
- Network-level monitoring on VPN traffic
- Zero Trust principles applied to both access mechanisms
WireGuard: VPN Doesn’t Have to Be Legacy
Part of why Zero Trust advocates successfully positioned VPN as “legacy” is because they were mostly arguing against IPSec-based solutions from vendors like Cisco and Palo Alto—software that genuinely feels like it’s from another era, client software that requires IT to install and maintain, and complex authentication flows.
WireGuard changed this. It’s:
- A few thousand lines of kernel code (auditable, fast, modern)
- Cryptographically modern (Curve25519, ChaCha20, BLAKE2s)
- Configuration that fits in 15 lines
- Blazingly fast (kernel-native, not userspace)
- Available on every platform
[Interface]
PrivateKey = <private-key>
Address = 10.0.0.2/24
DNS = 10.0.0.1
[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.company.com:51820
AllowedIPs = 10.0.0.0/8
PersistentKeepalive = 25
That’s a WireGuard client configuration. It’s not 1998 IPSec. It’s not a bloated Cisco AnyConnect client. Modern VPN isn’t inherently legacy.
The Real Lesson
Zero Trust as a principle is correct: don’t trust network location, verify identity and authorization for everything, apply least privilege.
Zero Trust as a product category that “replaces VPN” is a vendor narrative designed to sell ZTNA subscriptions to organizations that then discover they still need VPN for their infrastructure and re-purchase VPN as well.
The organizations that are actually secure aren’t the ones that declared VPN dead. They’re the ones that applied Zero Trust principles to everything—including their VPN, which now has identity-aware access controls, device posture checking, and least-privilege network segmentation.
Zero Trust is a methodology, not a product. Buy the methodology. Keep your VPN.
