Quick take
VPNs give you a tunnel into a flat network and hope for the best. Zero trust checks identity, device, and context on every single request. COVID just accelerated what was already obvious: the perimeter is dead. Kill your VPN dependency before it kills you.
March 2020. Every company on earth scrambles to get employees working from home. The answer for most? Crank up the VPN capacity. Buy more licenses. Pray.
I watched this unfold from both sides. At the fintech startup we’d already moved most services behind identity-aware proxies. At Decloud we were building infrastructure that assumed zero trust from day one. Meanwhile, companies that had spent a decade building fat VPN pipes were routing all their cloud traffic through a single gateway in an office nobody was sitting in.
The absurdity was staggering.
The VPN mental model is from 1996
Here’s how a VPN works in practice:
Remote laptop -> encrypted tunnel -> office network -> everything
That arrow into “everything” is the problem. Once you’re through the gate, the network treats you like you’re sitting at a desk in the building. Same access. Same trust. Same flat network where a compromised laptop can reach the database server, the admin panel, the file shares, all of it.
VPNs do get a few things right. Encryption in transit is solid. The connect-then-work model is simple for users. And for weird legacy protocols that can’t be proxied, sometimes a network tunnel is genuinely the only option.
But the failure modes are brutal:
- Lateral movement is trivial. One stolen credential and the attacker is “inside.” Game over on a flat network.
- Performance is terrible for cloud workloads. You’re backhauling traffic to an office gateway just to reach AWS. In 2020. While nobody is in the office.
- Visibility stops at the perimeter. You know someone connected. You don’t know what they’re doing once they’re in.
- Scaling is painful. VPN concentrators have hard capacity limits. Ask anyone who hit them in March.
During my time working with NATO cyber defense, the model was already shifting. You can’t protect a network perimeter when the network spans allied nations, temporary field deployments, and dozens of classification levels. The answer was always granular access control tied to identity and clearance, not network location.
Zero trust is an architecture, not a product
I need to say this because vendors have completely destroyed the term. Zero trust isn’t a product you buy. It’s not a firewall with a new label. It’s an architecture decision: no request is trusted by default, regardless of where it comes from.
Every access decision considers:
- Who is making the request (identity, authentication strength, MFA)
- What device they’re on (managed? encrypted? patched?)
- What context surrounds the request (location, time, risk signals)
- What resource they’re trying to reach (and whether they actually need it)
In practice, this looks like per-application access policies instead of network-wide trust:
app: internal-wiki
rules:
- name: employee-access
conditions:
- identity: authenticated
- mfa: required
- device: managed
action: allow
- name: default
action: deny
Simple. Explicit. Every app gets its own policy. No more “you’re on the VPN so you can reach everything.”
The actual differences that matter
Forget the marketing comparisons. Here’s what changes day to day:
Blast radius. VPN compromise gives attackers the network. Zero trust compromise gives them one application session, maybe, if they also have the right device posture and MFA token.
Performance. VPN routes everything through a chokepoint. Zero trust lets users connect directly to the resource. Your team in Vilnius doesn’t need to hairpin through a London office to reach a Frankfurt data center.
Auditability. With a VPN you get connection logs. With zero trust you get per-request decisions with full context. When something goes wrong, and it will, you actually know what happened.
User experience. This one surprises people. Zero trust done right is invisible. No “connect to VPN” step. No split-tunnel headaches. You open the app, the policy engine checks everything behind the scenes, and you’re in. Or you’re not.
When to keep the VPN
I’m not dogmatic about this. VPNs still earn their place in specific scenarios:
- Legacy applications that genuinely require L3/L4 network access and can’t be proxied
- Air-gapped or highly isolated environments where direct internet connectivity isn’t allowed
- Temporary access for third-party contractors working with ancient systems
- Specific protocols that don’t speak HTTP and can’t be wrapped
The key distinction: VPN as a tactical tool for specific legacy needs, not as your security architecture.
How to actually migrate
At Decloud, we built with zero trust from scratch. Most companies don’t have that luxury. Here’s the migration path I’ve seen work:
Step 1: Get identity right. Centralize authentication. Enforce MFA everywhere. Not “for admins.” Everywhere. This is the foundation and nothing else works without it.
Step 2: Know your devices. Define what a “trusted device” means. Managed. Encrypted. Patched within some reasonable window. Start enrolling endpoints.
Step 3: Move web apps first. SaaS tools and internal web applications are the easiest to put behind an identity-aware proxy. BeyondCorp style. This covers 70-80% of what people actually use daily.
Step 4: Shrink the VPN scope. Every app you move to per-app access is one less reason for the VPN to exist. Segment your internal network. Tighten VPN access to only the systems that genuinely need it.
Step 5: Instrument everything. Log every access decision. Not just “allowed/denied” but the full context. You’ll need this to tune policies and prove the model works.
Step 6: Iterate. Review access logs weekly. Find overly broad policies and tighten them. Find unnecessary friction and reduce it. This isn’t a project with an end date. It’s how you operate now.
The traps I’ve seen teams fall into
Buying a “zero trust product” and calling it done. You didn’t adopt zero trust. You bought a proxy. The architecture change is what matters.
Exception creep. Someone important complains about access friction, you create a broad exception, and suddenly you’ve rebuilt the perimeter you were trying to eliminate. Every exception should have an expiration date and an owner.
Ignoring device health. MFA plus a compromised laptop is still a compromised session. Device posture isn’t optional.
No communication plan. People will lose access to things. If you don’t explain why and provide a clear path to regain access, you’ll face a revolt and the project will get rolled back.
Where this is going
The perimeter model worked when your employees, your servers, and your data all lived in the same building. That world is gone and it’s not coming back.
Zero trust isn’t new. Google published the BeyondCorp papers years ago. The military has operated on need-to-know principles forever. What’s new is that 2020 made it impossible to ignore. Every company just ran a forced experiment in remote access at scale, and the VPN-first companies suffered the most.
Start the migration now. Identity and MFA this month. Per-app access for your top ten applications this quarter. Shrink the VPN to legacy-only by end of year.
The network perimeter is dead. Stop defending a border that doesn’t exist.