Legacy VPNs have become the primary entry point for ransomware in the Benelux. Analysis of 2025 incident data shows that 70% of successful ransomware attacks originated from vulnerabilities in traditional VPN infrastructure. This is not a future risk. It is the current operational reality for organisations still relying on perimeter-based remote access.
This report presents the data behind that statistic, examines the architectural reasons legacy VPNs fail against modern threats, and outlines the transition path to Zero Trust Network Access. For IT leaders facing NIS2 compliance deadlines and board-level scrutiny, understanding this shift is no longer optional.
Key findings from 2025
- 70% of ransomware incidents traced to VPN vulnerabilities during peak months, according to Q3 2025 cyber insurance claims data.
- 47% year-over-year increase in disclosed VPN vulnerabilities across major vendors.
- 96% of ransomware attacks now include data exfiltration before encryption, making network-level access particularly damaging.
- Ransomware groups Akira and SafePay specifically targeted Benelux organisations through SSL VPN gateways.
- NIS2 CyberFundamentals verification deadline of 18 April 2026 creates compliance urgency for essential entities in Belgium.
Why VPNs became the preferred attack vector
The shift from phishing to edge device exploitation marks the most significant change in attack patterns over the past year. Ransomware operators discovered that compromising a VPN gateway delivers something phishing cannot: an authenticated tunnel directly into the network.
Once inside, the attacker inherits whatever access the legitimate user had. In most legacy VPN deployments, that means broad network-level access rather than specific application permissions. The attacker becomes a trusted insider within minutes.
Three factors accelerated this trend in 2025.
Internet-facing exposure. VPN concentrators must be publicly visible to accept connections. This makes them permanent targets for automated scanning and zero-day exploitation. Patching cycles for hardware appliances often lag weeks behind vulnerability disclosure.
Credential availability. Initial Access Brokers now sell pre-compromised VPN credentials at scale. Attackers using legitimate credentials bypass most detection systems because their traffic appears normal.
Lateral movement opportunity. Traditional VPNs provide network access, not application access. Once connected, attackers can scan, pivot, and deploy ransomware across any reachable system.
The Benelux incident record
The theoretical risk materialised into operational disruption across multiple sectors in 2025 and early 2026.
| Organisation | Date | Attack Vector | Impact |
|---|---|---|---|
| AZ Monica Hospital (BE) | January 2026 | Network infiltration / Ransomware | 70+ surgeries cancelled, 3-week recovery, estimated €3M+ cost |
| Ingram Micro (Global/Benelux) | July 2025 | SSL VPN exploitation / SafePay | Supply chain disruption, ordering systems offline, $136M daily revenue impact globally |
| Dutch Public Prosecution Service | July 2025 | Citrix NetScaler vulnerability | Case delays, systems taken offline |
| MySonicWall customers (NL) | October 2025 | SSL VPN credential theft | Network configuration files exfiltrated |
What happened at AZ Monica
On 13 January 2026, ransomware forced IT administrators at AZ Monica hospital in Antwerp to shut down all servers proactively. The attack cancelled at least 70 surgeries on the first day. Critical patients required transfer to other facilities. Systems reached only 70% capacity three weeks later.
Hospital environments often run flat networks to allow communication between medical devices. Initial access through an external connection, such as a maintenance VPN, can propagate across the entire ecosystem. The forensic investigation by CERT.be continues, but the pattern fits a classic network infiltration where perimeter security failed to contain lateral movement.
The supply chain effect at Ingram Micro
When SafePay compromised Ingram Micro in July 2025, the impact cascaded across thousands of IT resellers and MSPs in the Netherlands and Belgium. The attack exploited a vulnerability in the SSL VPN platform, using stolen credentials to access internal systems.
Online ordering platforms including Xvantage and Impulse went offline for days. This single breach through one VPN gateway created sector-wide disruption, demonstrating how centralised access points amplify blast radius.
Why legacy VPN architecture fails
The VPN was designed for a different era. When most employees worked from offices and applications lived in data centres, creating a tunnel to the corporate network made sense. That model does not survive contact with hybrid work, SaaS adoption, and sophisticated threat actors.
The implicit trust problem
Legacy VPNs authenticate once, then grant network access. After passing the initial credential check, users receive an IP address with access to the entire network segment. This creates a large blast radius from any single compromised credential.
Compare this to Zero Trust Network Access, which asks continuously: who is connecting, from what device, in what state, to which specific application, and should this access continue?
The performance tax
VPN architecture forces traffic through centralised gateways even when the destination is a cloud application. This hairpinning creates latency, consumes bandwidth at the concentrator, and frustrates users who then seek workarounds.
For mobile workers switching between 5G, Wi-Fi, and hotspots, legacy VPNs introduce reconnection delays of several seconds. Modern ZTNA implementations complete handshakes in approximately 100 milliseconds, maintaining seamless connectivity during network transitions.
The management burden
Every VPN appliance requires individual configuration, monitoring, and patching. In environments with multiple vendors and locations, this creates operational complexity that leads to configuration drift and missed security updates. A single management console that unifies policy across all access scenarios eliminates this fragmentation.
The architectural case for ZTNA
The protocols underlying most legacy VPNs, SSL and IPsec, carry decades of accumulated complexity. Modern ZTNA platforms take a fundamentally different approach to access security.
| Characteristic | Legacy VPN (SSL/IPsec) | Modern ZTNA Architecture |
|---|---|---|
| Access model | Network-level (broad, IP-based) | Application-level (granular, identity-based) |
| Trust basis | One-time authentication | Continuous verification |
| Internet visibility | Publicly exposed concentrator | Minimal attack surface, stealth capable |
| Lateral movement | Possible after initial breach | Structurally prevented through isolation |
| Protocol overhead | 15-20% typical | 4-5% with modern protocols |
| Reconnection time | 5-8 seconds | ~100 milliseconds |
| Management model | Per-appliance configuration | Centralised cloud policy |
The difference is not incremental improvement. ZTNA eliminates the architectural assumptions that make VPNs vulnerable. Even if credentials are compromised, access remains limited to specifically authorised applications rather than the entire network segment.
The Fortinet deprecation catalyst
Fortinet’s decision to remove SSL VPN tunnel mode in FortiOS 7.6.3 and later versions forces thousands of organisations to reconsider their remote access strategy. Companies that relied on the included FortiClient VPN now face a choice between purchasing additional licensing or migrating to a different architecture entirely.
This forced migration creates an opportunity to move directly to ZTNA rather than replacing one legacy VPN with another. The transition effort is similar, but the security outcome is substantially better.
NIS2 compliance and the April 2026 deadline
For Belgian organisations classified as essential entities, the timeline is concrete. By 18 April 2026, these organisations must demonstrate CyberFundamentals (CyFun) achievement at the Basic or Important level, verified by an accredited conformity assessment body.
| NIS2 / CyFun Milestone | Date | Requirement |
|---|---|---|
| Law entered into force | 18 October 2024 | Implementation period begins |
| CCB registration | 18 March 2025 | Mandatory entity status notification |
| CyFun verification | 18 April 2026 | Basic/Important level achievement |
| Full certification | 18 April 2027 | Essential level (100% resilience) |
The CyFun framework requires explicit definition and enforcement of access rights under control measure PR.AC-4. A VPN that provides broad network access without granular application-level control will likely result in a negative audit finding.
Beyond technical compliance, NIS2 introduces board-level accountability. Directors must complete regular cybersecurity training and can face temporary suspension for failing to implement appropriate measures after an incident. For mid-market organisations, fines of up to 2% of global annual turnover represent existential risk.
Adopting a SASE architecture that integrates ZTNA, Secure Web Gateway, and centralised policy management addresses approximately 90% of the technical requirements under NIS2 Article 21, significantly shortening the path to compliance.
Securing industrial environments
Manufacturing organisations face additional complexity where IT and OT networks converge. Smart factories using IIoT and AI-driven robotics create connectivity requirements that legacy VPNs handle poorly.
The common practice of providing external vendors with VPN access for PLC maintenance creates direct risk. Malware on a technician’s laptop can traverse the VPN tunnel directly to production systems. Because legacy OT equipment often cannot be patched without voiding warranties, these systems remain vulnerable to laterally spreading ransomware.
Network isolation hardware addresses this by providing brokered, time-limited vendor access to specific machines only. External partners can communicate with the equipment they need to service during a defined window while the rest of the factory environment remains invisible to them. This micro-segmentation approach satisfies Cyber Resilience Act requirements while maintaining operational continuity.
Planning the transition
Moving from legacy VPN to ZTNA does not require a disruptive migration. A phased approach reduces risk and allows teams to build confidence with the new architecture.
Phase 1: Assessment and inventory. Map all applications accessed via VPN, identify user groups and their actual access requirements, and document current device posture standards.
Phase 2: Pilot deployment. Publish 2-3 low-risk applications through ZTNA. Run parallel access during the pilot to validate user experience and policy configuration.
Phase 3: Expand coverage. Migrate business-critical applications, implement device posture checks, and integrate with existing identity providers.
Phase 4: VPN retirement. Disable VPN access for migrated applications, decommission legacy infrastructure, and update compliance documentation.
Phase 5: Continuous improvement. Add Secure Web Gateway controls, implement network isolation for agentless devices, and establish ongoing policy review cycles.
Throughout this process, single console management reduces the operational overhead of running parallel systems and provides unified logging for compliance evidence.
Metrics that matter
Track these indicators to validate progress and demonstrate improvement to auditors and leadership.
Before migration:
- Number of network segments accessible per VPN user
- Average time from vulnerability disclosure to patch deployment
- VPN-related support tickets per month
After migration:
- Applications accessible per user role (should decrease significantly)
- Device posture compliance rate
- Blocked lateral movement attempts
- Time to provision new user access
Organisations completing ZTNA migration typically report 60% reduction in security-related support overhead and measurable improvement in user satisfaction due to faster, more reliable connectivity.
FAQ
Does replacing VPN require replacing all network infrastructure?
No. ZTNA operates at the application layer and integrates with existing identity providers and network equipment. The migration is incremental, not forklift.
How does ZTNA handle devices that cannot run an agent?
Printers, IoT sensors, and industrial equipment require inline isolation rather than agent-based protection. NIAC hardware places these devices behind identity-aware access controls without requiring software installation on the device itself.
What about users who need access to multiple applications?
ZTNA policies can grant access to multiple specific applications based on role. The difference from VPN is that each application requires explicit authorisation rather than inheriting access from network position.
Is 70% really attributable to VPNs specifically?
The 70% figure reflects peak months in Q3 2025 based on cyber insurance claims data. The annual average across all remote access vectors including VPN and RDP was approximately 60%, still representing the majority of ransomware entry points.
How long does migration typically take?
For mid-market organisations with 50-400 users, initial pilot deployment takes 2-4 weeks. Full migration including VPN retirement typically completes within 3-6 months depending on application complexity and compliance requirements.
What compliance frameworks does ZTNA support?
The architecture directly supports NIS2, GDPR access minimisation requirements, DORA operational resilience standards, and sector-specific frameworks in healthcare and finance. Centralised logging and policy versioning provide audit evidence without additional tooling.
The path forward
The 70% statistic is not a prediction. It reflects what happened in 2025 to organisations that maintained legacy VPN infrastructure while threat actors evolved their techniques. The architectural limitations of perimeter-based access, implicit trust after authentication, broad network access, and internet-visible attack surface, cannot be patched away.
For Benelux organisations facing NIS2 deadlines, board-level accountability, and the operational reality of hybrid work, the transition to identity-based access is not a technology upgrade. It is a governance requirement.
Ready to assess your VPN exposure and plan the transition? Book a demo to see how a unified SASE platform makes the migration straightforward for your team.
