SonicWall SMA 100 SSL VPN deactivation: what comes next

SonicWall deactivated all SMA 100 series appliances on 31 October 2025 after repeated exploitation of critical vulnerabilities. Affected models include the SMA 200, 210, 400, 410 and 500v. If you are still running one of these devices or encountering SSL VPN license errors on your SonicWall firewall, you have three realistic paths forward: migrate within SonicWall’s ecosystem (Cloud Secure Edge or SMA 1000), move to a vendor-neutral ZTNA/SASE platform, or temporarily shift SSL VPN sessions to a Gen 7 firewall while you plan the longer migration.

If you landed here because your SonicWall console just threw a license error, you are not alone. Thousands of mid-market IT teams hit this wall after SonicWall pulled the plug on the SMA 100 series. This post covers the technical details of the deactivation, explains the license errors, and maps out your options.

What happened to SonicWall SMA 100 SSL VPN

SonicWall ended support for the entire SMA 100 series on 31 October 2025 and actively deactivated the devices. After that date, the appliances stopped functioning. VPN connectivity, cloud-based security services and firmware updates all ceased simultaneously. This was not a standard end-of-life announcement with a multi-year wind-down. SonicWall accelerated the timeline after security researchers and CISA confirmed active exploitation of multiple critical vulnerabilities in the SMA 100 line.

The trigger was a chain of vulnerabilities that made the devices indefensible. CVE-2024-38475, a path traversal flaw in the Apache mod_rewrite module used by SMA 100 firmware, carries a CVSS score of 9.8. It allows unauthenticated attackers to read arbitrary files on the appliance, including session tokens. When chained with CVE-2023-44221 (CVSS 7.2, post-authentication command injection), attackers achieved full remote code execution. CISA added both CVEs to its Known Exploited Vulnerabilities catalogue on 1 May 2025.

Google’s Threat Intelligence Group (GTIG) attributed exploitation activity to UNC6148, a threat group linked to Abyss-branded ransomware operations. WatchTowr Labs published a proof-of-concept in May 2025 demonstrating how the two CVEs chain together for full system compromise.

Additional CVEs disclosed in 2024 exposed deeper architectural weaknesses.

The affected models are the SMA 200, SMA 210, SMA 400, SMA 410 and SMA 500v. SonicWall’s no-charge replacement programme ended on 1 December 2025. In 2026, no firmware updates, no technical support and no hardware replacements are available for these devices. Services that relied on active cloud entitlements, including Endpoint Control, Botnet Filtering and Geo-IP Filtering, stopped functioning on the EOS date.

Why you are seeing the “maximum SSLVPN license” error

If your SMA 100 is deactivated and your organisation shifted remote access to a SonicWall Gen 7 firewall, you may be hitting this error:

Maximum SSLVPN license [number] is reached

This message means the firewall has hit its concurrent SSL VPN tunnel limit. It appears when more users try to connect via NetExtender than the hardware can support, regardless of how many software licences you purchased through MySonicWall.

The root cause is a mismatch between licence entitlements and hardware capacity. During the SMA 100 migration programme, SonicWall offered SSL VPN licences for Gen 7 firewalls matching the user count on the old SMA appliance. But every firewall model has a hard ceiling on simultaneous SSL VPN tunnels, and that ceiling is often lower than what the SMA 100 handled.

When you activate 100 licences on a TZ270, the 51st user who tries to connect will see the error. The licences are valid, but the hardware cannot serve them.

Three things to check before escalating. First, verify in the MySonicWall portal that licences are correctly associated with the firewall’s serial number, not still linked to the deactivated SMA appliance. Second, ensure the firewall runs the latest SonicOS 7.1.x firmware, as earlier versions contained bugs in SSL VPN entitlement handling. Third, look for idle sessions holding licences open. Setting aggressive idle timeouts (10 to 15 minutes) reclaims capacity from sessions where the user disconnected without logging out.

For organisations where the firewall’s hardware ceiling is genuinely too low, a firmware fix will not help. The options are upgrading to a higher-tier firewall, or moving to a cloud-delivered access solution where concurrent session limits are tied to your licence count rather than appliance hardware.

Your three realistic options after SMA 100 deactivation

Option 1: Stay within SonicWall (Cloud Secure Edge or SMA 1000)

SonicWall’s recommended path is Cloud Secure Edge (CSE), a cloud-native ZTNA solution. CSE removes the public-facing hardware gateway, integrates with identity providers like Microsoft Entra ID, and applies continuous trust scoring based on device posture. SonicWall offered a trade-up programme with up to 52% discount on 3-year CSE licences. That programme’s no-charge exchange window closed on 1 December 2025, though paid migration paths remain available.

For organisations with complex legacy requirements, the SMA 1000 series is an alternative. It handles larger-scale deployments but lacks some SMA 100 capabilities, including the built-in WAF. Supplementing with an external WAF service adds cost and complexity.

Option 2: Move to a vendor-neutral ZTNA/SASE platform

A forced vendor migration is an opportunity to evaluate whether staying in the same ecosystem makes sense. Vendor-neutral platforms, including Jimber, Cato Networks and Cloudflare One, provide ZTNA without tying you to a single firewall vendor’s licensing cycle. The architectural shift is the same as CSE (identity-based, per-application access, no public gateway), but you avoid repeating the single-vendor dependency that created this migration pressure in the first place.

Jimber’s SASE platform combines ZTNA, Secure Web Gateway, Firewall-as-a-Service and SD-WAN in a single console. For mid-market teams running 50 to 400 users, deployment typically completes in days for a pilot group and weeks for broader rollout. Transparent per-user pricing avoids the bandwidth-tier surprises common with enterprise SASE vendors.

Option 3: Temporary band-aid (SSL VPN on Gen 7 firewall)

If you need remote access restored within hours, not weeks, shifting SSL VPN sessions to a Gen 7 TZ or NSA firewall is the fastest fix. This resolves the immediate connectivity gap but does not address the architectural problem. You are still exposing a VPN gateway to the internet, still granting network-level access after authentication, and still running into the hardware capacity limits described above.

This option makes sense as a bridge for two to four weeks while you plan and pilot one of the first two options. Running it beyond that turns a temporary measure into a permanent liability, especially if you enable split tunnelling to manage bandwidth, which introduces its own compliance risks under NIS2.

The security implications of staying on SMA 100

Some organisations still have SMA 100 appliances connected to their network. If the device retains a perpetual VPN licence, tunnels may technically still function even without support. Running one in 2026 is accepting documented, actively exploited risk.

The CVE-2024-38475 and CVE-2023-44221 exploit chain gives unauthenticated attackers a path from the public internet to arbitrary command execution on the appliance. Google’s Threat Intelligence Group linked this chain to UNC6148, a group associated with data exfiltration and ransomware. Even after the EOS date, SonicWall issued an exceptional hotfix in December 2025 for CVE-2025-40602 (CVSS 6.6), a privilege escalation zero-day, underscoring that new vulnerabilities continue to surface in hardware that no longer receives regular patches.

Cyber insurers have taken notice. Underwriters routinely scan policyholder perimeters using external vulnerability scanners. A SonicWall SMA 100 interface visible on the internet triggers immediate scrutiny, and some insurers have added SonicWall legacy appliances to their exclusion lists.

For European organisations, the compliance exposure is equally concrete. NIS2 Article 21 requires “appropriate and proportionate technical, operational and organisational measures” to manage network security risks. Operating a device that the manufacturer has publicly declared unsafe and deactivated is difficult to defend as proportionate. The broader trend of why ZTNA is replacing VPN in 2026 applies doubly when the VPN hardware itself has been decommissioned by its maker. Belgian organisations facing CyberFundamentals (CyFun) verification in 2026 must demonstrate that end-of-life equipment has been retired or isolated. Auditors specifically check for decommissioning of unsupported network devices as part of the Basic and Important level assessments.

A practical migration timeline

Whether you choose SonicWall’s Cloud Secure Edge, a vendor-neutral SASE platform, or a combination, the migration follows a predictable pattern. This timeline assumes a mid-market organisation with 50 to 300 users.

For organisations that still have a SonicWall TZ or NSA firewall handling temporary SSL VPN traffic, this timeline runs in parallel. Each application published through ZTNA reduces the load on the firewall, gradually eliminating the “maximum SSLVPN license” bottleneck. Platforms like Jimber that support parallel deployment let you keep legacy access running for unmigrated users while the new architecture handles everything else.

If you also plan to exit the broader SonicWall ecosystem, our broader SonicWall to SASE migration guide covers the full stack replacement, from firewall rules and content filtering to SD-WAN connectivity.

Frequently asked questions

Is my SonicWall SMA 100 still safe to use in 2026?

No. Support ended on 31 October 2025. Multiple CVEs with CVSS scores above 9.0 are confirmed exploited in the wild. Running an SMA 100 creates unpatched exposure that most cyber insurance policies will not cover.

Can I downgrade firmware to re-enable SSL VPN on SMA 100?

Downgrading removes the final patches and exposes the device to every known exploit chain, including CVE-2024-38475 and CVE-2023-44221 which affect all firmware versions prior to 10.2.1.14-75sv.

Does the “maximum SSLVPN license” error mean my SMA 100 is broken?

This error typically appears on Gen 7 firewalls (TZ or NSA series) when concurrent users exceed the hardware limit. Check licence synchronisation in MySonicWall and clear idle sessions. If the hardware ceiling is the bottleneck, cloud-delivered ZTNA removes the constraint.

What is the cheapest way to replace SMA 100 SSL VPN?

For fewer than 50 remote users with an existing Gen 7 firewall, shifting SSL VPN to the firewall is cheapest. For anything larger, a per-user ZTNA subscription avoids hardware investment.

Is the SMA 1000 series also affected?

The SMA 1000 had its own critical vulnerability (CVE-2025-23006, CVSS 9.8) but remains supported and patched. It is designed for larger deployments and carries enterprise pricing that may not suit mid-market budgets.

Can I migrate to a non-SonicWall ZTNA solution while keeping my firewall?

Yes. ZTNA platforms operate independently of your firewall vendor. Your SonicWall firewall handles north-south traffic while ZTNA manages how SSL VPN is being deprecated across vendors and application-level access.

How long do I have before SonicWall ends all SMA 100 support?

It has already ended. Support ceased 31 October 2025. SonicWall did issue one exceptional hotfix in December 2025 for an actively exploited zero-day, but this was explicitly described as an exception.

The SMA 100 deactivation forced a decision that many IT teams had been postponing. The IPsec VPN vs ZTNA decision framework can help you evaluate the protocol-level trade-offs, and our SASE architecture guide explains how the components fit together. If you want to see how Jimber handles the SonicWall replacement specifically, book a demo and we will map a migration path for your environment.