A Linux kernel networking mode that carries IPsec ESP traffic over TCP and relies on kernel handling of packet and fragment state. When that handling is flawed, the feature can become an unexpected attack surface for local code that can reach the right namespace and module path.
Expanded Definition
ESP-in-TCP is a Linux networking mode that encapsulates IPsec Encapsulating Security Payload traffic inside TCP. It is usually discussed as a transport workaround for environments where native IPsec encapsulation is blocked, fragile, or operationally awkward. In NHI and agentic systems, the important point is not the tunnelling trick itself but the trust boundary it creates around kernel packet handling, socket state, and namespace access.
Definitions vary across vendors and kernel discussions because ESP-in-TCP is a mechanism, not a policy control. It sits below IAM, but it can still expose the credentials, certificates, and service-to-service channels that NHIs depend on. For governance, it should be treated as a security-sensitive transport path rather than a generic networking convenience, especially when paired with privileged containers, host networking, or local code execution paths. For broader identity-risk context, the Ultimate Guide to NHIs shows how transport and credential handling failures compound one another, and the NIST Cybersecurity Framework 2.0 reinforces the need to manage protective technology as part of the wider risk posture.
The most common misapplication is treating ESP-in-TCP as a harmless plumbing choice, which occurs when operators enable it without reviewing who can reach the namespace, load the module, or influence packet state.
Examples and Use Cases
Implementing ESP-in-TCP rigorously often introduces extra kernel and operational complexity, requiring organisations to weigh connectivity resilience against a larger attack surface and more difficult troubleshooting.
- A cluster administrator enables ESP-in-TCP so IPsec traffic can traverse a network path that drops ESP directly, but later discovers that local namespace access matters as much as firewall policy.
- A service mesh or node-level agent uses the feature to keep encrypted east-west traffic stable, while relying on kernel state tracking that must be monitored alongside service account permissions.
- A container host runs privileged automation that can interact with the networking stack, making a kernel transport feature relevant to NHI risk because the code path is reachable by a workload identity.
- An incident responder reviews encrypted traffic failures and finds that the issue is not authentication itself, but packet or fragment handling inside the Linux networking layer.
- Operators compare this approach with native IPsec or overlay alternatives, using Ultimate Guide to NHIs guidance on visibility and rotation to decide whether the transport path justifies the added complexity.
In standards terms, transport selection should be reviewed alongside network trust assumptions in the NIST Cybersecurity Framework 2.0, while kernel-level deployment patterns should be validated against the local access model and the workload’s identity boundary.
Why It Matters in NHI Security
ESP-in-TCP matters because NHI security failures rarely stay confined to credentials alone. When service accounts, API keys, or agent tokens are already overexposed, a flawed transport path can become the bridge that turns local access into broader network reach. That is especially relevant in environments where the Linux kernel, namespaces, and privileged automation are all part of the same operational plane. NHIMG research shows that 79% of organisations have experienced secrets leaks, and 97% of NHIs carry excessive privileges, which means transport-layer flaws can quickly become identity-layer incidents.
Security teams should therefore assess who can invoke the feature, what modules or namespaces are exposed, and whether kernel handling is protected by least privilege, segmentation, and change control. The operational question is not whether encrypted transport is useful, but whether the implementation creates a reachable kernel surface for identities that should never have that level of influence. Organisationally, the issue usually becomes visible only after a privilege escalation, container breakout, or unexplained packet-handling failure, at which point ESP-in-TCP becomes operationally unavoidable to address.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Covers excessive privilege and attack surface around non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions and least privilege apply to workloads that can reach this kernel path. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires reducing implicit trust in network transport and internal paths. |
| OWASP Agentic AI Top 10 | A3 | Agentic workloads using network tools can amplify risk when transport paths are overtrusted. |
| NIST AI RMF | AI risk governance extends to infrastructure dependencies used by automated systems. |
Limit NHI reach into kernel and namespace paths, and review transport-related privileges regularly.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 21, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
