Still Trusting Your VPN? Let's Talk About That

I'll be straight with you — up until a few years ago, I thought the same thing most people do: "VPN is on, we're safe." When IT handed me a VPN client and said "this makes it like you're sitting in the office," I just took their word for it. Didn't ask questions. Seemed reasonable enough.

Then I started digging into how enterprise breaches actually happen, and my perspective completely changed.

Here's the uncomfortable truth: the same remote-work explosion that drove VPN adoption through the roof after 2020 also turned VPNs into one of the most actively exploited attack surfaces on the internet. CISA (Cybersecurity and Infrastructure Security Agency) has repeatedly flagged VPN vulnerabilities in its Known Exploited Vulnerabilities catalog. The FBI's Internet Crime Complaint Center (IC3) lists compromised VPN credentials as a leading initial access vector for ransomware gangs year after year.

So how did the thing we use for security become a primary security liability?

Why VPNs Break Down Structurally

VPN's core concept — creating an encrypted tunnel so remote users can access internal networks — is still sound in theory. The problem isn't encryption. The problem is what happens after the tunnel opens.

The Three Most Common VPN Attack Paths

The first is unpatched VPN software vulnerabilities. Vendors like Fortinet, Ivanti (formerly Pulse Secure), Palo Alto, and Cisco regularly release critical CVEs — and organizations routinely fall weeks or months behind on patches. Attackers scan the internet for vulnerable instances and strike before IT gets around to updating. This isn't theoretical. It's happening constantly.

The second is credential stuffing. Attackers take username/password combinations leaked from other breaches — billions of which are freely available on dark web markets — and systematically test them against corporate VPN endpoints. Password reuse makes this devastatingly effective.

The third is the scariest: phishing for VPN credentials directly, then logging in as a legitimate user. The connection looks completely normal. There's no malware to detect, no exploit signature to catch. Just someone quietly walking through the front door with a stolen key card.

Real-World VPN Breach Cases That Should Worry You

Theory is one thing. Let's look at what's actually happened — because these aren't edge cases. They're the norm.

Ivanti Connect Secure Zero-Days (2024) — CISA issued an emergency directive after threat actors actively exploited critical vulnerabilities in Ivanti VPN appliances. Thousands of organizations worldwide, including federal agencies, were impacted. What made it worse: some compromises went undetected for months because attackers maintained persistence even after patches were applied.

Colonial Pipeline Ransomware Attack (2021) — The attack that shut down fuel supplies to the U.S. East Coast for nearly a week started with a single compromised VPN account. No multi-factor authentication was in place. One leaked password. $4.4 million in ransom. The economic and reputational fallout was enormous.

Fortinet SSL-VPN Exploits (Ongoing) — CISA and the FBI have issued multiple joint advisories about state-sponsored and criminal groups exploiting Fortinet appliance vulnerabilities. These advisories keep coming because the underlying problem — overly trusted perimeter access — hasn't been solved at the architectural level.

I'll be honest: when I first read through CISA's advisory history, I was surprised by how consistent the pattern is. Different vendors, different years, same fundamental story. The perimeter model has a structural expiration date, and we're well past it.

What Zero Trust Actually Means

Zero Trust as a formal framework was coined by John Kindervag at Forrester Research back in 2010. The name is the philosophy: Never Trust, Always Verify. No user, device, or system gets implicit trust — ever — regardless of whether they're inside or outside the network perimeter.

Where VPN says "you passed the front gate, welcome in," Zero Trust says "prove who you are, on what device, from where, to access this specific thing — and then prove it again next time you need something else."

When I first encountered this model, it felt almost paranoid. Surely we can trust our own employees? But then I thought about how many breaches involve valid employee credentials — whether stolen through phishing, purchased on the dark web, or misused by a disgruntled insider. Trust that isn't continuously verified isn't security. It's optimism.

The Three Core Zero Trust Principles

• 1
  Verify Explicitly — Every Time

  Every access request is evaluated using all available signals: user identity, device health, location, time of request, and behavioral patterns. A user authenticated at 9 AM from Chicago doesn't get a free pass at 3 AM from an unknown location in Eastern Europe.

• 2
  Use Least Privilege Access

  Users and systems get access only to what they actually need — nothing more. A marketing coordinator doesn't need access to the engineering database. A contractor working on one project doesn't get visibility into unrelated systems. Scope is tight and time-limited by default.

• 3
  Assume Breach

  Design as if attackers are already inside. Encrypt internal traffic, segment networks aggressively, log everything, and build automated responses to anomalous behavior. The goal shifts from "keep attackers out" to "limit what they can do once they're in."

NIST's Special Publication 800-207 (Zero Trust Architecture) is the definitive federal reference document here — and it's worth bookmarking if you're making the case internally for a Zero Trust transition. Having an NIST citation behind your proposal tends to move conversations forward.

VPN vs. Zero Trust — Side-by-Side Comparison

Sometimes a table is worth a thousand words. Here's how the two approaches stack up on the dimensions that matter most for security teams making decisions.

The "Breach Blast Radius" row is the one that changes minds in boardrooms. You can argue all day about architecture philosophy — but when you frame it as "if we get hit, how bad does it get?", the case for Zero Trust writes itself.

Step-by-Step Zero Trust Transition Roadmap

Here's where most organizations get stuck: they treat Zero Trust like it's an all-or-nothing rip-and-replace project. It's not. The reality is more like renovating a house while still living in it — you do it room by room, in a logical order, without tearing everything down at once.

I've seen teams get paralyzed waiting for "the perfect plan" while continuing to run VPN-only security for another two years. That's the wrong call. Start small. Direction matters more than speed.

Phase 1 — Inventory Everything & Harden Identity

Before you can control access, you need to know what you have. Map every user, device, application, and data flow in your environment. Then — and this is non-negotiable — enforce MFA (multi-factor authentication) across all users, especially for admin accounts and any remote access points.

Seriously. Just that. Start there.

According to Microsoft's internal threat intelligence data, MFA blocks more than 99% of account compromise attacks. It's the single highest-ROI security action any organization can take, and it's a prerequisite for everything that follows in a Zero Trust model.

Phase 2 — Redesign Access on Least Privilege

Audit what everyone actually needs access to versus what they currently have access to. You'll almost certainly find over-provisioned accounts, orphaned accounts from departed employees, and service accounts with excessive permissions. Clean all of that up. Then reissue access based on job function — nothing more.

This phase tends to surface surprises. One company I read about discovered a former contractor's credentials were still active 18 months after the engagement ended. That account had full internal network access the entire time.

Phase 3 — Implement Microsegmentation

Break the flat network into isolated zones. HR systems, finance infrastructure, engineering environments, customer data — each should exist in its own segment with explicit rules governing traffic between them. When an attacker lands in one segment, they hit a wall instead of an open corridor.

Software-defined networking tools and cloud-native security groups make this significantly more manageable than it was five years ago. You don't need to rebuild your entire network from scratch to get meaningful segmentation benefits.

Phase 4 — Continuous Monitoring & Automated Response

Zero Trust isn't a destination you arrive at — it's an operating posture you maintain. Log every access request, analyze behavior patterns, and build automated responses for anomalies: impossible travel (login from New York, then Tokyo 20 minutes later), off-hours access to sensitive systems, sudden spikes in data export volume.

SIEM platforms, cloud provider security services (AWS Security Hub, Microsoft Sentinel, Google Chronicle), and purpose-built Zero Trust solutions all have tooling for this. The key is closing the loop between detection and response.

Top Zero Trust Tools for 2026

The market has matured significantly. You're no longer choosing between "enterprise-only" options and "build it yourself." Here's an honest look at the landscape as of 2026 — where each solution actually fits, not just where vendors say it fits.

My honest take: if you're a small to mid-size org and haven't started yet, begin with either Microsoft Entra ID (if you're already in the Microsoft ecosystem) or Cloudflare Zero Trust (if you want something fast and vendor-agnostic). Both have solid documentation, active communities, and — critically — a free or low-cost entry point that lets you learn the model before committing to a larger spend.

For enterprises already evaluating Zscaler or Palo Alto: both are mature, capable platforms. The differentiator at that level usually comes down to which vendors you're already standardized on and where your apps actually live — not raw feature counts.