Split tunnelling creates risk because it sends some traffic through the VPN and the rest directly over the user’s local network. That removes visibility and control over what the device reaches outside the business boundary, weakens network-based detection, and can expose users to interception or credential capture. The issue is not VPNs themselves, but the loss of consistent inspection and policy enforcement.
Why Split Tunnelling Changes the Security Boundary
Split tunnelling matters because it creates two security paths on the same endpoint, one controlled by the organisation and one controlled by the local network the user happens to be on. That means the remote access session no longer gives the business a single, consistent enforcement point for inspection, policy, and monitoring. The practical result is a weaker trust boundary, especially on untrusted Wi-Fi or home networks.
With full-tunnel remote access, organisations can more reliably apply content inspection, DNS controls, logging, and egress policy. With split tunnelling, those controls may only see part of the device’s traffic, while other traffic can bypass them entirely. That is why split tunnelling is not just a routing preference, it changes what the organisation can observe and govern.
In practice, teams usually discover the weakness when an incident crosses from the corporate path into the local path and the control stack never sees the full sequence.
How It Works in Practice
In a split-tunnel setup, traffic destined for corporate resources is sent through the VPN, while traffic to the public internet uses the user’s normal network connection. That sounds efficient, but it introduces several operational gaps:
- Traffic inspection becomes partial, so web, DNS, and proxy controls may not apply to non-corporate destinations.
- Endpoint exposure increases, because the device can talk to local printers, peers, or hostile networks while still holding a corporate session.
- Detection quality drops, because the security team may only see one side of the device’s activity and cannot reconstruct the full path easily.
- User trust assumptions become inconsistent, since the same device is simultaneously inside and outside the managed boundary.
This model is especially risky when users work from shared environments, airport Wi-Fi, personal hotspots, or networks that can intercept DNS and web traffic. It also complicates conditional access decisions, because the VPN alone no longer proves that all traffic is subject to the same controls. If malware, phishing, or interception starts outside the tunnel, the organisation may still inherit the consequences once the user reconnects to internal apps. For a broader control lens on remote-access architecture, NIST SP 800-207 Zero Trust Architecture is useful because it emphasises continuous policy enforcement rather than trusting the network path.
These controls tend to break down when security teams rely on the VPN as the main inspection point but allow unmanaged networks and consumer-grade DNS paths to remain outside that policy boundary.
Common Variations and Edge Cases
Tighter remote-access controls often increase user friction and network load, so organisations have to balance security coverage against performance and usability. That tradeoff is real, but the answer is not always to disable split tunnelling everywhere.
Some environments use split tunnelling safely for low-risk traffic while forcing sensitive applications, DNS, or management channels through the VPN. Others keep full tunnelling only for high-risk users, privileged sessions, or regulated environments. The key is whether the organisation can still enforce the controls that matter most: inspection, routing discipline, device trust, and logging.
The risk becomes more pronounced when remote access is combined with weak endpoint posture, cached credentials, or users who move between home, hotel, and public networks. In those cases, split tunnelling can become a convenience feature that quietly expands the attack surface. If the security model depends on seeing traffic to make a decision, split tunnelling is usually the wrong default. For guidance on control layering and remote-access governance, NCSC UK Advice and Guidance is a useful reference point.
In practice, the hardest cases are not the fully managed corporate laptops, but the partially trusted devices used on unstable networks where policy visibility is already weakest.
Risk and Threat Considerations
Split tunnelling increases exposure because it creates a gap between what the organisation thinks it can control and what the device can actually reach. That gap can be exploited by interception on the local network, malicious Wi-Fi infrastructure, or malware that pivots through the non-VPN path to avoid security controls.
Failure mechanism: The attacker abuses the untunneled traffic path to capture credentials, redirect traffic, or observe sessions that never pass through corporate inspection tools. Because only part of the device’s activity is visible, the defender may miss the precursor traffic, the initial compromise, or the lateral path that follows.
Impact: The organisation loses consistent policy enforcement and detection coverage, which can lead to credential theft, session hijacking, data exposure, or an incomplete incident record. The result is a weaker remote-access boundary even when the VPN itself is correctly configured.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | Split tunnelling changes enforcement of access paths and trust boundaries. |
| Recommendation — Limit remote-access paths and enforce policy on every route a device can use. | ||
| NIST Zero Trust (SP 800-207) | JEA — Least-Privilege and Continuous Verification | Split tunnelling undermines continuous verification of traffic and trust. |
| Recommendation — Apply continuous policy enforcement instead of trusting the VPN path alone. | ||
| CIS Controls v8 | 6 — Access Control Management | Remote access should be restricted so unmanaged paths do not bypass control. |
| Recommendation — Restrict remote-access routes and review which traffic can bypass inspection. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Split tunnelling weakens information-flow control across managed boundaries. |
| AU-2 — Audit Events | Partial tunnelling reduces the audit trail for remote-access activity. | |
| Recommendation — Enforce information-flow restrictions so sensitive traffic stays under policy. Log remote-access events on all paths that can carry sensitive traffic. | ||
Practitioner Guidance
What to prioritise: Decide which traffic must always be inspected or controlled, then force that traffic through the VPN or another enforced path. Remote access should be designed around the most sensitive use cases first, not around convenience.
What to verify: Check whether DNS, web filtering, logging, and threat detection still apply when the device is off-tunnel. If they do not, treat the split as a material control gap rather than a benign optimisation.
Decision rule: If a user role handles sensitive data, privileged access, or regulated systems, default to full tunnelling or tightly scoped exceptions. If split tunnelling remains in place, document which destinations bypass inspection and why.
Practitioner takeaway: Split tunnelling is acceptable only when the organisation can tolerate the visibility loss it creates; if control depends on seeing the full traffic picture, the architecture is already too weak for that exception.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
