Why Your VPN Is Not Zero Trust - and Why It Matters

The phrase "Zero Trust" has been absorbed into vendor marketing so thoroughly that it's become difficult to use without qualification. Firewalls are marketed as Zero Trust. VPNs are marketed as Zero Trust. Products that are, charitably, perimeter security with a new coat of paint are marketed as Zero Trust.

The result is that many organizations believe they've adopted Zero Trust because they've modernized their VPN - or added MFA to it. They haven't. VPNs and Zero Trust are not different implementations of the same idea. They are architecturally opposed models built on different assumptions about where threats come from and what constitutes sufficient verification. Understanding the distinction isn't academic. It determines your actual exposure.

Section 01 - VPNs are built on a perimeter assumption that no longer holds

Risk tag: The model

A VPN extends your network perimeter. The underlying model is sometimes called "castle and moat": everything inside the perimeter is trusted, everything outside is not, and the VPN is the drawbridge that lets authorized users cross from untrusted to trusted territory. Once a user authenticates and connects, they're inside the castle. They have broad access to whatever the network contains.

This model made sense when your infrastructure lived in a physical datacenter, your employees worked from a fixed office, and your applications were hosted on servers you controlled. The perimeter was real and relatively defensible. The assumption that users inside it were trustworthy was at least operationally justified.

None of those conditions hold for most organizations today. Infrastructure is distributed across cloud environments. Employees work from home networks, coffee shops, and managed devices of varying integrity. Applications run in SaaS platforms that exist entirely outside your network. The perimeter is not just porous - for most modern stacks, it barely exists. A VPN authenticates a user and grants them network access. It has no mechanism for continuously evaluating whether that access remains appropriate as conditions change.

Section 02 - Zero Trust assumes breach and verifies continuously

Risk tag: The principle

Zero Trust is not a product category. It's an architectural principle, originally articulated by John Kindervag at Forrester in 2010 and formalized in NIST SP 800-207. The core axiom is simple: never trust, always verify. No user, device, or network location is inherently trusted - not even traffic that originates inside your own infrastructure.

In a Zero Trust architecture, every access request is evaluated at the time of the request against a defined set of signals: who is the user, is their identity verified, what device are they on, is that device compliant with your security policy, what are they trying to access, and does their role justify that access. Access is granted to the specific resource being requested, not to the network broadly. And that access is continuously re-evaluated - a session that starts legitimate can be terminated if signals change.

The practical implication is a fundamentally different blast radius when credentials are compromised. In a VPN model, a stolen credential grants network-level access - an attacker can move laterally to anything the user could reach. In a Zero Trust model, a stolen credential grants access only to what passes the policy evaluation at that moment, on that device, from that context. Lateral movement is structurally constrained.

VPN model:

• Authenticate once at the perimeter
• Broad network access granted
• Trust is implicit once connected
• No continuous verification
• Lateral movement is unconstrained

Zero Trust model:

• Every request evaluated independently
• Access scoped to specific resource
• Trust is never assumed
• Signals re-evaluated continuously
• Lateral movement is structurally limited

Section 03 - Where the VPN model breaks under real attack conditions

Risk tag: The failure modes

The gap between VPN and Zero Trust is not theoretical. It maps directly to the attack patterns that drive most enterprise breaches. Credential phishing campaigns don't care how strong your VPN authentication is - if a user can be convinced to hand over their credentials and MFA token in a real-time phishing proxy attack, an attacker authenticates as that user and inherits their full network access. The VPN has done its job correctly. That's the problem.

Compromised endpoints are a related failure mode. A VPN checks whether a user is authorized. Most VPN implementations do not continuously evaluate whether the device they're connecting from is compromised, unpatched, or running malicious software. Once the tunnel is established, traffic from an infected machine flows through it just as legitimately as traffic from a clean one. Device health is a signal that VPNs were never designed to consume.

The insider threat scenario exposes the broadest gap. A malicious or negligent insider with VPN access has, in most organizations, network-level visibility into far more than their job requires. Zero Trust's principle of least-privilege access - applied at the resource level, not the network level - constrains what any single compromised identity can reach. VPNs have no equivalent control once a user is authenticated.

Section 04 - What a Zero Trust architecture actually looks like

Risk tag: The implementation

Zero Trust is implemented as a set of coordinated controls, not a single product. The core components are an identity provider that serves as the policy decision point, a device management layer that enforces endpoint compliance, and an access proxy or network architecture that enforces the policy at the resource level. These three elements - identity, device, and access - are the pillars that replace the perimeter.

In practice, this means a user requesting access to an internal application is evaluated against: their verified identity (from the IdP), the compliance state of their device (from MDM or EDR), and the access policy for that application (from the access proxy). If any signal fails - unpatched OS, unrecognized device, anomalous login location - access is denied or stepped up, regardless of whether the user has valid credentials. The policy enforcement happens at the application layer, not the network layer.

For teams moving from VPN to Zero Trust, the transition is rarely a single cutover. Most organizations run both in parallel during migration, progressively moving applications behind Zero Trust access controls while phasing out broad VPN access. The forcing function is usually a security incident, an audit requirement, or a cloud migration that makes the perimeter model obviously untenable.

Tools that fit:

• Cloudflare Access - application-level Zero Trust proxy, integrates with any IdP
• Google BeyondCorp Enterprise - mature ZTNA with deep device trust integration
• Tailscale - lightweight mesh network with identity-aware access, good for smaller teams
• Okta + device trust - identity layer that feeds signals into access policy decisions

Section 05 - Why the distinction matters for teams building on cloud infrastructure

Risk tag: The stakes

For organizations running entirely on-premises infrastructure with a well-defined perimeter, a VPN is a reasonable control. That describes a shrinking minority of technology companies. For teams building on AWS, GCP, or Azure - with SaaS applications, remote workforces, and contractors accessing internal systems - the perimeter model is not just insufficient. It's actively misleading, because it creates confidence in a boundary that doesn't functionally exist.

The cost of a Zero Trust migration is real. It requires investment in identity infrastructure, device management, and access proxy tooling. It requires policy decisions about who can access what from where. It requires ongoing maintenance as your stack evolves. None of that is trivial.

But the cost of maintaining the VPN illusion is a network-wide blast radius on any credential compromise, no visibility into device health at the point of access, and an architecture that assumes threats originate outside your perimeter - when most post-breach analysis shows they don't. The question isn't whether Zero Trust is worth implementing. It's whether you can afford to keep operating as if the perimeter is real.

Further reading:

• NIST SP 800-207 - the authoritative Zero Trust architecture specification
• Google BeyondCorp research papers - the original real-world Zero Trust implementation

A VPN tells you a user is authorized. Zero Trust tells you a user is authorized, on a compliant device, from a recognized context, to access this specific resource, right now. Those are not the same statement - and the gap between them is where most breaches live.

The terminology problem is real but solvable. When a vendor claims their product is Zero Trust, ask one question: does it evaluate device health and enforce least-privilege access at the resource level, continuously, on every request? If the answer is "it's VPN with MFA," that's a useful VPN. It is not Zero Trust.

The architectural shift matters because the threat model has changed. Attacks don't come from outside your perimeter and stop at the drawbridge. They come through your users, your devices, and your supply chain - and they move laterally once inside. An architecture that assumes perimeter integrity cannot defend against that. One that assumes breach, and verifies everything, can.

Never trust. Always verify. That's not a slogan - it's a design constraint.