A common example of VPN Split Tunneling is a remote user sending corporate traffic through the VPN while direct internet browsing uses the local connection. This reduces backhaul load, but it can expose the device to concurrent trust zones and data leakage. Teams should define allowed traffic, assess endpoint risk, and watch for bridge paths between networks.
What split tunneling looks like in a real remote-work setup
In practice, split tunneling means a remote employee’s VPN carries only the traffic that needs corporate routing, while ordinary web traffic exits through the local internet connection. That setup is common for SaaS access, internal apps, and administrative tools when the organisation wants to reduce VPN congestion without forcing every packet through the tunnel.
The difference from full tunneling is not just performance. Split tunneling creates two simultaneous paths from the same endpoint, so the device can interact with both the corporate network and external services at once. That is why the design choice matters even when the user experience feels invisible.
A useful way to picture it is policy-based routing: the VPN client or gateway decides which destinations stay inside the tunnel and which stay outside. VPN Security Guide covers the wider VPN design choices around split tunnelling, hardening, and replacement options, which is often where teams start when they need to define what should and should not traverse the tunnel.
Why the same example can be safe, or unsafe, depending on policy
Split tunneling is usually chosen for bandwidth, latency, and user productivity reasons, especially when business traffic is relatively small and internet browsing is not sensitive to corporate routing. The control is only defensible when the organisation can clearly separate trusted corporate destinations from general internet access and can explain why the split does not create an unacceptable bridge between them.
The practical boundary is endpoint trust. If a laptop can reach internal resources through the VPN while also visiting untrusted sites directly, the device becomes a junction point between two trust zones. That is why teams often pair split tunneling with device posture checks, DNS control, and route restrictions rather than treating it as a pure network-performance setting.
For remote-access programmes, the bigger question is whether the access model still enforces least privilege and strong entry controls even when traffic is split. Remote Access Identity Guide is useful here because it frames VPNs alongside MFA, device posture, ZTNA, and dormant-account reduction, which are the controls that keep a convenient remote-access design from becoming a broad trust shortcut.
What usually goes wrong with split tunneling
The main failure mode is bridge-path creation. A browser session, downloaded file, or compromised endpoint can move between the public internet side and the corporate side if the device is over-permissive, poorly monitored, or allowed to talk to internal resources that it does not truly need. That does not require a dramatic exploit, only an environment where dual connectivity is left too open.
Another common problem is credential and session exposure at the edge. If the VPN user session is compromised, the attacker may inherit the same mixed-network position the user had, which makes lateral movement or internal discovery easier than it would be on a fully isolated device. SonicWall SSL VPN account compromises 2025 is a reminder that valid access on a remote-access edge can be enough to create serious downstream reach, even before a second-stage exploit appears.
When teams want to understand the trust-boundary side of that risk, NIST SP 800-207 Zero Trust Architecture is the clearest external reference for the idea that network location should not be treated as an implicit trust grant. Split tunneling is a routing choice, but its security meaning depends on whether the rest of the environment still verifies, scopes, and limits access.
Risk and Threat Considerations
Split tunneling can reduce operational load, but it also creates concurrent trust zones on the same endpoint. If the device is infected, misconfigured, or carrying weak access controls, the tunnel can become a bridge from untrusted internet activity into internal resources, or a path for internal credentials and sessions to be exposed to a broader attack surface.
Failure mechanism: An attacker abuses the dual-path design by compromising the endpoint, stealing a VPN session, or exploiting a permissive route policy so the device can pivot between external and internal networks.
Impact: The result can be data leakage, internal reconnaissance, unauthorized access, or faster lateral movement than the organisation intended when it approved split tunneling.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Split tunneling is governed by route and traffic-flow restrictions. |
| IA-2 — Identification and Authentication (Organizational Users) | Remote VPN access depends on strong user authentication before traffic is split. | |
| IA-5 — Authenticator Management | VPN access risk rises when credentials or sessions are weakly managed or long-lived. | |
| Recommendation — Restrict which destinations may bypass the tunnel and which must stay protected. Require strong user authentication at VPN entry before granting remote access. Rotate and manage VPN authenticators and related credentials tightly. | ||
| NIST CSF 2.0 | PR.AA-05 — Network Segmentation | Split tunneling changes network boundaries and requires intentional segmentation. |
| Recommendation — Segment remote-access traffic so bypassed internet paths do not widen internal exposure. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Split tunneling must be evaluated against trust-by-location assumptions. |
| Recommendation — Verify each access request independently instead of trusting the endpoint network path. | ||
Practitioner Guidance
What to verify: Confirm which destinations are allowed outside the tunnel and whether any internal admin paths, identity services, or sensitive applications are accidentally reachable through the split. If the list cannot be explained in business terms, the policy is probably too broad.
Decision rule: Use split tunneling only when the business case is explicit, the endpoint posture is known, and the allowed traffic set is narrow enough that a compromised device does not become an open bridge between trust zones. If those conditions are not met, full tunneling or a tighter remote-access model is the safer default.
What practitioners underestimate: The routing policy is only one part of the control. The real question is whether the endpoint can safely hold two trust relationships at once without turning convenience into a hidden lateral-movement path.
Practitioner takeaway: Split tunneling is a routing optimisation, not a security feature by itself, so treat it as safe only when the allowed paths, endpoint trust, and monitoring all limit what a compromised device can reach.