SSL VPN is deprecated: every vendor’s timeline and what replaces it

SSL VPN tunnel mode is being removed or deprecated across every major firewall vendor. If your remote access strategy still relies on it, the clock is ticking. Fortinet has already stripped SSL VPN from FortiOS 7.6.3, Cisco is retiring the ASA platforms that run it, SonicWall has deactivated its SMA 100 appliances, and Palo Alto Networks is phasing out legacy GlobalProtect SKUs. This is not a single vendor’s decision. It is an industry-wide admission that SSL VPN is fundamentally broken.

This guide maps out the deprecation timeline for each vendor, explains what is driving the change, and shows why a vendor-neutral SASE platform is the cleanest path forward for mid-market IT teams in Europe.

SSL VPN deprecation at a glance

1. Fortinet removed SSL VPN tunnel mode entirely from FortiOS 7.6.3. Existing configurations are not migrated on upgrade.
2. Cisco is ending support for multiple ASA 5500-X models that run SSL VPN, with the last deadline hitting August 2026.
3. SonicWall deactivated all SMA 100 series appliances on 31 October 2025 due to repeated vulnerability exploitation.
4. Palo Alto Networks ended sale of legacy GlobalProtect SKUs on 15 August 2025, replacing them with cloud-based licensing.
5. Check Point has not formally deprecated SSL VPN but is investing in cloud-delivered alternatives.
6. The common thread: every vendor now acknowledges that network-level tunnels on public-facing hardware cannot be secured.

Why vendors are killing SSL VPN now

VPN appliances that accept SSL connections on public-facing ports have become the single largest entry point for ransomware. According to Coalition’s 2025 Cyber Claims Report, perimeter appliances such as VPNs and firewalls accounted for 58% of ransomware claims. Compromised VPN credentials were the initial access vector in 48% of ransomware attacks during Q3 2025, according to Beazley’s research. The Verizon 2025 DBIR found that exploitation of edge and VPN device vulnerabilities jumped to 22% of all exploit-based breaches, an eightfold increase year-on-year.

The pattern is consistent. Attackers are not breaking through complex defences. They are walking in through VPN portals using stolen credentials or exploiting known vulnerabilities in appliances that take weeks to patch. Groups like Akira, Black Basta and Qilin have built automated toolkits specifically designed to brute-force SSL VPN gateways from Fortinet, Cisco and SonicWall.

For vendors, this creates a liability problem. For IT teams, it creates an operational one. Every unpatched VPN appliance is an open door, and the window between vulnerability disclosure and active exploitation has shrunk to hours.

Vendor-by-vendor deprecation timeline

The table below shows where each major vendor stands today. Use it to check whether your current hardware and software is still supported, and when you need to act.

Every vendor in this table is pushing customers toward their own cloud-delivered replacement, often at significantly higher cost and with new licensing models that lock you deeper into their ecosystem. There is a better option, which we will cover after looking at each vendor’s situation.

Fortinet: the most disruptive change

Fortinet’s move has caught many mid-market teams off guard. Starting with FortiOS 7.6.3, SSL VPN tunnel mode is completely gone. Not deprecated with a warning. Gone. If you upgrade a FortiGate to 7.6.3 without migrating your SSL VPN configuration first, your remote access setup simply stops working. Existing settings are not carried over.

Fortinet’s short-term migration path is IPsec VPN using TCP port 443, which maintains compatibility with networks that block traditional IPsec traffic on UDP. The web-only mode (now called “Agentless VPN”) still functions for browser-based access. But neither of these options addresses the root problem. IPsec VPN still requires a publicly reachable gateway, still grants network-level access, and still depends on patching hardware appliances before attackers exploit the next vulnerability.

For IT managers running FortiGate appliances across multiple locations, the practical impact is significant. Every device needs its configuration converted before any firmware upgrade. Fortinet provides a FortiConverter tool and CLI-based migration guides, but the process is manual and requires thorough testing.

If you are still on FortiOS 7.4.x, you have a window until May 2026 when engineering support ends. Rather than spending that time migrating to IPsec only to face the same architectural problem, use it to plan a move to Zero Trust Network Access that eliminates the public-facing gateway entirely.

Cisco: hardware reaching its limits

Cisco’s SSL VPN deprecation is less about a single firmware change and more about ageing hardware. The ArcaneDoor campaign in 2024 and 2025 demonstrated that state-sponsored attackers could modify the firmware of older ASA appliances, maintaining persistence even across reboots. The root cause was that these older models lack Secure Boot and hardware-based integrity verification.

Cisco has already ended support for the ASA 5512-X through 5555-X models. The 5506-X, 5508-X and 5516-X series reach end of support on 31 August 2026. For organisations still running these appliances, the risk is not theoretical. Cisco’s own security advisories in September 2025 documented critical vulnerabilities in the ASA VPN web service that allowed unauthenticated remote code execution.

Replacing an end-of-life ASA with another generation of Cisco hardware just restarts the same cycle. You buy new appliances, configure SSL VPN or IPsec, expose a gateway to the internet, and wait for the next CVE. Organisations using this forced hardware refresh as an opportunity to move to a cloud-managed SASE platform break that pattern permanently.

SonicWall: forced deactivation

SonicWall took the most aggressive approach. Rather than simply ending support, SonicWall actively deactivated all SMA 100 series appliances on 31 October 2025. After that date, the devices stopped functioning entirely.

The reason was straightforward: repeated exploitation of critical vulnerabilities in the SMA 100 line. CISA advisories confirmed that attackers, including the Akira ransomware group, were actively targeting these devices. SonicWall determined that the risk of leaving them operational outweighed the disruption of forcing migration.

The Gen 6 and 6.5 firewall series (NSA, TZ lines) also approach end of support in April 2026, which affects organisations using SSL VPN on those platforms. For teams that already lost their SMA 100 access, the priority now is a permanent replacement that does not depend on another generation of hardware appliances.

Palo Alto Networks: licensing shift to the cloud

Palo Alto’s approach is more commercial than technical. GlobalProtect itself continues to function as an agent, but the legacy GlobalProtect SKUs tied to on-premises NGFW were retired on 15 August 2025. New and renewing customers now purchase cloud-based licensing. GlobalProtect App versions 6.0 and 6.1 reached end of life on 31 December 2025.

The signal from Palo Alto is clear: the future of remote access is cloud-delivered, not firewall-hosted. For mid-market teams, Palo Alto’s cloud offerings come with enterprise-tier pricing and complexity that often does not match the budget or team size of a 50-400 user organisation.

Check Point: no formal deprecation, but a clear direction

Check Point has not formally deprecated its Remote Access VPN or Mobile Access blades. Both remain available in current Quantum firmware releases. However, Check Point’s development investment has shifted visibly toward cloud-delivered access since acquiring Perimeter 81 in 2023.

For IT managers on Check Point, there is no forced migration today. But the writing is on the wall. The question is not if you will need to move, but when, and whether you want to move to another vendor-locked alternative or to a platform you choose on your own terms.

The problem with “just use our SASE”

Every vendor in this list is deprecating SSL VPN while simultaneously selling their own cloud replacement at a higher price point. This creates a convenient upgrade path for the vendor, but not necessarily for you.

Three problems come with staying in your current vendor’s ecosystem.

Pricing opacity.
Enterprise SASE platforms from the major firewall vendors are typically priced per bandwidth tier, per user, with add-on modules for web security, SD-WAN and advanced threat protection. What starts as a simple remote access replacement quickly becomes a complex commercial negotiation. For mid-market teams, this means either overpaying for capabilities you do not need or underbuying and hitting limits.

Implementation complexity.
Vendor SASE offerings are often designed for large enterprise deployments. Long onboarding projects, complex policy engines, and the assumption that you have a dedicated security team to manage it. A 50-400 user organisation with a three-person IT team needs something they can deploy in days, not months.

Deeper lock-in.
Moving from a vendor’s VPN to the same vendor’s SASE ties you more tightly into their licensing and renewal cycles. If pricing changes or the product direction shifts, you face the same forced migration problem all over again.

The deprecation of SSL VPN is a rare opportunity to step back and choose your access architecture independently of your firewall vendor.

What actually replaces SSL VPN

The replacement for SSL VPN is not a different flavour of tunnel. It is an architectural shift. Instead of exposing a gateway to the internet and granting network-level access after authentication, Zero Trust Network Access hides your infrastructure entirely and grants access per application, per user, per device.

This is what that looks like in practice with Jimber’s SASE platform.

No public-facing gateway.
Unlike SSL VPN or IPsec, Jimber’s ZTNA architecture makes your internal infrastructure invisible to the internet. There are no ports to scan, no gateway to exploit, no CVE to race against. The attack surface that made SSL VPN a ransomware entry point simply does not exist.

Per-application access, not network access.
Users connect to specific applications, not to a network segment. A finance team member reaches the invoice portal and nothing else. An engineer accesses the production monitoring dashboard without being able to reach HR systems. This is least-privilege access by default, not by complex firewall rule management.

Device posture verification.
Before any connection is established, the device is checked for OS version, encryption status and security configuration. Non-compliant devices are denied access until they meet the baseline. This closes the BYOD and unmanaged device gap that VPNs left wide open.

Coverage for agentless devices.
Printers, IoT sensors and industrial equipment cannot run a VPN client or a ZTNA agent. Jimber’s NIAC hardware provides inline isolation for these devices, placing them behind controlled access points that enforce policy without requiring software on the device. This creates a secure bridge between IT and OT environments without disrupting production.

Central web security.
With Secure Web Gateway and Firewall-as-a-Service built into the same platform, web filtering, threat protection and policy enforcement apply consistently to every user, whether they are in the office, at home or on the road. No separate tool, no separate console.

One console for everything.
Access policies, web security, SD-WAN connectivity, device posture and logging all live in a single cloud-managed interface. For an IT team managing multiple sites, this means fewer consoles, fewer configuration errors and faster troubleshooting.

Why Jimber fits the post-VPN moment

The vendors deprecating SSL VPN built those products in the first place. They designed the same perimeter architecture that is now failing. Jimber did not start with a firewall and bolt on cloud access later. The platform was built from the ground up around Zero Trust and isolation, not detection.

For mid-market IT teams in Europe, three things matter most in this transition.

Speed.
You do not have months for a migration project. Firmware deadlines and end-of-support dates are already here. Jimber deploys in days, not months, because there is no hardware to install at every site and no complex policy engine to configure from scratch.

Simplicity.
A three-person IT team cannot manage a platform designed for a 50-person security operations centre. Jimber’s single console and straightforward policy model mean your team spends time operating, not integrating.

Transparent pricing.
No bandwidth tiers, no hidden add-ons, no surprise invoices at renewal. Jimber’s pricing is predictable, which matters when you are replacing a VPN that came bundled with your firewall contract. For MSPs and partners managing multiple customers, the multi-tenant architecture and clear margin structure make it commercially viable to offer managed SASE without absorbing hidden costs.

A practical migration path from any vendor

Regardless of which firewall vendor you are currently using, the migration steps follow the same pattern.

Week 1: Inventory and prioritise. Map your users, devices and applications. Identify the highest-risk applications currently accessed via SSL VPN. This becomes your pilot group.

Week 2: Deploy ZTNA for pilot applications. Publish 2-3 applications through Jimber’s ZTNA. Configure identity integration with your existing directory service. Set device posture baselines for managed devices. Test access from both corporate and personal devices.

Week 3: Expand and validate. Add more applications based on your priority list. Deploy NIAC hardware for any agentless devices. Enable Secure Web Gateway with your acceptable use policy. Validate logging and SIEM integration.

Week 4 onward: Disable VPN access for migrated applications. As each application is successfully published through ZTNA, remove it from your VPN configuration. Once all applications are covered, decommission the VPN entirely. Update documentation for NIS2 evidence.

This timeline assumes a mid-market organisation with 50-400 users and a small IT team. Larger or more complex environments may need additional weeks, but the phased approach means users experience minimal disruption and you always have a fallback.

NIS2 and the compliance angle

The timing of SSL VPN deprecation coincides with NIS2 enforcement deadlines across Europe. NIS2 Article 21 requires organisations to implement proportionate technical measures for access control, incident containment and risk management. Running a legacy SSL VPN appliance with known architectural weaknesses is increasingly difficult to justify as a “proportionate” measure when the vendor itself has deprecated it.

For Belgian organisations classified as essential or important entities, the verification deadlines in 2026 add urgency. Demonstrating that your remote access infrastructure follows least-privilege principles, logs all access decisions and limits lateral movement becomes much simpler with Jimber’s ZTNA-based architecture than with a patched-together VPN setup. One console, one audit trail, one policy model.

FAQ

Is SSL VPN completely dead across all vendors?

Not yet, but the direction is unmistakable. Fortinet has removed it from current firmware. Cisco and SonicWall have ended support for the hardware that runs it. Palo Alto has retired the legacy licensing. Planning as if SSL VPN has a limited remaining lifespan is the safest approach.

Can I just switch from SSL VPN to IPsec VPN and stay on my current hardware?

For Fortinet, yes, IPsec on TCP 443 is the documented migration path. But IPsec VPN still grants network-level access and still requires a publicly reachable gateway. It solves the immediate compatibility problem without addressing the architectural weakness that led vendors to deprecate SSL VPN in the first place.

How does SSL VPN deprecation affect NIS2 compliance?

NIS2 requires proportionate access controls and demonstrable risk management. Running deprecated software on end-of-life hardware is hard to defend during an audit. ZTNA provides per-application access, device posture verification and centralised logging that directly supports NIS2 evidence requirements.

What about devices that cannot run a VPN or ZTNA agent?

Printers, IoT sensors and industrial equipment need inline isolation hardware, such as Jimber’s NIAC appliances, that places these devices behind controlled access points enforcing policy without requiring an agent. This closes one of the biggest gaps that VPNs never addressed.

Is a phased migration realistic for a team of 3-5 IT staff?

Yes. Start with your highest-risk application and one user group. Publish that application through ZTNA, validate access and performance, then expand. Jimber’s single cloud-managed console keeps the operational overhead manageable for small teams.

Do I have to migrate to my firewall vendor’s SASE platform?

No. The deprecation of SSL VPN means your current remote access approach is ending, not that you owe the same vendor another multi-year contract. A vendor-neutral platform like Jimber gives you a clean break from the cycle of buying hardware, patching it, then replacing it when the next generation is deprecated.

Your VPN contract is expiring. Your firmware needs upgrading. Act now.

SSL VPN deprecation is not a future event. It is happening now, across Fortinet, Cisco, SonicWall and Palo Alto. If your next firewall renewal or firmware upgrade is on the calendar, your remote access architecture should be on the agenda too.

Book a demo and see how Jimber replaces legacy VPN access with Zero Trust in a single cloud-managed platform.