What are the security risks of VPN split tunnelling?
Split tunnelling routes some traffic through the VPN and sends the rest directly to the internet. This creates four risks: DNS leakage that exposes internal hostnames, malware delivery via the unprotected path, data exfiltration through direct internet connections, and compromised home networks bridging into corporate systems. Under NIS2, these blind spots violate Article 21 requirements for access control and risk management. ZTNA eliminates the dilemma entirely by replacing the tunnel with per-application, identity-based access.
Split tunnelling started as a performance fix. During the pandemic, VPN concentrators buckled under the weight of full-tunnel configurations, and Microsoft recommended routing Teams traffic around the tunnel to reduce latency. That advice made sense when the priority was keeping video calls running. It makes less sense now that NIS2 auditors are asking pointed questions about traffic visibility and access control.
The problem is straightforward. Every packet that bypasses your VPN also bypasses your security stack. No firewall inspection, no web gateway filtering, no DLP controls. For IT managers still running split tunnel configurations, the question is no longer whether this creates risk. It does. The question is whether you can defend that configuration during a NIS2 compliance checklist audit.
What is split tunnelling and why do IT teams use it?
Split tunnelling divides network traffic at the endpoint. Some packets travel through the encrypted VPN tunnel to the corporate gateway. The rest go directly to the internet via the user’s local connection.
There are three common configurations. Full tunnel sends everything through the VPN, giving the security team complete visibility but adding latency and straining bandwidth. Split tunnel (include-based) only routes traffic destined for specific corporate IP ranges through the VPN, while all other traffic goes direct. Inverse split tunnel (exclude-based) sends everything through the VPN except explicitly excluded destinations like Microsoft 365 or Zoom.
IT teams enable split tunnelling for practical reasons. Full tunnel configurations backhaul cloud-bound traffic through a central gateway, adding latency that kills video call quality and slows SaaS applications. When your Brussels-based employee needs to reach Microsoft 365 servers in Amsterdam, routing that traffic through a VPN concentrator in Antwerp first is wasteful. Split tunnelling fixes the performance issue.
The trade-off: you lose visibility over everything that goes direct.
The security risks IT teams underestimate
Split tunnelling creates a dual-homed endpoint. The device sits on both the corporate network (via VPN) and whatever local network the user connects from. That combination is the root of every risk below.
DNS leakage exposes your internal infrastructure
When split tunnelling is active, DNS queries for non-corporate destinations often resolve through the local network’s DNS server instead of the corporate resolver. This leaks internal hostnames and reveals the structure of your network to anyone monitoring that local DNS traffic.
A compromised home router can exploit this further through DNS hijacking, redirecting the user to a spoofed login page for corporate services. Because the request travels outside the VPN tunnel, none of your security controls see it. The user enters credentials on what looks like a legitimate page, and the attacker harvests them. Our DNS security in Zero Trust guide covers this attack vector in detail.
Malware enters through the unprotected path
A user browsing the web outside the tunnel downloads a malicious file. The corporate Secure Web Gateway never sees it because that traffic bypasses the VPN entirely. Once the malware executes, it has two options: exfiltrate data directly through the unprotected internet connection, or pivot through the active VPN tunnel into the corporate network.
The second scenario is the dangerous one. The VPN tunnel is authenticated and trusted. Malware riding that tunnel looks like legitimate internal traffic. Security teams monitoring the VPN concentrator see normal-looking connections from a trusted user, while the initial compromise happened entirely outside their view.
Data exfiltration via direct internet connections
Any application running outside the tunnel can send data directly to the internet without passing through DLP controls. A user copying sensitive files to a personal cloud storage account, a compromised browser extension uploading session tokens, a keylogger sending credentials to a command-and-control server, all of this happens invisibly when split tunnelling is active.
The legacy VPN risk report documents how lateral movement after initial VPN compromise has become the dominant attack pattern in Benelux ransomware incidents.
Compromised home networks become a bridge
VPN-connected devices on residential networks share that network with smart TVs, IoT devices, children’s gaming consoles, and other endpoints with minimal security. An attacker who compromises any device on the home network can potentially reach the VPN-connected work laptop.
With split tunnelling active, the attacker can use the work laptop as a bridge. Traffic from the compromised home network reaches the corporate environment through the authenticated VPN tunnel. The AZ Monica hospital ransomware incident in January 2026 illustrated how healthcare networks remain vulnerable when remote access architectures allow this kind of lateral bridging.
Where split tunnelling conflicts with NIS2
NIS2 Article 21(2) lists the minimum cybersecurity measures organisations must implement. Split tunnelling conflicts with at least four of these requirements.
Article 21(2)(a): risk analysis and information system security policies. You cannot perform adequate risk analysis on traffic you cannot see. Split tunnelling deliberately routes a portion of endpoint traffic outside your monitoring perimeter. An auditor will ask what percentage of your remote users’ traffic bypasses your security controls. If the answer is anything above zero, you need a documented justification.
Article 21(2)(e): security in network and information systems acquisition, development and maintenance. Running VPN infrastructure with known architectural weaknesses, when the vendor community has broadly acknowledged those weaknesses and offered alternatives, is difficult to defend as a proportionate measure. The SSL VPN deprecated across vendors timeline shows how rapidly the industry is moving away from legacy remote access.
Article 21(2)(g): basic cyber hygiene practices and cybersecurity training. NIS2 explicitly references Zero Trust principles as part of good cyber hygiene. Split tunnelling operates on implicit trust: once the tunnel is established, traffic routing decisions happen without continuous verification. That is the opposite of Zero Trust.
Article 21(2)(i): access control policies. VPNs typically grant subnet-level access after authentication. Split tunnelling adds another layer of weakness by allowing endpoints to maintain uncontrolled connections alongside that already-broad access. Auditors expect least-privilege enforcement, not architectural exceptions that widen the attack surface.
The ENISA Technical Implementation Guidance, published in June 2025 to support the Implementing Regulation (EU) 2024/2690, addresses remote access security directly. The guidance recommends that entities disable or restrict split tunnelling for remote access, on the basis that all traffic from external devices should pass through the organisation’s security controls. For entities in NIS2-regulated sectors, ignoring this guidance creates a direct compliance gap.
How CyFun levels address VPN configuration in Belgium
Belgium’s CyberFundamentals (CyFun) framework translates NIS2 into practical controls. The April 2026 deadline for submitting self-assessments to the CCB means VPN configurations are under scrutiny now.
At CyFun Basic level, organisations must demonstrate that remote access is authenticated and encrypted. Split tunnelling does not inherently violate this requirement, but the documentation burden increases because you need to justify why some traffic is excluded from encryption and inspection.
At CyFun Important and Essential levels, the requirements tighten. Access control measures must follow least-privilege principles, and network traffic must be monitored for anomalies. Split tunnelling undermines both: it grants broader access than necessary by allowing uncontrolled internet connections alongside corporate access, and it creates blind spots in traffic monitoring.
The CyFun Protect function controls (PR.AC-3, PR.AC-4) require documented evidence that access is limited to what each role needs. A VPN configuration that permits split tunnelling is harder to document as compliant because you are deliberately excluding traffic from your control framework. The CyFun self-assessment guide walks through what assessors expect.
Organisations pursuing CyFun verification will find that a consolidated security platform generates the evidence auditors need far more efficiently than a fragmented stack with VPN exceptions documented in spreadsheets.
How ZTNA eliminates the split tunnelling dilemma
The split tunnelling debate exists because of a VPN limitation: the tunnel is all-or-nothing at the network level, so you either route everything through it (slow) or exempt some traffic (risky). ZTNA removes the tunnel entirely, which makes the dilemma irrelevant.
With ZTNA, there is no tunnel to split. Users connect directly to the specific applications they are authorised to access, verified by identity and device posture on every request. Traffic to cloud applications like Microsoft 365 goes direct without a detour through a central gateway, but it still passes through a cloud-native Secure Web Gateway that inspects and enforces policy. You get the performance benefit of direct access and the security benefit of full visibility. No trade-off required.
Jimber’s ZTNA replaces the tunnel entirely. Users connect to the applications they need, verified by identity and device posture checks, without routing all traffic through a central gateway. There is no VPN concentrator listening on the public internet, so there is no target for port scanning or zero-day exploitation. Each application connection is individually authorised. Even if a device is compromised through a local network attack, the attacker cannot pivot to other systems because those systems are invisible and unreachable.
Jimber’s SWG inspects all web traffic regardless of the user’s location, closing the visibility gap that split tunnelling creates. Every access request is logged with user identity, device state, application target, and policy decision. That is precisely the audit trail NIS2 assessors expect, and it is generated automatically rather than assembled manually from multiple tools.
For IT managers running the VPN to ZTNA migration, the split tunnelling question disappears on day one of the pilot. The first applications published through ZTNA immediately benefit from granular access and full logging, while legacy VPN access can run in parallel until the migration is complete.
Frequently asked questions
Is split tunnelling ever acceptable under NIS2?
NIS2 does not explicitly ban split tunnelling by name. However, the ENISA Technical Implementation Guidance recommends disabling or restricting it, and the Article 21 requirements for access control, risk management, and traffic monitoring are difficult to satisfy when a portion of endpoint traffic is invisible to your security stack. If you maintain split tunnelling, expect to document a detailed risk assessment justifying the exception.
Does Microsoft still recommend split tunnelling for Teams?
Microsoft’s original split tunnelling guidance from 2020 was a response to VPN capacity constraints during the pandemic. The recommendation was specifically for Teams media traffic, which is already encrypted at the application layer. Microsoft has since introduced features like Global Secure Access that route traffic through cloud security controls without requiring traditional VPN split tunnelling. The pandemic-era workaround is no longer the only option.
How does ZTNA handle Microsoft 365 traffic differently than split tunnel VPN?
With split tunnel VPN, M365 traffic goes direct to Microsoft servers without any security inspection. With ZTNA and a cloud-native SWG, M365 traffic still goes direct (no backhaul through a central gateway), but it passes through policy enforcement that checks for data loss, malware, and compliance violations. Same performance, different security posture.
Can I disable split tunnelling without killing performance?
Not with a traditional VPN. Full tunnel configurations force all traffic through the concentrator, which adds latency and creates a bandwidth bottleneck. That is why ZTNA is the practical answer: it eliminates the need for a tunnel altogether, so there is no performance penalty to avoid. The IPsec VPN vs ZTNA comparison breaks down the performance differences.
What should I check first if I currently run split tunnelling?
Start with DNS configuration. Verify whether your split tunnel endpoints use corporate DNS or local resolvers. If DNS queries leak to local resolvers, your internal network structure is exposed. Then audit which applications are excluded from the tunnel and assess whether any of them handle sensitive data. Document these findings, because a CyFun assessor will ask for them.
How quickly can I migrate from split tunnel VPN to ZTNA?
A phased approach is typical. Publish two or three low-risk applications through ZTNA first, validate the user experience, then expand coverage application by application. Most mid-market organisations complete the migration within weeks, not months. VPN and ZTNA run in parallel during the transition, so there is no big-bang cutover.
Ready to close the split tunnelling gap before your CyFun deadline? Book a demo and see how Jimber replaces partial VPN protection with full-visibility ZTNA in a single cloud-managed platform.
