Editor’s note: The following is a guest post from Kent Lawson, founder and CEO of Private Communications Corporation.
There is a pattern that should concern every MSP serving small and midsize businesses. A critical SSL VPN vulnerability is disclosed. A patch is issued. Organizations scramble to apply it only to learn of another critical vulnerability in the same product line just a few months later. As the cycle repeats, unpatched SSL VPN appliances have become the number one initial access vector for ransomware.
This is not a future risk. It is happening now.
In the past 18 months, Fortinet FortiOS SSL VPN has disclosed a series of high and critical CVEs, including CVE-2024-21762, a critical out-of-bounds write vulnerability rated 9.6 that Fortinet warned was likely already being exploited at the time of disclosure.
SonicWall SSL VPN has followed a parallel pattern, with multiple critical authentication bypass and remote code execution flaws, including CVE-2024-40766, a CVSS 9.3 access control vulnerability targeted by ransomware groups within days of disclosure. The Volt Typhoon campaign identified Fortinet VPN appliances as an entry point into U.S. critical infrastructure. SonicWall appliances running end-of-life firmware have appeared on CISA’s Known Exploited Vulnerabilities catalog with no patch available, leaving managed service providers in the impossible position of managing hardware the vendor can no longer protect.
I have been in the VPN infrastructure business for more than a decade. What we are seeing now is not a rough patch in an otherwise reliable technology. It is the structural end of an architecture that was built for a world that no longer exists.
A structural problem
SSL VPN was designed to extend a corporate perimeter to remote users. The assumption baked into that model is that once a user authenticates, they can be trusted with broad network access. That assumption was always a risk. In today's threat environment, it is a liability.
When an attacker compromises an SSL VPN gateway, they get a foothold into the entire network behind it. The VPN concentrates risk into a single, internet-facing appliance that has become one of the highest-value targets in the adversary playbook. Nation-state actors know this. Ransomware groups know this.
For enterprises with dedicated security teams and the resources to patch rapidly, this is a manageable problem. For SMBs served by MSPs, it’s a different story. Most SMB clients cannot sustain a patch cadence that keeps pace with the current SSL VPN vulnerability rate. Many are running appliances that are approaching or already past end-of-life. And most do not have the internal visibility to know whether a given appliance has already been compromised before a patch is applied.
A difficult conversation
Most SMB clients are not going to walk in asking for a VPN replacement. They trust their MSP to understand the threat landscape and bring solutions before problems become incidents. That is both the opportunity and the responsibility here.
The channel is in a unique position to lead a transition. MSPs already own the remote access relationship. They know the clients that are running legacy SSL VPN appliances, approaching end-of-support or putting off patching. That is the starting point for a proactive conversation that positions the provider as a security leader rather than a break-fix vendor.
The conversation does not have to be complex. The core message is straightforward: the technology your remote access is built on has become a primary attack vector, the vendor patch cadence cannot keep up and there is a better architecture available that eliminates the exposure.
A practical migration
The good news for MSPs is that moving clients off SSL VPN does not require a rip-and-replace project. The replacement architecture — cloud-native VPN with a built-in path to Zero Trust Network Access — can be deployed alongside existing infrastructure and transitioned gradually.
The core difference in the ZTNA model is that access is granted per application, per identity, per session, rather than at the network level. A compromised credential or endpoint cannot be used to move laterally across the network the way it can through a traditional SSL VPN tunnel. The blast radius of any given breach is fundamentally smaller.
For MSPs managing multiple SMB clients, the operational case is equally compelling. Cloud-delivered remote access eliminates the hardware lifecycle, reduces the patching burden and scales without appliance upgrades. For clients in industries facing cyber insurance scrutiny, the move away from legacy SSL VPN appliances increasingly aligns with insurer priorities.
The migration does not have to happen all at once. A phased approach, starting with the most vulnerable clients or those whose SSL VPN appliances are nearest to end-of-life, gives MSPs a manageable rollout and clients time to adapt.
An SMB imperative
The consequences for SMB clients running vulnerable SSL VPN infrastructure are not theoretical. Credential theft, client data exposure and ransomware are the direct outcomes already appearing in incident reports tied to SonicWall and Fortinet appliances. Compounding the risk, cyber insurers are beginning to deny claims when vulnerable legacy infrastructure is identified as a contributing factor. An SMB client hit with ransomware through an unpatched SSL VPN gateway may find itself without coverage at the moment it needs it most.
The guidance coming from the major SSL VPN vendors is consistent: buy new hardware, rip out the old stack and jump straight to ZTNA. For enterprises with dedicated IT teams and capital budgets, that may be a workable path. For most SMBs, it’s not a migration plan but a disruption event. A forklift replacement of remote access infrastructure, with no bridge from where they are to where they need to be, is the kind of project that gets deferred until after an incident.
Every SSL VPN deployment is a replacement conversation waiting to happen. Across the SMB market, that represents millions of endpoints running infrastructure with no good path forward under the current vendor guidance. MSPs who can offer a practical alternative — one that does not require ripping out existing infrastructure or disrupting operations — should start the conversation before a competitor or an incident does it for them.
A channel window
Every major SSL VPN vendor has acknowledged, through product end-of-life notices, advisory language or their own migration guides, that the direction of travel is toward Zero Trust architectures. The market is moving. The question is whether MSPs will lead their clients through that transition or respond to it after an incident.
The MSPs who move proactively will earn deeper client relationships, recurring revenue from modern managed access services, and a defensible position when the next wave of CVEs hits. The ones who wait will be spending their time explaining to clients why the technology they were still running was already on the exploited vulnerabilities list.
The SSL VPN era is not ending. It has ended. The channel's job now is to help clients land safely on the other side.
