Why the VPN Is Dying + Zero Trust Principles

For two decades the corporate network worked like a castle: a hard perimeter (the firewall and the VPN) around a soft interior where, once you were "inside," you could reach almost everything. That model is failing, and the failure is the reason "Zero Trust" went from a buzzword to a procurement requirement. This lesson explains why the VPN perimeter breaks down, what Zero Trust actually means as a set of principles (not a product), and how ZTNA — Zero Trust Network Access — replaces "on the network" with "authenticated, authorized, and healthy, per request." This is the conceptual backbone for the tools you'll compare next and the policy you'll configure after.

What a VPN actually does — and why that's the problem

A traditional VPN authenticates you once, then drops you onto the internal network. From that point you have network-level access: you can route to internal systems, and reaching any given application is mostly a matter of network connectivity plus that app's own login. The implicit assumption is trust by location — being on the network is treated as evidence you belong.

Three shifts broke that assumption:

• The perimeter dissolved. Work moved to SaaS, multi-cloud, and home offices. There is no single "inside" anymore — the data is in Google Workspace, Salesforce, AWS, and a dozen other places the VPN never sat in front of.
• Lateral movement is the attacker's whole game. Once an attacker phishes one laptop or steals one VPN credential, the flat internal network lets them move sideways to reach the systems they actually want. The 2010s breaches that defined modern security — and the ransomware playbook today — are lateral-movement stories. A VPN that grants broad network access is an accelerant.
• Trust-by-location ignores device health. A valid VPN credential on a compromised, unpatched, or personal device still gets in. Location says nothing about whether the endpoint should be trusted.

The summary an auditor will recognize: a VPN gives coarse, network-level, login-once access with implicit trust, and that is exactly the shape of access modern attacks exploit.

Zero Trust: "never trust, always verify"

Zero Trust is a security model, codified in NIST SP 800-207, built on one assumption: no implicit trust is granted based on network location. Every access request is verified as if it originated from an untrusted network — because, increasingly, it did. The core principles:

• Verify explicitly. Every request is authenticated and authorized using multiple signals — identity, device posture, location, time — not just "you reached the port."
• Least-privilege, per-resource access. Access is granted to a specific application, not the whole network. Reaching the wiki gives you no path to the finance app.
• Assume breach. Design as if an attacker is already inside. Microsegment, verify continuously, and limit blast radius so one compromised identity or device can't reach everything.

The mental shift: the unit of access changes from "the network" to "this user, on this device, to this application, right now." Trust is never permanent — it's re-evaluated on each request against current signals.

ZTNA: Zero Trust applied to network access

ZTNA is the technology pattern that implements those principles for application access. Instead of putting users on the network, a ZTNA broker sits in front of each application and brokers access per request:

1. The user's request hits the ZTNA proxy/broker, not the app directly. The application itself is not exposed to the internet — there's no open inbound port to attack.
2. The broker authenticates the user against the identity provider (Okta, Entra ID, Google), enforcing MFA.
3. The broker checks device posture — is the device managed, encrypted, patched, running EDR? — typically via the MDM/EDR signals from Phase 3.
4. The broker evaluates the per-application policy — is this user, in this group, allowed to reach this specific app under these conditions?
5. Only if all of that passes is the single connection brokered. The user never gets network-level reach to anything else.

The contrast the diagram makes concrete: under the VPN, one credential reaches three apps by default; under ZTNA, the same user reaches only the apps their policy explicitly allows, each gated on a healthy device and a fresh MFA check — and the apps have no internet-facing front door for an attacker to even find.

Why GRC cares: the controls this satisfies

ZTNA is not just architecture hygiene — it directly produces the evidence behind several control families:

• Least-privilege / logical access (SOC 2 CC6.1, CC6.3; ISO 27001 A.8.2–8.3) — access is scoped per application and reviewable as policy.
• Network segmentation and secure access (ISO 27001 A.8.20–A.8.22; CC6.6) — applications aren't exposed to untrusted networks; there's no flat internal network to traverse.
• MFA and device trust (CC6.1; the conditional-access work from Phase 3) — every session carries an identity and device-posture decision you can log and prove.
• Continuous monitoring — the broker logs every access decision (who, what app, what device, allowed/denied), giving you a per-request audit trail a VPN never produced.

That last point matters for evidence: a ZTNA broker's access logs are a far richer artifact than "user connected to VPN at 09:14." You can show an auditor exactly which identities reached which applications, on what devices, and why each was allowed.

What to carry forward

The VPN's model — authenticate once, get broad network-level access, trust by location — fails because the perimeter dissolved and lateral movement is the attacker's path. Zero Trust answers with "never trust, always verify": per-resource least privilege, explicit verification on every request, and assume-breach design. ZTNA implements it by brokering access to individual applications based on identity, MFA, and device posture, with no implicit network reach and a per-request log. The unit of access moves from the network to "this user, this device, this app, now."

Next you'll compare the three tools teams actually reach for to implement this — Cloudflare Access, Tailscale, and Twingate — and see how their different architectures map to the same principles.