A device-specific overlay route sends only traffic for selected hosts through the private network, while a full-tunnel VPN redirects most or all traffic through the tunnel. The first preserves normal internet routing and narrows scope. The second centralises traffic handling and can simplify remote access, but it also expands what traverses the trusted path.
How the Traffic Path Differs
The core difference is scope. A device-specific overlay route sends only selected destinations through the private path, so the device keeps using normal internet routing for everything else. A full-tunnel VPN sends most or all traffic through the tunnel, which makes the VPN the default path for browsing, application traffic, and often DNS resolution.
That routing choice changes more than convenience. Selective routing narrows what the private network must carry and usually reduces the blast radius if the tunnel or gateway has a problem. Full-tunnel routing centralises traffic handling, which can make policy enforcement and inspection easier, but it also makes the tunnel a critical dependency for general connectivity.
In practice, the question is not simply “more secure or less secure.” It is whether you want the VPN to protect only the private resources that need it, or whether you want it to become the primary transit path for most traffic. That decision affects latency, failure behaviour, troubleshooting, and how much trust you place in the VPN path.
What Changes for Security and Operations
Device-specific overlay routes are often used when only a narrow set of internal services must be reachable, such as admin portals, private APIs, or segmented application networks. Because only matching traffic traverses the overlay, external traffic keeps its normal path and the operator can avoid turning the VPN into a single point of failure for all internet access.
Full-tunnel VPNs are often chosen when the organisation wants a stronger central control point for inspection, logging, egress policy, or remote access simplicity. The trade-off is that the tunnel now carries far more traffic, so authentication, routing stability, and tunnel health become more operationally significant. If the tunnel degrades, the user may lose not just private access but everyday connectivity as well.
For teams comparing the two, the practical difference is policy surface. A selective route usually creates a smaller and more explicit trust boundary. A full tunnel increases the amount of traffic that falls under that boundary, which can help with policy consistency but also raises concentration risk if the gateway, profile, or route design is flawed.
When to Use Each Model
Use a device-specific overlay route when access needs are limited, the private network should not carry unrelated traffic, and preserving local internet performance matters. This is a good fit when only a subset of hosts or services are intended to be private and the rest of the device should behave normally.
Use a full-tunnel VPN when the environment needs broader traffic control, more predictable enforcement, or a simpler remote-access model for users who should operate as if they are inside the corporate boundary. It is also useful when policy requires that most traffic, not just private-destination traffic, be handled through centrally managed controls.
The wrong choice usually shows up as either overreach or undercoverage. Overreach means a tunnel is taking on more traffic than the business actually needs, which increases dependency and user friction. Undercoverage means sensitive traffic bypasses the private path when the organisation expected it to be protected or governed.
Risk and Threat Considerations
The main risk difference is exposure scope. A full-tunnel design gives the VPN gateway more influence over traffic flow, so compromise or misconfiguration can affect a much larger share of the device’s communications. A device-specific route limits that exposure, but only if the route list is accurate and the split is maintained consistently.
Failure mechanism: Route mistakes, DNS leakage, stale policy, or tunnel failures can send traffic down the wrong path, either exposing sensitive destinations outside the private path or blocking legitimate access when the tunnel becomes unavailable.
Impact: Organisations can get false confidence from the tunnel design itself, when the real control strength depends on route accuracy, authentication quality, and how much of the user’s traffic is actually dependent on the VPN.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), 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 Zero Trust (SP 800-207) | GV.OC-01 — Cybersecurity and Enterprise Risk Management | Route scope changes the trust boundary and enterprise access model. |
| PR.AA-05 — Least Privilege Access to Resources | Selective routing implements narrower access than a full-tunnel design. | |
| Recommendation — Define which traffic must traverse the trusted path and limit trust to that scope. Limit tunnel access to only the destinations that require private reachability. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Both VPN models are boundary controls that change traffic flow across trust boundaries. |
| AC-4 — Information Flow Enforcement | The difference is fundamentally about which traffic flows are permitted through the tunnel. | |
| Recommendation — Enforce controlled network boundaries and verify routing follows intended policy. Apply flow controls to restrict which destinations may use the private path. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | VPN route design and gateway handling are network infrastructure control decisions. |
| Recommendation — Manage tunnel routes and gateway settings as part of hardened network operations. | ||
Practitioner Guidance
What to verify: Confirm which destinations are meant to traverse the tunnel, then test DNS, fallback routing, and failure behaviour rather than assuming the profile matches the intended design. If a user can reach sensitive services outside the tunnel, the model is not doing what the policy says.
Decision rule: If the business need is narrow private access, prefer selective routing and keep the tunnel scope as small as practical. If the business need is centralised inspection or broad remote-access policy, accept the operational dependency of a full tunnel and treat gateway reliability as a user-critical control.
Practitioner takeaway: The real choice is between narrower trust scope and broader policy centralisation, so judge the design by failure mode, not by labels like “more secure” or “more convenient.”
Related resources from NHI Mgmt Group
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between zero trust for users and zero trust for NHIs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
