When should organisations prioritise forced tunneling over split tunneling for remote users?

Why the traffic path matters more than the tunnel label

Forced tunneling is the right default when the organisation wants a single control point for remote-user traffic. It lets security teams inspect, log, filter, and apply policy to traffic before it reaches the internet, SaaS, or other external services. Split tunneling reduces latency and preserves local access, but it also creates two simultaneous trust paths that must be governed differently.

The practical decision is less about the VPN feature itself and more about whether the remote endpoint should be treated like an extension of the corporate network or a partially trusted device with independent internet access. That distinction becomes important when monitoring, content filtering, DLP, or egress control are part of the security model.

For broader remote-access policy design, NIST’s Cybersecurity Framework 2.0 and the control emphasis in CIS Controls v8 both support the idea that traffic control, logging, and access governance should follow the risk of the environment, not user convenience alone.

When forced tunneling is the better choice

Prioritise forced tunneling when the remote session can reach sensitive systems, regulated data, or security-sensitive applications. It is also the safer choice when your organisation needs consistent inspection of outbound traffic, centralized DNS or web filtering, or evidence that remote endpoints are not bypassing corporate controls by using local internet paths.

It is especially appropriate where compliance obligations, incident response visibility, or data loss prevention matter more than endpoint convenience. In those cases, letting some traffic exit locally can weaken the organisation’s ability to prove that user activity, downloads, and exfiltration paths are subject to the same controls as office-based access.

When organisations rely on managed remote devices, tunnel all non-local traffic through the security stack so that access, logging, and response decisions are applied uniformly. The operational logic is similar to zero trust thinking: do not assume the user location makes the traffic safe.

NHIMG’s Regulatory and Audit Perspectives section is useful here because the same governance pressure that drives tighter identity and access control also drives stronger routing control for sensitive remote work.

When split tunneling is acceptable, and what to verify first

Split tunneling is reasonable when users need reliable access to local printers, conferencing tools, home-network resources, or low-risk public services, and when the organisation has accepted that not all remote traffic needs corporate inspection. It can also reduce load on the VPN infrastructure and improve user experience for bandwidth-heavy applications.

The trade-off is that the organisation gives up some visibility and control over the non-tunneled path. That is usually acceptable only if the endpoint has strong device posture, the workload is low sensitivity, and the security team has explicit compensating controls such as endpoint protection, conditional access, and tightly scoped application access.

Before allowing split tunneling, verify that the device is managed, patched, and protected against local-network abuse. The main failure mode is not simply “internet traffic goes elsewhere”, but that a compromised endpoint can bridge corporate and local paths in ways that bypass inspection or make lateral movement easier.

For identity and access programmes that depend on strong operational discipline, NHIMG’s Lifecycle Processes for Managing NHIs is a good companion reference because it reinforces the same principle: access paths should be governed according to sensitivity and lifecycle risk, not treated as equally safe by default.

Risk and Threat Considerations

Split tunneling increases exposure when local and corporate traffic are allowed to coexist on the same endpoint. The risk is not theoretical: an attacker who compromises the device may gain a less-monitored route to corporate resources, while the local internet path can provide a way to bypass logging, filtering, or inspection controls.

Failure mechanism: The endpoint becomes a dual-homed trust bridge, so malicious code, stolen session state, or unauthorized traffic can move between local and corporate contexts without all flows passing through the same control plane.

Impact: Reduced visibility, weaker egress control, and a larger opportunity for data exfiltration or lateral movement, especially where remote users handle regulated data or connect to high-value internal services.

Practitioner Guidance

Decision rule: If the remote device can access sensitive applications, administrative interfaces, regulated data, or anything that would materially change incident response if exfiltrated, default to forced tunneling. If users genuinely need local-network access, treat split tunneling as an exception that needs a documented risk acceptance and compensating controls.

What to verify: Check whether your VPN, DNS, web filtering, and logging controls still see the traffic that matters most. If the answer is no, split tunneling is usually creating a governance gap rather than a user-experience improvement.

Practitioner takeaway: Choose forced tunneling whenever security teams need the remote user’s traffic to be observable, enforceable, and defensible; choose split tunneling only when local access is operationally necessary and the residual risk is consciously accepted.

Related resources from NHI Mgmt Group

• When should organisations prioritise e-KYC for foreign users over manual onboarding processes?
• When should organisations prioritise data sources over variables or remote state in Terraform?
• When should organisations prioritise least privilege over broad network connectivity for remote access?
• Should organisations prioritise reducing secret reuse over faster scanning?