Back in May 2025, we wrote about Fortinet’s SSL VPN deprecation and what it meant for organisations running FortiGate infrastructure. The message was clear: SSL VPN tunnel mode was disappearing in FortiOS 7.6.3, and teams needed to migrate before the FortiOS 7.0 End of Life deadline in September.
That deadline passed four months ago. Most teams completed their IPsec migrations. The immediate crisis is over.
But here’s the question worth asking now that the dust has settled: did you solve the problem, or just meet the deadline?
After completing your Fortinet IPsec migration
- Evaluate ongoing operational friction with IPsec management
- Assess whether network-level access still fits your security posture
- Identify applications ready for identity-based access
- Plan a phased transition from VPN to ZTNA
- Consolidate remote access and web security in a single platform
The migration is done. The architecture problem remains.
SSL VPN had real security issues. The accumulated vulnerabilities made deprecation necessary. Moving to IPsec closed those specific holes. That was the right call given the timeline.
What IPsec didn’t change is the fundamental access model. Users authenticate, get network access, and then reach resources based on firewall rules. The perimeter moved from SSL to IPsec, but it’s still a perimeter. Once inside, lateral movement paths remain open.
For organisations that treated the migration as a checkbox exercise, this matters. The acute risk from SSL VPN vulnerabilities is gone. The structural risk from network-level access architecture continues.
What IPsec fixed and what it didn’t
| Security aspect | SSL VPN | IPsec VPN | ZTNA |
|---|---|---|---|
| Protocol vulnerabilities | High risk | Lower risk | Minimal attack surface |
| TCP-over-TCP performance | Problematic | Improved | Not applicable |
| Network-level access | Yes | Yes | No (app-level) |
| Lateral movement exposure | High | High | Eliminated |
| Device posture verification | Optional | Optional | Built-in |
| Per-session authentication | No | No | Yes |
The first two rows improved. The rest stayed the same. IPsec was a protocol upgrade, not an architecture upgrade.
The operational friction nobody budgeted for
Migration planning focused on the technical cutover. What teams are experiencing now is the ongoing management overhead that comes with IPsec at scale.
FortiClient endpoint management requires configuration profiles pushed to every device. When something changes, that’s a fleet-wide update. BYOD scenarios complicate this further.
SAML integration works, but reconfiguration when identity providers change or when adding new applications means touching FortiGate config. For multi-site deployments, that’s multiple appliances.
Mobile network issues persist. Carrier-grade NAT interferes with standard IPsec. The TCP 443 fallback helps, but reintroduces some of the overhead that made SSL VPN slow in the first place.
Multi-site means multi-configuration. Each FortiGate maintains its own IPsec settings. Policy consistency across locations requires careful synchronisation or management tools that add their own complexity.
None of this is catastrophic. Teams are managing. But “managing” isn’t the same as “thriving.” The support tickets keep coming. The configuration drift keeps happening. The operational overhead keeps consuming time that could go elsewhere.
From VPN survivor to Zero Trust adopter
The migration was forced by a deadline. The next step is strategic.
With the immediate pressure gone, there’s space to ask bigger questions. Does network-level VPN access still make sense for your organisation? Is the ongoing management overhead sustainable? What would it take to move toward identity-based access?
Zero Trust Network Access represents a different model entirely. Instead of granting network access and relying on downstream controls, ZTNA validates identity, device posture, and application access for every session. No broad network exposure. No lateral movement paths. No implicit trust after initial authentication.
The shift doesn’t have to happen overnight. ZTNA can run alongside existing IPsec infrastructure. Migrate user groups incrementally. Start with applications that work over HTTPS. Keep IPsec for specific legacy requirements. Reduce reliance as confidence builds.
A practical path forward
| Phase | Focus | Outcome |
|---|---|---|
| Assessment | Identify high-volume, low-risk applications | Migration candidates ranked |
| Pilot | Deploy ZTNA for IT staff accessing internal tools | Operational validation |
| Expansion | Migrate department by department | Reduced VPN load |
| Optimisation | Consolidate policies in single console | Simplified management |
| Completion | IPsec retained only for specific legacy needs | Architecture modernised |
The timeline depends on your environment. Some organisations complete this in a quarter. Others take longer. The point is that each phase delivers value independently. You don’t need to commit to everything upfront.
What mid-market teams gain from the shift
For IT managers stretched thin
The IPsec migration added configuration work. ZTNA removes it. Identity-based policies replace per-appliance rules. Changes propagate from a central console instead of requiring FortiGate-by-FortiGate updates.
Device posture verification happens automatically. Instead of chasing endpoint compliance through separate tools, posture checks integrate with access decisions. Non-compliant devices get restricted access without manual intervention.
For MSPs managing multiple clients
Every customer migration multiplied the IPsec configuration work. Multi-tenant ZTNA platforms consolidate that into a single management interface. Policy templates apply across customers. Onboarding follows repeatable processes instead of custom configurations.
Margin predictability improves too. Per-user pricing replaces the bandwidth-based surprises common with other platforms. Support load decreases when access issues resolve through policy rather than troubleshooting individual tunnels.
How Jimber fits into this picture
Jimber provides identity-based ZTNA built on WireGuard, offering performance advantages over both SSL VPN and traditional IPsec. The platform runs alongside existing infrastructure during transition, so there’s no forced cutover.
Native SSO integration with Microsoft, Google, and standard identity providers eliminates separate token management. Multi-tenant architecture gives MSPs unified visibility across their customer base. Transparent pricing means no surprises as usage scales.
For organisations dealing with restrictive network environments, stealth mode tunnels WireGuard over HTTPS. Connections remain functional where traditional VPN protocols face blocking.
| Capability | Post-migration IPsec | Jimber ZTNA |
|---|---|---|
| Access model | Network-level | Application-level |
| Policy management | Per-appliance | Centralised |
| Device posture | Optional add-on | Integrated |
| Multi-tenant | Limited | Native |
| Protocol | IPsec (UDP/TCP 443) | WireGuard + stealth |
| Transition approach | N/A | Incremental alongside existing |
The goal isn’t to replace everything immediately. It’s to provide a path that makes operational sense while improving security posture over time.
Frequently asked questions
We just finished our IPsec migration. Why consider changing again?
The IPsec migration solved the immediate deadline. It didn’t address the underlying architecture. Network-level access, lateral movement exposure, and per-appliance management remain. ZTNA addresses these while reducing operational overhead.
Can ZTNA run alongside our existing Fortinet infrastructure?
Yes. Jimber deploys incrementally. Migrate user groups and applications at your own pace while maintaining IPsec for specific needs. No forced cutover required.
What’s the business case for moving beyond IPsec?
Reduced management overhead, improved security posture through application-level access, integrated device posture verification, and simplified multi-site or multi-tenant operations. The ROI comes from operational efficiency as much as security improvement.
How long does a ZTNA transition typically take?
Pilot deployments can happen in weeks. Full transitions depend on environment complexity. Most mid-market organisations complete the shift within a quarter to two quarters, moving incrementally.
What about organisations still running older FortiOS versions?
If you’re still on pre-7.6 firmware, you’re running software past its support date. The security risk increases daily. ZTNA offers a path forward that doesn’t require upgrading through the IPsec migration first. You can move directly to identity-based access.
Does this work in countries where VPNs face restrictions?
Jimber’s stealth mode tunnels traffic over HTTPS, making it indistinguishable from regular web traffic. This maintains connectivity in restrictive environments across China, Turkey, Egypt, and similar locations where traditional VPN protocols are blocked or throttled.
Ready to turn your VPN migration into a Zero Trust foundation? Book a demo and see what comes after IPsec.
