Your VPN Is Now One of Hackers' Favourite Entry Points. Here's What Replaces It.

When your organization set up a VPN, the logic was simple: give remote workers an encrypted tunnel back into the office network, and they can work from anywhere safely. For two decades, that model worked. Remote work was the exception, not the rule. The corporate network was the perimeter. The VPN was the gate.

That world no longer exists. Cloud applications, remote-first teams, contractors accessing systems from personal devices, and an entirely different threat landscape have fundamentally changed what secure remote access means. And VPNs — designed for a different era — have not kept up. They have become one of the most actively targeted entry points in modern cyberattacks.

Compromised VPN credentials were the initial access vector in 48% of ransomware attacks in Q3 2025, up from 38% just the quarter before. Edge device and VPN exploits jumped from 3% to 22% of all vulnerability-based breaches — an approximately 8x year-over-year increase. The ransomware groups doing the most damage right now — Akira, Qilin, Inc Ransom — specifically target VPNs as their preferred front door.

This is not a reason to panic. It is a reason to understand what is happening, why VPNs have this problem structurally, and what the replacement looks like. This post covers all three.

Why VPNs Have Become a Primary Target

VPNs are not inherently insecure. The problem is structural — the way VPNs work creates specific vulnerabilities that are difficult to address regardless of how well they are maintained.

VPNs sit on the public internet by design

A VPN gateway is an internet-facing appliance. It has to be publicly reachable for remote users to connect to it. This means it appears in internet scanning tools like Shodan. It has a known IP address. It is running software with a version number that maps to known vulnerabilities. In April 2025, researchers found more than 4,000 Ivanti VPN systems exposed to the internet and vulnerable to a critical authentication bypass exploit. In February 2025, over 4,500 SonicWall VPN endpoints were still unpatched against a vulnerability that had been disclosed months earlier.

Every VPN appliance is a target. The question is whether it has been patched against current exploits — and the data on patching speed is not reassuring.

🚨  The average time to patch an edge device or VPN vulnerability is 209 days. Attackers can weaponize the same vulnerability in as little as 5 days. That 204-day gap is exactly where ransomware groups operate — scanning for known-vulnerable VPN endpoints, establishing persistence, and deploying ransomware weeks or months before anyone notices the intrusion.

A compromised VPN credential gives attackers a key to everything

This is the deeper structural problem with traditional VPNs. When a user connects to a VPN, they are placed on the corporate network. The VPN does not know — or care — which specific applications that user actually needs. They are in. Everything accessible from the network is accessible to them.

This is called the implicit trust problem, and it is the reason a single compromised VPN credential can be so catastrophic. An attacker who obtains a VPN username and password — through phishing, credential-stuffing attacks using leaked password lists, or purchasing credentials from dark web marketplaces — does not get access to one application. They get broad network access. From there, they can move laterally, discover other systems, escalate privileges, and deploy ransomware across the network before anyone realizes the initial VPN credential was compromised.

⚠️  92% of organizations are concerned about being targeted by ransomware through unpatched VPN vulnerabilities. 89% rate lateral movement — an attacker spreading from the VPN connection across the entire network — as a top concern. These are not hypothetical risks. They are the documented mechanics of how the most costly ransomware attacks of 2025 actually started.

VPNs have no built-in access controls

A traditional VPN makes a binary decision: is this user authenticated? If yes, they are on the network. There is no built-in capability to say 'this user should only be able to reach the accounting application, not the file server' or 'this device has not had its security patches applied in 60 days, so access should be restricted until it is remediated.'

Those kinds of granular controls require additional layers of configuration, additional tools, and ongoing maintenance that most small and mid-sized organizations simply do not have the resources to maintain consistently. The result is overly permissive access — and overly permissive access is what makes a single compromised credential into a major incident.

Real-world VPN breaches: the pattern is consistent

The major VPN-related attacks of the past two years follow a recognizable pattern:

• Ivanti Connect Secure (January 2025): Critical zero-day vulnerabilities (CVE-2025-0282 and CVE-2025-0283) allowed unauthenticated remote code execution. Suspected Chinese APT groups exploited these against financial institutions and government agencies, exfiltrating sensitive data and establishing persistent access before patches were available.
• SonicWall SSL-VPN (late 2024–2025): A critical authentication bypass (CVE-2024-53704) required only base64-encoding 32 null bytes in a request to bypass authentication entirely. More than 4,500 endpoints remained unpatched months after disclosure. Akira ransomware specifically targeted SonicWall VPNs as a primary attack vector.
• Fortinet FortiGate VPN (recurring): Multiple critical remote code execution vulnerabilities over 2023–2025, including CVE-2023-27997, have made Fortinet VPN appliances recurring targets. In late 2025, SonicWall announced end-of-life for its SMA 100 appliance line after discovering OVERSTEP backdoor malware on the platform.
  

None of these are isolated incidents. They represent a systematic campaign by well-resourced threat actors to exploit the structural weaknesses of internet-facing VPN appliances — weaknesses that cannot be patched away entirely because they are inherent to how VPNs work.

The Operational Problems That Come With VPNs

The security risks are the primary concern, but VPNs also create operational friction that has become increasingly hard to justify as better alternatives become available.

• Performance bottlenecks: Traditional VPNs route all traffic back through a central hub — typically a physical or virtual appliance at your main office or data centre. Every employee working remotely sends their traffic on a detour through that hub before it reaches the cloud application they are actually trying to use. In a cloud-first environment where most applications are in Microsoft 365, SharePoint, or other SaaS platforms, this backhauling adds latency with no security benefit.
• Complexity at scale: 72% of organizations managing multiple VPN deployments run between two and five different VPN services. Enforcing consistent security policies across multiple VPN gateways, for remote staff, contractors, and branch offices, is an IT management burden that consumes significant resources.
• Third-party and contractor access is a persistent gap: Giving a contractor or vendor temporary VPN access typically means giving them network-level access — the same broad access that creates the lateral movement risk. Managing that access correctly, restricting it to what they actually need, and reliably revoking it when the engagement ends is operationally difficult.
• BYOD and personal devices: VPNs generally cannot check the security posture of a device before granting access. An employee connecting through an unpatched personal laptop brings all of that device's vulnerabilities into your network.

What Replaces the VPN: ZTNA and SASE Explained

Zero Trust Network Access (ZTNA) and Secure Access Service Edge (SASE) are the frameworks that organizations are adopting to replace traditional VPN-based remote access. They are not just different technology — they represent a fundamentally different security model.

The core principle: never trust, always verify

The defining characteristic of Zero Trust is the elimination of implicit trust. A traditional VPN says: this user authenticated, so they are trusted on the network. Zero Trust says: authentication is necessary but not sufficient. Before granting access to any resource, verify the user's identity, the device's security posture, what they are trying to access, whether that access is appropriate for their role, and whether everything checks out against current security policies. Then grant access to that specific application — not the network.

📋  The analogy: a VPN is a master key to the building. ZTNA is a key that opens only the specific rooms the user is authorized to enter — and only when they meet the current security requirements. Even if someone steals the key, they cannot access anything they were not explicitly authorized for.

Zero Trust Network Access (ZTNA): application-level access control

ZTNA replaces the network-level access of a VPN with application-level access control. When a user needs to access a system, ZTNA evaluates:

• Who is this user — is their identity verified against your identity provider (such as Microsoft Entra ID)?
• Is this device healthy — does it meet your organization's security requirements (OS version, patches, endpoint protection status)?
• Is this access appropriate — does this user's role actually require access to this specific application?
• Is the context normal — is this an unusual location, time of day, or access pattern that warrants additional scrutiny?

If all checks pass, the user gets access to that specific application. Not the network. Not adjacent systems. Just what they need, verified at every session. Even if their credentials are compromised, the attacker faces verification requirements they cannot meet — no healthy managed device, no match to the user's normal access patterns — and access is denied or restricted.

Critically, ZTNA eliminates the lateral movement problem. Because the user is never placed on the network, a compromised account cannot be used to scan the network, pivot to adjacent systems, or escalate privileges across the organization. The blast radius of a credential compromise is fundamentally reduced.

Secure Access Service Edge (SASE): the full security stack in the cloud

SASE takes the Zero Trust approach and combines it with the broader security and networking capabilities an organization needs into a single cloud-delivered platform. Where ZTNA focuses specifically on access control, SASE adds:

• Secure Web Gateway (SWG): filters web traffic, blocks malicious sites, enforces acceptable use policies for every user regardless of where they are working
• Cloud Access Security Broker (CASB): provides visibility and control over SaaS application usage, including shadow IT detection and data governance
• Firewall as a Service (FWaaS): delivers enterprise firewall capabilities from the cloud without requiring appliances at every location
• Data Loss Prevention (DLP): prevents sensitive data from leaving the organization through any channel
• SD-WAN integration: optimizes traffic routing so users connect directly to cloud applications without backhauling through a central hub, improving performance significantly

For an organization that currently manages a VPN, an on-premises firewall, separate endpoint security, and various cloud security tools as separate systems, SASE consolidates much of this into a single managed platform — reducing complexity, improving consistency of policy enforcement, and eliminating the performance penalty of traditional VPN backhauling.

VPN vs. ZTNA vs. SASE: Side-by-Side

Getting From VPN to Zero Trust: A Practical Approach

Replacing a VPN is not a single event — it is a phased transition that can happen alongside your existing infrastructure. The good news: ZTNA and SASE are designed to coexist with VPNs during the migration period. You do not have to cut everything over at once.

Step 1: Understand what your VPN is actually protecting

Before you can replace your VPN, you need to know what it is being used for. Most organizations find their VPN usage falls into a small number of categories: remote employees accessing internal applications, contractors or vendors needing limited access, branch offices connecting to central resources, and users accessing legacy on-premises systems that cannot easily move to the cloud. Each of these has a corresponding ZTNA or SASE solution. Always Beyond can audit your current VPN usage as the first step in building a transition roadmap.

Step 2: Start with the highest-risk access patterns

Third-party and contractor access is typically the highest-risk and easiest to migrate. Contractors often have broad VPN access that they rarely need — scoping their access to specific applications through ZTNA immediately reduces risk without disrupting internal users. Employee access to cloud-based applications (Microsoft 365, SharePoint, cloud-hosted tools) is the next natural candidate — these users do not need VPN-level network access to reach SaaS platforms, and ZTNA with direct-to-app access gives them better performance with stronger security.

Step 3: Deploy ZTNA alongside your existing VPN

ZTNA can be deployed in parallel with an existing VPN. Users who have been migrated to ZTNA access applications through the new system; those not yet migrated continue using VPN. This parallel operation allows IT to test, refine policies, and migrate in waves rather than all at once. It also allows the organization to maintain access to legacy systems that genuinely require network-level access while the rest of the environment moves to application-level access.

Step 4: Harden your VPN while the migration happens

During the transition period, your VPN remains part of your infrastructure and needs to be actively managed:

• Ensure all VPN appliances are on current firmware — patch within days of critical vulnerability disclosures, not weeks
• Enable and enforce MFA for all VPN connections — even compromised credentials cannot be used without the second factor
• Review VPN access logs for unusual patterns — off-hours connections, connections from unexpected geographies, connections followed by large data transfers
• Reduce the scope of VPN access for users who have been partially migrated to ZTNA — they should not need both full network access and application-level access

💡 If your VPN appliance is from a vendor that has had repeated critical vulnerabilities — Ivanti, SonicWall, Fortinet — and your firmware is not current, contact Always Beyond now. These are the specific appliances being actively targeted by ransomware groups today.

Canadian Considerations: Compliance, Data Sovereignty, and PIPEDA

For Canadian businesses, the shift from VPN to ZTNA and SASE carries specific regulatory relevance beyond pure security posture.

• PIPEDA breach notification: A successful ransomware attack that originated through a VPN breach — particularly one involving access to personal information about customers, employees, or clients — triggers mandatory notification obligations to the Privacy Commissioner of Canada and affected individuals. The remediation and notification costs of a VPN-enabled breach are significant. ZTNA's reduced blast radius meaningfully limits the scope of a potential breach even if credentials are compromised.
• Third-party risk: Many Canadian businesses use VPNs to give vendors, accountants, lawyers, or IT contractors remote access to systems. Under PIPEDA, you remain responsible for personal information accessed by third parties on your behalf. ZTNA's application-scoped access for third parties reduces your exposure and makes it materially easier to demonstrate that third-party access was appropriately limited.
• ‍OSFI guidance for financial services: Federally regulated financial institutions and many provincially regulated ones operate under OSFI's technology and cyber risk guidance, which explicitly addresses third-party risk and the security of remote access. ZTNA's granular access controls and audit trail capability align well with OSFI's expectations around demonstrable access governance.‍
• Cloud data residency: SASE platforms vary in where their enforcement points are located. If Canadian data residency is a requirement for your organization — particularly relevant for healthcare, financial services, and organizations serving Quebec residents under Law 25 — this is an important evaluation criterion when selecting a SASE or ZTNA platform. Always Beyond can advise on platform options with appropriate Canadian data handling commitments.

Frequently Asked Questions

Do we need to completely replace our VPN right away?

No — and most organizations should not try to. A phased transition is the right approach: deploy ZTNA alongside your existing VPN, migrate users and applications in waves, and maintain VPN for legacy systems that genuinely require it during the transition. The urgency is to start — particularly if your VPN appliances are from vendors with recent critical vulnerabilities — not to cut everything over at once. Always Beyond can help you build a transition roadmap that fits your timeline and budget.

Our team is small. Is ZTNA really relevant for a 20-person company?

Yes, and in some ways more so than for large enterprises. Smaller organizations are frequently targeted by ransomware groups precisely because they are assumed to have weaker controls. The Akira ransomware group — responsible for the majority of VPN-targeted attacks in 2025 — specifically targets SMBs. ZTNA solutions have become significantly more accessible and cost-effective for smaller organizations, and the protection they provide scales down as well as up. The per-user licensing model is often more cost-effective than maintaining VPN infrastructure as the organization grows.

What is the difference between ZTNA and SASE?

ZTNA is the access control component — it replaces the VPN by granting application-level access based on identity and device posture rather than network-level access. SASE is the broader framework that includes ZTNA plus additional security services: web filtering, cloud application security, data loss prevention, and network optimization. Think of ZTNA as replacing your VPN, and SASE as replacing your VPN plus a number of other security tools in a consolidated cloud-delivered platform. Most organizations transitioning from VPN start with ZTNA and expand to SASE as they consolidate their security stack.

What happens to our on-premises systems that are harder to move to ZTNA?

ZTNA can protect on-premises applications too — it is not limited to cloud-hosted systems. Access to on-premises resources is proxied through the ZTNA platform, which enforces identity and device posture checks before granting access to the application. Legacy systems that genuinely cannot be reached without network-level access may require VPN access during a transition period, but most applications that were traditionally accessed via VPN can be transitioned to ZTNA with minimal disruption.

Should we be concerned if our VPN is a brand that has had recent vulnerabilities?

Yes — and this is worth treating with urgency. If your organization uses Ivanti, SonicWall, or Fortinet VPN appliances, verify that your firmware is current and that you have applied all recent security patches. These specific platforms were the primary targets of the most damaging VPN-based attacks in 2025. If your appliances are not on current firmware, or if they are approaching end-of-support, contact Always Beyond for a priority review. This is not a routine maintenance issue — it is an active risk.

The VPN Is Not Dead — But It Should Not Be Your Only Line of Defence

VPNs still have a role in many organizations. They are not going to disappear overnight, and for specific use cases — legacy system access, site-to-site connectivity — they remain appropriate. But as the sole mechanism for remote access security, the traditional VPN model is no longer sufficient for the threat environment that exists today.

The organizations that are reducing their exposure to ransomware and credential-based attacks are the ones moving to a Zero Trust model — verifying every access request based on identity and device posture, limiting access to what users actually need, and eliminating the lateral movement risk that makes a single compromised credential into a catastrophic incident.

This is not a future state to plan for. It is the direction the industry has moved, and the tools to implement it are available, increasingly cost-effective, and designed to work alongside your existing infrastructure during the transition.

Want to know where your VPN infrastructure stands? Always Beyond can assess your current remote access security posture, identify which appliances carry active vulnerability risk, and build a transition roadmap to ZTNA that fits your timeline and operational needs. Reach out to start the conversation.