Compare Zero Trust and VPN to secure remote business networks

Stolen credentials, harvested session tokens, and MFA-fatigue campaigns have turned the corporate VPN portal into a frequent target across enterprise environments. The architecture is not outdated by accident. It is outdated by design.

The move toward distributed workforces, cloud-hosted applications, and bring-your-own-device policies has quietly dismantled the network perimeter. What remains is a series of encrypted tunnels pointing into networks that no longer have clear edges. Security teams that continue to treat the VPN as a primary access control are not being cautious. They are running a defense optimized for a topology that stopped existing years ago.

The Perimeter Fallacy: Why VPNs Struggle with Modern Remote Work

The traditional corporate network was a castle. The firewall was the wall. The VPN was the drawbridge, lowered for credentialed travelers. Inside, every workstation, server, and printer shared the same broadcast domain. Trust was ambient. Visibility was total. The model assumed that anyone who cleared the moat had legitimate business inside.

That assumption is bankrupt.

Modern enterprises do not operate inside castles. They operate across SaaS platforms, regional offices, home networks, and unmanaged mobile devices. The "inside" is a legal fiction maintained by IP ranges and Active Directory forests. Attackers know this. They do not breach perimeters. They authenticate into them. Stolen credentials, session tokens lifted from infostealer logs, and aggressive MFA-fatigue campaigns have turned the VPN portal into the softest target in the infrastructure.

The architecture is complicit in its own compromise. A VPN grants broad network reach once the user is authenticated. There is no native mechanism to limit what the authenticated user can see or touch. Subnet enumeration, SMB relay, and lateral movement are not exotic techniques. They are the default behavior of any compromised endpoint dropped onto a flat corporate network through a tunnel.

Security teams that respond to this by adding more VPN concentrators, more MFA prompts, or more aggressive password rotation are addressing symptoms. The disease is the trust model itself.

The perimeter did not vanish overnight. It was dismantled from the inside, one remote worker, one cloud app, one stolen credential at a time.

NIST 800-207 and the Core Philosophy of Zero Trust Architecture

In 2020, the National Institute of Standards and Technology published Special Publication 800-207. The document is not a product specification. It is a confession that perimeter-based security had failed and a prescription for what comes next. The core tenet is blunt: never trust, always verify.

Zero Trust Architecture operates on the premise that no user, device, or session is trusted by default, regardless of network location. Every access request is authenticated, authorized, and logged against a continuous evaluation of identity, device posture, and behavioral context. The model assumes the network is already compromised. It assumes the attacker is already inside. It functions anyway.

Mechanically, this is implemented through Software-Defined Perimeter (SDP) gateways and Identity-Aware Proxies (IAPs). These components do not advertise resources to the public internet. A database, an internal application, a file share — none of them respond to unsolicited traffic. They exist on the network as dark addresses, invisible until an authenticated, policy-compliant request arrives through the broker. Attackers cannot probe what they cannot find. They cannot exploit what they cannot reach.

This is not theoretical hardening. The shift from addressable infrastructure to gated, broker-mediated access is a categorical change in attack surface. A VPN tunnel is a road into the network. A Zero Trust proxy is a door that opens for one user, one application, and the duration of one session — and only when policy allows.

Side-by-Side: VPN and Zero Trust at a Glance

Lateral Movement Risks: Flat Networks vs. Granular Control

The most damaging property of a VPN-based architecture is not the authentication weakness. It is what happens after authentication succeeds.

Once a VPN tunnel is established, the authenticated user typically receives a routable position on the corporate network. From that position, the user can reach other systems — often far more than the user's role requires. This is the structural definition of a flat network. It is also the operational ideal for ransomware affiliates, who treat the initial access as a foothold and the flat network as a highway.

The playbook is documented and repetitive. A phishing email delivers a loader. The loader drops an infostealer. The stealer captures VPN credentials and MFA tokens. The credentials are repackaged and sold to an access broker. The broker logs in through the VPN portal. The broker enumerates the subnet. The broker identifies a domain controller, a file server, or a backup appliance. The broker escalates. The broker exfiltrates. The broker hands the keys to a ransomware crew. The crew encrypts everything reachable from the flat network.

Zero Trust breaks this sequence at multiple points. Identity is gated. Device posture is verified. Lateral access to other resources is denied by default. A compromised credential in a Zero Trust environment opens one door, not the entire building. The blast radius of a single stolen token is measured in megabytes, not terabytes.

The difference is not philosophical. It is operational. One architecture assumes the user is who they claim to be and grants them a network. The other assumes the user might be an attacker using stolen credentials and grants them nothing without continuous proof.

Performance Bottlenecks and the Latency Cost of Backhauling Traffic

The performance argument against VPNs is older than the security argument, and security teams have been ignoring it for years.

A traditional VPN terminates traffic at a central concentrator — often a data center appliance in a single geographic region. Remote users in Singapore, São Paulo, and Stockholm all funnel their traffic through the same gateway before it reaches its destination. For a user accessing a SaaS application hosted on the same continent, the round trip is circuitous. The latency tax is real. The bandwidth cost compounds.

Cloud-native applications did not design themselves around this constraint. They expect direct, optimized routing. A user in Frankfurt accessing a Microsoft 365 resource does not need that traffic to land in a corporate data center in Virginia. The hub-and-spoke topology of legacy VPN was built for a world where most applications lived in that data center. That world is gone.

Zero Trust, properly implemented with cloud-delivered brokers, can route traffic to the nearest point of presence. The user authenticates at the edge. The broker forwards the request to the application — wherever it lives. Backhaul becomes optional, not mandatory. The latency penalty disappears for most workflows. Bandwidth costs on the corporate internet pipe drop correspondingly.

Vendors will frame this as a productivity gain. It is more accurate to frame it as the removal of an architectural tax that should never have been paid. The VPN's performance penalty was not a feature. It was friction caused by centralizing access to a network that no longer existed in any meaningful sense.

Strategic Implementation: Transitioning from Legacy Tunnels to Identity-Aware Proxies

The VPN is not dead. It is a tool. Like any tool, it has appropriate use cases.

Site-to-site connectivity between regional offices, access to legacy applications that cannot tolerate proxy mediation, and regulated environments with explicit tunneling requirements remain valid scenarios for VPN deployment. Security leaders who declare the VPN obsolete are either selling something or unfamiliar with the operational reality of large networks. The honest assessment is narrower. The VPN is no longer appropriate as the primary mechanism for workforce remote access in environments where identity, device, and context can be evaluated continuously.

The transition to Zero Trust is not a project. It is a program. NIST 800-207 is explicit on this point. A functioning implementation requires:

• An identity provider capable of conditional access and continuous session evaluation
• An endpoint management regime that produces trustworthy device posture signals
• A policy engine that evaluates identity, device, and context against access decisions
• A broker layer — SDP, IAP, or equivalent — to enforce those decisions at the resource

None of these components are novel. Most enterprises already own at least the identity layer. The work is in integration, in policy authoring, and in retiring the implicit trust that the VPN has been subsidizing for two decades.

The cost objection is real and deserves an honest answer. Zero Trust done well is a multi-year capital and operational investment. For organizations with constrained budgets, the path usually starts with the highest-value targets — administrative accounts, production data stores, anything holding regulated data — and expands outward from there. When capital expenditure is frozen and the existing VPN concentrator is end-of-life, the operational and risk calculus must be confronted directly.

Continuing to expose a flat corporate network through a single VPN portal, year after year, while Zero Trust remains on the roadmap, is no longer strategic caution. It is negligence, and the post-incident reports will reflect that finding.

The strategic direction is set. It has been codified in NIST 800-207. The architectural direction is not in dispute. The question that remains is how much of the existing flat network will stay reachable through legacy tunnels while the transition is underway. Every month a flat network remains accessible through a single VPN portal is a month during which a stolen credential, sold for a few hundred dollars, can convert into a multi-million-dollar incident.

The question is no longer whether to abandon the VPN. It is how to do so without taking the rest of the infrastructure with it.