VPN Limitations Are the Remote Access Security Gap You Already Have

Seven Minutes Was All It Took

On August 4, 2026, an Akira ransomware affiliate started spraying passwords against a SonicWall SSL VPN. Seven minutes later, one of those attempts hit a valid credential. The account connected. MFA never prompted, never alerted, never did a single thing — because the VPN didn't enforce it.

That's the story in miniature. Not a zero-day. Not some exotic Kerberos relay. Just a password spray against an exposed endpoint that trusted "knowing the password" as sufficient proof of identity. BleepingComputer covered this through a Specops-sponsored piece, but the numbers behind it are harder to argue with: the Verizon DBIR consistently shows that stolen credentials feature in roughly 45% of confirmed breaches. Stolen credentials still work. The question is why they keep working in environments that swear they have MFA.

How Remote Access VPN Actually Works

Before I get into the gaps, let me sketch the architecture — because a lot of the confusion about MFA coverage traces back to people not understanding what a VPN actually does at the authentication layer.

A remote access VPN creates an encrypted tunnel between a user's device and the corporate network. The typical flow goes like this:

1. The user's VPN client initiates a connection to the VPN gateway (a hardware appliance or software service like SonicWall, Check Point, Fortinet, etc.).
2. The gateway authenticates the user — typically against an identity source like Active Directory, a RADIUS server, or an LDAP directory.
3. Once authenticated, the gateway assigns an IP address and establishes a tunnel (IKE/IPsec or SSL/TLS depending on the protocol).
4. All traffic through that tunnel lands inside the corporate network as if the user plugged into an office LAN port.

Step two is the critical one. Many VPN appliances validate credentials against Active Directory using protocols like NTLM or LDAP bind — the same paths that a Windows logon uses. If your MFA enforcement lives in a cloud identity provider like Entra ID or Okta, it sits in front of your SaaS apps. The VPN never talks to it. The gateway asks AD "is this password correct?" and AD says yes. Done.

This isn't hypothetical. It's the default behavior on a huge number of deployed VPN appliances that predate the cloud-IdP era and were never retrofitted.

Can MFA Be Bypassed? Not Always — But It Often Isn't Even Invoked

I want to draw a clear distinction here because the security community conflates two things constantly: MFA bypass (defeating the second factor through phishing, push fatigue, or session theft) versus MFA non-enforcement (the second factor was never triggered in the first place).

The latter is what attackers exploit far more often, and it's almost entirely invisible to security teams who've checked the "MFA enabled" box in their cloud identity console. The Hacker News / Specops research identifies seven Windows authentication paths where Entra ID or Okta MFA policies simply don't apply:

• Interactive Windows logon (the local or domain-joined sign-in screen). Authentication goes to AD via Kerberos or NTLM. No cloud IdP involved. No MFA.
• Hybrid Active Directory environments where Entra Pass-Through Authentication handles sign-ins. If the path doesn't route through a conditional access policy, MFA never fires.
• Service accounts and legacy protocols, Kerberos TGTs, NTLM hashes. These authenticate once and don't re-trigger MFA on subsequent requests within ticket lifetimes.

Each one is a separate authentication path that sits outside your cloud MFA coverage. The attacker who steals a password doesn't need to bypass your MFA. They just need to find a door where MFA was never installed.

VPN Limitations and Remote Access Security: Where the Coverage Actually Stops

This is the heart of the problem. The VPN gateway is where your cloud identity stack and your on-premises network meet, and at that junction, things often go wrong in three specific ways.

No MFA at the gateway itself. As the Akira incident demonstrates, a SonicWall SSL VPN with no second-factor enforcement is a password gate. Password sprays work against those because the gateway has no concept of "this came from an unusual IP with 200 other failed attempts." Some newer firmware supports RADIUS integration with an MFA provider, but older deployments, and there are hundreds of thousands still running, don't.

Token/session reuse after initial auth. Once a VPN session is established, the attacker inherits network-level access. If the VPN doesn't re-authenticate periodically or validate device posture, that access persists.

Protocol-level weaknesses. The Qilin ransomware intrusion via Check Point VPN exploited a zero-day in the IKEv1 protocol, the negotiation layer that sits underneath the authentication layer entirely. No amount of MFA helps if the protocol that carries your credentials has a broken handshake.

The broader pattern: internet-facing devices are attack surface, and edge device identity gaps compound the problem. Your VPN gateway authenticates users, but who's authenticating the gateway? Unpatched appliances, credential-harvested Fortinet devices, and unmanaged RDP endpoints all feed into the same operational failure, the assumption that "we turned on MFA" means "credentials don't matter anymore."

RDP: The Quiet Attack Surface That Almost Nobody Covers

Remote Desktop Protocol gets a bad rap, but unfairly. The protocol itself supports Network Level Authentication (NLA), strong encryption, and gateway-based routing. The problem is that the default configuration, especially on Windows Server, often ships with none of that enforced.

TSplus documentation for Windows Server 2025 outlines what a hardened RDP deployment actually requires:

• Restricting access to the Remote Desktop Users group via Group Policy (not local admin sprawl).
• Binding inbound access to known IPs or subnets so automated scanners can't find port 3389 in the first place.
• Enforcing FIPS-compliant session encryption so credentials don't traverse untrusted networks in plaintext.
• Disabling drive and clipboard redirection to cut data exfiltration paths.
• Auditing both successful and failed RDP logons, then forwarding those to a SIEM for correlation with authentication events.

That last one is key. If your SIEM ingests your cloud IdP logs (which show MFA events) but not your on-prem VPN or RDP logs (which show raw AD auth), you're building your detection on half the picture. An attacker authenticates over RDP, moves laterally, and your SOC never sees a failed-login spike because those logs live on a server nobody forwarded.

The Fix Isn't Exotic, It's Enumeration

I'm going to be blunt. The mitigation strategy here isn't glamorous. There's no new product to buy, no zero-trust framework that solves this by itself. It's a list:

1. Map every authentication path. Cloud IdP conditional access doesn't cover VPN gateways, RDP sessions, or interactive domain logons. Write down every protocol that validates a credential. If it doesn't call your IdP, it has no MFA.

2. Enforce MFA at the VPN gateway. Most major appliances now support RADIUS chaining or built-in MFA integration. If yours doesn't, that appliance is end-of-life whether the vendor admits it or not.

3. Enforce NLA on all RDP endpoints and restrict exposure behind an RD Gateway or a zero-trust network access (ZTNA) layer. Never expose raw port 3389 to the internet.

4. Audit and lock down legacy protocols. If NTLM is still active on your domain, that's a pass-the-hash vector. If Kerberos TGT lifetimes are 10+ hours, an attacker who steals a ticket has half a workday of access before it expires.

5. Unify your logging. SIEM coverage of on-prem authentication events isn't optional anymore. Correlate cloud MFA events against on-prem logon events. The gaps in coverage are where the breaches live.

What This Means for the Next Budget Cycle

The uncomfortable truth is that MFA coverage is an architecture problem, not a licensing problem. Organizations that adopted Microsoft 365 five years ago and layered Entra ID on top didn't decommission their on-prem authentication paths. Those paths kept working. Attackers found them.

The Akira affiliate who sprayed that SonicWall didn't outsmart your security team. They just walked up to a door where nobody had installed the lock.