They assume the tunnel also solves authorization, visibility, and offboarding. In practice, encryption protects traffic in transit, but it does not prove the actor should have access, limit what the actor can do inside the session, or remove every credential path when access ends.
Why This Matters for Security Teams
Encrypted tunnelling is often treated as a security boundary, but it only protects data in transit. It does not confirm that the connected actor is authorised, does not limit what happens after the tunnel is established, and does not help much when credentials remain valid long after access should have ended. The practical failure is trust inflation: once the tunnel is up, too many teams assume the session is safe.
That assumption is especially costly for non-human identities, where keys, tokens, service accounts, and API credentials can persist outside the tunnel and be reused elsewhere. NHI Management Group’s Ultimate Guide to NHIs notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, which means tunnel encryption does nothing to address the larger access path. The issue is not whether the traffic is encrypted. The issue is whether the access was valid, constrained, and revocable.
Security teams also get misled by “secure channel” language in VPN, proxy, and bastion designs. Current guidance from the OWASP Non-Human Identity Top 10 aligns with a simpler operational rule: protect transport, but enforce identity and privilege at the point of use. In practice, many teams discover this only after a tunnel account, API key, or service credential has already been reused for lateral movement.
How It Works in Practice
Encryption should be treated as one control in a layered access model, not the access model itself. Teams need to separate three questions: can traffic be intercepted, is the actor allowed to connect, and what can the actor do once connected. A tunnel answers the first question only. For modern environments, especially those involving service-to-service calls and autonomous workloads, access decisions need to happen at runtime with context, not just at session establishment.
That is why practices such as workload identity, policy-as-code, and just-in-time access are gaining traction. Workload identity gives the system a cryptographic proof of what the workload is, rather than assuming the tunnel endpoint is trustworthy. The SPIFFE overview is a useful reference point for this model. For authorisation, current guidance suggests evaluating requests against runtime context using policy engines and short-lived credentials rather than relying on a broad network permit once the tunnel is open.
- Issue short-lived secrets or tokens per task instead of long-lived tunnel credentials.
- Bind access to workload identity, not just source IP, network zone, or VPN membership.
- Apply least privilege inside the session with explicit service, method, and resource constraints.
- Log tool use, secret access, and privilege changes separately from tunnel establishment.
- Revoke access paths on completion, not just on disconnect, because cached tokens and secondary credentials can survive.
The operational lesson is consistent across environments: encryption is necessary, but it is not an authorisation system. NHI Management Group’s Key Challenges and Risks research highlights how hidden credentials and weak offboarding amplify exposure. These controls tend to break down in hybrid estates where legacy VPNs, shared service accounts, and unmanaged secrets coexist, because the tunnel becomes a convenient bypass for governance.
Common Variations and Edge Cases
Tighter tunnel-based access often increases operational overhead, so organisations must balance stronger control with ease of automation and incident response. That tradeoff is especially visible in regulated or legacy-heavy environments, where full replacement of network tunnels is not realistic in the short term.
One common edge case is the internal east-west tunnel used between services. Teams sometimes treat it as “trusted by default,” but that becomes a problem when a compromised workload can pivot through the tunnel and reach other systems. Another edge case is break-glass or vendor access, where encrypted connectivity is permitted but session scope is not tightly constrained. Best practice is evolving here, and there is no universal standard for this yet, but the direction is clear: session encryption should be paired with explicit entitlement checks, strong offboarding, and continuous monitoring.
This is also where 52 NHI Breaches Analysis becomes instructive. Many real incidents involve not tunnel failure, but credential persistence, over-privilege, and poor revocation discipline after the tunnel ends. For NHI-heavy systems, the right question is not whether the channel is encrypted. It is whether the actor still has a reason to exist in the environment at all.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Tunnel trust often hides over-privileged NHI access paths. |
| NIST CSF 2.0 | PR.AA-1 | Access should be verified at use, not assumed from network reachability. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust rejects implicit trust in network tunnels. |
Require identity-based access checks before and during each session, not just tunnel admission.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
