Split tunnelling is a VPN configuration where only selected traffic goes through the corporate tunnel while other traffic uses the user’s local internet connection. That can improve performance, but it also removes consistent monitoring and policy control, which increases exposure to interception, unapproved access, and weaker enforcement of security controls.
Expanded Definition
Split tunnelling is a VPN design choice, not a single product feature. It tells the client which traffic should enter the corporate tunnel and which traffic should go directly to the public internet, usually based on destination, application, or route rules.
The boundary matters because “VPN connected” does not always mean “all traffic is protected by the VPN.” In a split-tunnel model, enterprise policy typically applies only to routed traffic, while local internet-bound traffic follows the user’s normal network path. That can reduce latency and congestion, but it also creates two trust paths inside one session.
Definitions vary in practice because some teams use the phrase only for route-based split tunnelling, while others include application split tunnelling or per-destination exclusions. The common misunderstanding is assuming the VPN client itself provides full-path visibility or inspection once it is connected.
For a standards-oriented view of the surrounding control area, NIST SP 800-53 Rev 5 Security and Privacy Controls helps frame the access control, audit, and configuration-management expectations that split tunnelling can weaken if it is not governed carefully.
Examples and Use Cases
- A remote employee sends SaaS or video-conference traffic directly to the internet while internal application traffic still traverses the VPN.
- A mobile device uses split tunnelling so only traffic for corporate subnets goes through the tunnel, avoiding unnecessary routing for public browsing.
- An organisation excludes large software updates or backups from the VPN to preserve bandwidth for business applications.
- A contractor accesses internal file shares through the tunnel, but their personal cloud and email traffic remains outside corporate monitoring.
- A security team allows limited split tunnelling for a business justification, then narrows the bypassed destinations to reduce the exposed surface.
The trade-off is operational, not just technical: the more traffic bypasses the tunnel, the less consistent the organisation’s logging, filtering, and policy enforcement becomes. That can be acceptable for clearly scoped use cases, but it should be a deliberate exception rather than a default assumption.
Security Implications
Split tunnelling can create blind spots because corporate controls no longer see every packet from the endpoint. If DNS, web, or application traffic escapes the tunnel, the organisation may lose the chance to inspect it with the same filtering, proxying, or detection logic used for internal traffic.
That exposure can also weaken the trust boundary around the device. A host on an untrusted local network may talk to corporate systems through the VPN while also maintaining separate direct paths to external services, increasing the chances of credential interception, traffic manipulation, or policy bypass.
Another practical consequence is inconsistent enforcement. Endpoint posture checks, web controls, and data-loss controls may apply to some sessions but not others, which makes investigation harder and can leave teams with incomplete logs during an incident. The result is often not a single catastrophic failure, but a smaller and harder-to-see accumulation of exposure.
For practitioners, the key signal is whether the organisation can still answer basic questions, such as what was accessed, what was inspected, and what was bypassed, when split tunnelling is enabled.
Security, Operational and Governance Implications
Split tunnelling sits at the intersection of performance, user experience, and security governance. The control decision is really about which traffic paths deserve corporate trust and which traffic paths can tolerate reduced inspection and reduced control.
That means ownership matters. Networking, endpoint, and security teams need a shared policy for route exclusions, because an “optimization” set by one group can quietly become a standing exception that changes the organisation’s threat posture. Once exemptions spread, they are difficult to audit and even harder to justify consistently.
A well-governed split-tunnel policy usually depends on a clear standard for what may bypass the tunnel, what must remain inside it, and how exceptions are reviewed. Without that discipline, split tunnelling becomes a convenience feature that gradually erodes visibility and creates uneven control coverage across user populations.
In mature environments, the question is not whether split tunnelling is always good or bad, but whether the organisation can prove that the performance benefit is worth the governance cost in each approved case.
Risk and Threat Considerations
Split tunnelling introduces exposure because it creates simultaneous trusted and untrusted communication paths on the same endpoint. That raises the chance that sensitive traffic, policy decisions, or user activity will bypass enterprise inspection while the VPN is still considered “connected.”
Failure mechanism: An attacker or hostile network can target the non-tunnel path, for example by manipulating local DNS, intercepting direct internet traffic, or using the bypassed channel to reach resources that would otherwise be filtered or logged. The core weakness is inconsistent visibility and control.
Impact: Organisations can lose enforcement consistency, miss suspicious activity in logs, and expose users to interception or policy bypass. In a compromise, responders may also struggle to reconstruct what happened because part of the session was never governed by the corporate tunnel.
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 SP 800-53 Rev 5 and CIS Controls v8 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 which traffic remains under corporate access control and monitoring. |
| DE.CM — Continuous Monitoring | Bypassed traffic reduces visibility and can create monitoring gaps across the remote session. | |
| GV.PO — Policy | Split tunnelling is a policy decision about permitted network paths and exception handling. | |
| Recommendation — Define which traffic must stay inside the tunnel and enforce route-based access boundaries. Monitor tunnel exclusions and verify that bypassed traffic does not hide security events. Document when split tunnelling is allowed and review exceptions on a defined cadence. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Split tunnelling affects how information flows are constrained between corporate and public paths. |
| AU-2 — Audit Events | Traffic bypassing the tunnel can reduce audit coverage unless events are explicitly captured. | |
| CM-2 — Baseline Configuration | Split tunnelling is a configuration baseline choice that must be controlled and reviewed. | |
| Recommendation — Enforce approved information-flow rules for traffic that may bypass the VPN. Log tunnel decisions and exception traffic so investigators can reconstruct session activity. Standardise approved tunnel-exclusion settings and prevent ad hoc client configuration drift. | ||
| CIS Controls v8 | 6 — Access Control Management | Split tunnelling changes remote-access enforcement and should be governed as an access-control exception. |
| 8 — Audit Log Management | Split tunnelling can hide traffic from central logging unless remote access telemetry is retained. | |
| Recommendation — Restrict split tunnelling to approved cases and remove unnecessary bypass paths. Collect remote-access logs that show which traffic used the tunnel and which did not. | ||
Practitioner Guidance
Governance implication: Treat split tunnelling as an exception policy with ownership, approval, and review, not as a default remote-access posture. The real question is which traffic paths you are willing to leave outside corporate control and why.
What to watch for: Unclear route-exclusion rules, broad destination allowlists, and users who need direct internet access for routine business workflows. Those are the conditions where split tunnelling tends to expand beyond its original purpose.
Practitioner takeaway: If you cannot explain which traffic is inspected, logged, and policy-enforced under split tunnelling, the control is too permissive for reliable governance.
Related resources from NHI Mgmt Group
- How should security teams split identity governance from implementation work?
- How should organisations split responsibilities between IGA and PAM?
- What breaks when privileged access is split across multiple tools and platforms?
- What breaks when identity governance is split across vaults, IGA, and PAM tools?
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
