Per-application tunnelling is a VPN or secure access mode that routes traffic for chosen applications through a tunnel while other applications use the normal network path. It is commonly enforced by client policy or process-based rules, and it narrows which data and sessions are carried inside the protected channel.
How Per-Application Tunneling Works
Per-application tunneling changes the unit of control from the whole device to selected processes or apps. That makes it useful when organisations want protected access for private resources without forcing every network request through the same tunnel. The security value comes from narrower routing scope, but the trade-off is that policy must reliably distinguish which traffic belongs inside and outside the protected path.
In practice, the control is usually enforced by client software, endpoint policy, or a secure access broker. That means the design depends on accurate application identification, stable process matching, and a clear rule set for which destinations are eligible for tunneling. When those rules are weak, traffic can leak around the tunnel or be routed inconsistently across sessions.
Why Organisations Use It
Per-application tunneling is often chosen to reduce unnecessary backhaul, improve user experience, and limit blast radius compared with full-tunnel VPN designs. It is especially relevant when only a subset of apps needs access to internal services, private SaaS, or segmented environments. The model supports least-access networking by sending only the chosen traffic through the protected channel.
It also helps with migration. Many organisations use it as a step toward zero trust network access, because it can replace broad network reachability with per-resource access decisions. The same pattern can reduce dependence on legacy VPN behaviour, where a connected endpoint may inherit more access than the user or app actually needs.
For a broader zero trust framing, see the ZTNA Guide, which covers per-application policy, identity-based access, and VPN migration.
Security Characteristics and Limitations
The main security advantage is scope reduction. If only one app is authorised to use the tunnel, compromise of an unrelated app does not automatically grant the same protected routing path. That improves segmentation, but it does not make the endpoint inherently trusted. A compromised device can still misuse the allowed app, intercept local traffic, or abuse whatever trust the client policy grants.
Per-application tunneling also shifts trust to the endpoint policy engine. If application matching is based on process names, local rules, or client-side enforcement, attackers may try to tamper with the process, piggyback on an allowed binary, or exploit gaps between user intent and actual routing behaviour. Security therefore depends on both network policy and endpoint integrity.
In zero trust architectures, this pattern fits the principle of limiting access to the smallest practical set of applications and destinations. NIST SP 800-207 is a useful reference for the broader access model, while policy enforcement details should be validated against the actual secure access platform in use.
Operational Checks Before Deployment
Before enabling per-application tunneling, organisations should verify which applications truly need protected access and how the client will identify them. The same app may behave differently across operating systems, browser wrappers, helper processes, and remote desktop tools, so the policy must be tested in the real endpoint environment rather than assumed from documentation.
Network teams should also confirm that DNS resolution, split-routing, and proxy behaviour are consistent with the intended design. If the tunnel carries only selected flows, visibility into what is inside and outside the tunnel becomes important for troubleshooting, policy review, and incident investigation. This is where logging and endpoint telemetry matter as much as the routing rule itself.
Because the control narrows exposure rather than replacing authentication or authorisation, it should be paired with strong identity checks, device posture review, and least-privilege access rules. Application-level routing is most effective when it is part of a broader zero trust pattern, not treated as a stand-alone security boundary.
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 CSF 2.0, 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 Zero Trust (SP 800-207) | Zero Trust Architecture | Per-application tunneling is a concrete zero trust access pattern. |
| Recommendation — Map app-specific access paths to ZTA principles and enforce least-privilege routing per resource. | ||
| NIST CSF 2.0 | PR.AA-05 — Asset Management, Access and Identity Governance | Per-app tunneling depends on governing which applications and sessions may use protected access. |
| PR.DS-01 — Data-at-Rest is Protected | Selective tunneling protects the confidentiality of traffic carried inside the protected channel. | |
| Recommendation — Define and enforce which applications are allowed to use protected network paths. Classify traffic that must traverse protected paths and keep sensitive flows within them. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The control narrows access paths and supports least-privilege network access. |
| Recommendation — Restrict application access paths so only approved traffic can reach internal resources. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Per-application tunneling is an information-flow control that routes selected traffic differently. |
| Recommendation — Enforce flow rules that send only authorised application traffic through the tunnel. | ||
Related resources from NHI Mgmt Group
- What breaks when session policy is global instead of per application?
- Why do application-level SBOMs matter more than per-component lists?
- How do organisations decide whether to invest first in an AI gateway or in per-application controls?
- What is the difference between perimeter security and access per application in Zero Trust?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org