Encrypted tunnels protect traffic by wrapping it in an encrypted connection between two endpoints, so outsiders cannot easily read or alter what passes through. Defenders need to monitor where tunnels terminate, who is allowed to use them and whether they hide unwanted outbound connections, data exfiltration or command-and-control traffic.
What an encrypted tunnel actually does
An encrypted tunnel is a protected channel between two endpoints. The sender wraps traffic in encryption before it enters the tunnel, and the receiving endpoint unwraps it after delivery. That keeps intermediaries from reading the payload, and it also lets the tunnel behave like a private path across an untrusted network without changing the application traffic inside it.
The important idea is that the tunnel protects confidentiality and, in many designs, integrity of the traffic in transit. It does not magically make the endpoints trustworthy. If one endpoint is compromised, the tunnel can still carry stolen data, malicious commands, or altered traffic from a trusted location.
In practice, the tunnel is only as strong as its endpoint authentication, key handling, and routing policy. If those controls are weak, the encryption can still hide traffic from network observers while giving an attacker a reliable covert channel.
How tunnels are established and controlled
Most encrypted tunnels begin with the endpoints proving who they are and agreeing on session keys. After that, each packet or frame is encapsulated, sent through the tunnel, and decrypted at the far end. That setup is what makes the tunnel useful for remote access, site-to-site connectivity, and other traffic that must cross networks you do not fully trust.
Because the tunnel is an access path, control matters as much as cryptography. You need to know which systems are allowed to terminate tunnels, which identities or devices may initiate them, what destinations they may reach, and whether the tunnel is meant for a narrow application flow or broad network access. Those decisions determine whether the tunnel is a bounded transport mechanism or a general-purpose bypass around normal security controls.
That is why encrypted tunnels often need visibility at the termination point, not just at the network edge. A tunnel can conceal payload content from outside observers while still leaving useful metadata, session patterns, and destination behavior available to defenders who inspect the endpoint, gateway, or proxy.
Why encrypted tunnels are useful and where they become risky
Encrypted tunnels are useful because they reduce exposure on hostile or shared networks, especially when traffic crosses the internet or another untrusted transport. They are also attractive to defenders because they can protect credentials, business data, and internal administration traffic while preserving normal application behavior.
But the same properties create risk. A tunnel can hide unwanted outbound connections, data exfiltration, remote administration abuse, or command-and-control traffic if security teams treat all encrypted traffic as automatically benign. Once the tunnel is established, inspection is harder, attribution is weaker, and detection often shifts from payload inspection to endpoint behavior, flow analysis, and policy enforcement.
For operational security, the main failure mode is not the encryption itself, but the trust placed in the tunnel. If the organization allows overly broad tunnel use, weakly governed credentials, or unmanaged termination points, the tunnel can become a durable path for persistence and lateral movement.
Risk and Threat Considerations
Encrypted tunnels can create blind spots when organisations assume that encryption equals legitimacy. The traffic may be protected from outsiders, but it may still carry exfiltration, remote access, or command-and-control activity if the tunnel is permitted too broadly or monitored too weakly.
Failure mechanism: Attackers abuse trusted tunnel endpoints, weak access policy, or poor egress monitoring to conceal malicious traffic inside an otherwise approved encrypted channel.
Impact: Defenders may miss suspicious outbound connections, lose visibility into data movement, and allow an attacker to maintain a low-noise access path through the environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1095 — Non-Application Layer Protocol | Encrypted tunnels often carry covert command-and-control or exfiltration traffic over non-application protocols. |
| T1041 — Exfiltration Over C2 Channel | Tunnels can hide data theft inside an established command-and-control path. | |
| Recommendation — Monitor tunneled traffic for unusual destinations, durations, and beaconing patterns. Inspect egress channels for bulk transfer, staging, and destination anomalies. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Tunnel policy is an information-flow control problem, defining what traffic may traverse the channel. |
| IA-2 — Identification and Authentication (Organizational Users) | Tunnel initiation depends on strong endpoint and user authentication before trust is granted. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Tunnel abuse is often detected through logs, flows, and endpoint events rather than payload inspection. | |
| Recommendation — Enforce rules on which sources, destinations, and flows may use the tunnel. Require strong authentication before allowing tunnel establishment. Review tunnel logs and network telemetry for anomalous use and abuse. | ||
Practitioner Guidance
What to verify: Confirm where each tunnel terminates, what identities or devices can establish it, and whether its allowed destinations match the business need. A tunnel that reaches too much of the internal network is a control problem even if the encryption is strong.
What to measure: Track tunnel volume, destination changes, unusual session duration, and any encrypted egress that does not fit normal application or administrative patterns. The goal is to spot tunnel misuse by behavior when payload inspection is not enough.
Common mistake: Treating encrypted traffic as inherently safe. Strong encryption protects the channel, not the legitimacy of the source, the destination, or the action being taken through it.
Practitioner takeaway: The security question is less “is it encrypted?” and more “who can open the tunnel, what can it reach, and can we still see suspicious behavior once it is in use?”
Related resources from NHI Mgmt Group
- Guide: MITRE D3FEND Guide
- Why do SSH tunnels create security risk even when the traffic is encrypted?
- Why does network DLP lose effectiveness as work shifts to encrypted traffic, browser-based SaaS, remote devices, and AI assistants?
- Should organisations treat encrypted traffic as enough protection for hybrid work?
- How does Encrypted Traffic Analysis work?
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 October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org