Service mesh mTLS hides a process identity gap in zero trust

At a glance

What this is: This analysis argues that sidecar-based mTLS can create a process identity gap, because Envoy can proxy trusted traffic without proving which process inside the pod generated it.

Why it matters: It matters because IAM and platform teams may mistake encrypted service-to-service traffic for verified workload identity, leaving NHI governance blind to impersonation inside the pod boundary.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 72% of identity professionals find machine identities more challenging to manage than human identities, citing poor internal processes and insufficient tooling.

👉 Read Riptides' analysis of service mesh mTLS and process identity risk

Context

Service mesh mTLS secures the network path, but it does not automatically prove which process inside a pod originated the request. That distinction matters for workload identity, because the security boundary shifts from encrypted transport to the authenticity of the runtime actor.

Riptides frames the problem as a mismatch between network identity and process identity. In an environment built on service accounts, SPIFFE identities, and sidecar proxies, the central question is whether the platform is authorising the workload or merely trusting a proxy to speak for it.

For teams already using service meshes, this is a familiar NHI governance problem: cryptographic trust is real, but it can still be attached to the wrong execution boundary. The same issue appears in other workload identity designs, which is why resources such as the Guide to SPIFFE and SPIRE and the NHI Lifecycle Management Guide remain relevant.

Key questions

Q: What breaks when sidecar mTLS is treated as proof of workload identity?

A: The control fails because the proxy is authenticated instead of the application process. A co-located process can route traffic through the sidecar and inherit a valid certificate, so the target service sees trusted mTLS while the real actor remains unverified. That is a workload identity problem, not just a transport problem.

Q: Why do service meshes complicate workload identity governance?

A: They separate cryptographic trust from execution provenance. The mesh can verify a SPIFFE identity on the wire, but the identity may be attached to a proxy rather than the process that generated the request. This makes accountability harder and can let local compromise turn into trusted service abuse.

Q: How should security teams reduce proxy relay risk in Kubernetes pods?

A: Teams should treat local proxy access as part of the identity control plane and restrict which processes can reach it. They should also validate whether workload credentials are bound to the process, not just the pod, and use stronger attestation for services that carry meaningful privileges.

Q: Who is accountable when a valid mTLS session is abused by the wrong process?

A: Accountability sits with the team that defined the trust boundary too broadly. If the platform authorises a sidecar while assuming it proves process identity, the governance model is incomplete. Frameworks such as NIST Cybersecurity Framework 2.0 and NIST SP 800-207 both expect clearer trust boundaries than that.

Technical breakdown

Why sidecar mTLS is not process identity

Istio and similar meshes terminate and originate traffic through a sidecar proxy, usually Envoy, which holds the workload certificate and performs the mTLS handshake. That design authenticates the proxy endpoint, not the application process that asked the proxy to send traffic. If an attacker can run code inside the pod or exploit a local breakout, the attacker can often talk to the local proxy and reuse the pod’s legitimate identity. The result is a valid cryptographic session with the wrong runtime actor behind it. The mesh has verified that the sidecar is trusted, but not that the process is.

Practical implication: treat sidecar mTLS as transport protection, not proof of workload authenticity.

How SPIFFE identities are consumed by the proxy

SPIFFE-based identities give each workload a verifiable name, usually expressed as a URI such as a service account binding. In the sidecar model, istiod issues short-lived X.509 certificates to Envoy through SDS, and Envoy uses those credentials to establish trust with peers. This is strong on paper because identity is machine-readable and rotatable. The weakness appears when the identity is attached to the proxy boundary instead of the process boundary. A valid SPIFFE ID can still be relayed by an attacker-controlled process if local access to the proxy is possible. The identity is correct, but the actor behind it is not.

Practical implication: validate where the private key and handshake authority actually sit in the execution chain.

Why localhost access becomes an identity bypass

The article’s attack chain depends on a simple local fact: in many pods, any process that can reach the loopback listeners on 127.0.0.1:15001 or 15006 can make Envoy proxy traffic on its behalf. That means the control plane assumes the proxy is speaking for the intended application, but the kernel and container runtime are not enforcing that claim at the same time. Namespace sharing, shared volumes, and mixed privilege levels make this a boundary problem, not a certificate problem. Once local access exists, the attacker can turn trusted mTLS into a delivery channel for forged workload requests.

Practical implication: enforce process-bound identity controls where local proxy access is possible.

Threat narrative

Attacker objective: The attacker aims to impersonate a trusted workload so they can submit authorised-looking service requests without controlling the real application process.

1. Entry occurs when an attacker exploits the application or breaks out of a container into the pod namespace, gaining the ability to act locally within the workload boundary.
2. Escalation happens when the attacker discovers Envoy listeners on localhost and uses curl, netcat, or a custom client to send requests through the sidecar as if they came from the application.
3. Impact follows when the target service accepts the proxied mTLS session and treats the request as trusted workload traffic, enabling impersonation and unauthorized actions under a valid SPIFFE identity.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Process identity: the sidecar boundary is not the trust boundary. The article shows that mTLS can be technically correct while still being governance-complete failure if the wrong actor is authenticated. Network identity, pod identity, and process identity are not interchangeable, and treating them as if they were collapses the actual control model. The implication is that workload governance must start by naming the execution boundary that is truly being trusted.

Workload identity attached to a proxy creates identity relay risk. A proxy can hold the right certificate and still speak for the wrong process when local access is available. That is a specific NHI failure mode, not a generic encryption issue, and it matters because certificate validity can survive even when the runtime actor has changed. Practitioners should read this as an identity relay problem, where the credential is authentic but the speaker is not.

Cryptographic trust without process attestation produces false assurance. The design assumption is that a valid mTLS session proves the workload on the other end. That assumption holds for transport authenticity, but it fails when the proxy can be reused by any co-located process. The implication is that teams must stop equating successful handshake verification with verified workload provenance.

Process-bound identity is the named concept this breach pattern exposes. The article is really about a missing concept, not a missing setting: identity must bind to the actual process that emitted the request. When identity is only pod-bound or sidecar-bound, the trust model allows impersonation inside the node. The practitioner conclusion is that runtime identity evidence must be tied to the executing process, not the transport path.

OWASP-NHI and zero trust both apply, but at different layers. The mesh satisfies one layer of encrypted service communication, while OWASP-style NHI governance asks whether the credential, its issuer, and its runtime usage are all aligned. That separation is easy to miss in platform discussions. The implication is that service mesh adoption should not be mistaken for complete workload identity governance.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That governance gap is why the NHI Lifecycle Management Guide matters when proxy-bound identities can outlive their intended trust scope.

What this signals

Process-bound identity is becoming the differentiator in workload governance. The more teams rely on sidecars, service meshes, and short-lived certificates, the more they need a way to prove which process actually emitted the request. With 69% of organisations now having more machine identities than human ones, per The Critical Gaps in Machine Identity Management report, the scale problem is no longer theoretical.

Credential provenance will matter more than certificate freshness. A short-lived certificate can still be attached to the wrong execution boundary if the proxy is the trusted actor. Teams should expect more pressure to move from pod-centric trust models toward process-attested identity, especially where workloads carry lateral movement risk.

Process identity is the new perimeter. That concept captures the real shift here: security programmes that only validate encrypted transport will miss local impersonation paths inside the node. The practical programme response is to align platform engineering, IAM, and runtime security around the same execution boundary.

For practitioners

• Map the real trust boundary in each mesh deployment Document whether the platform authenticates the sidecar, the pod, or the actual process. Where the proxy is the only authenticated component, treat the workload identity as relayable rather than process-bound.
• Audit loopback exposure to local proxy listeners Check whether any process in a pod can reach 127.0.0.1 proxy ports such as 15001 and 15006. If yes, the local attack surface must be considered part of the identity perimeter, not just the network perimeter.
• Use process-attestation mechanisms for high-trust workloads Prefer designs that bind credentials or mTLS termination to the process itself, using kernel enforcement or attestation where available. The goal is to make the request origin provable before the proxy can speak on behalf of the workload.
• Review service-account scope alongside proxy trust Confirm that the service account mapped to the SPIFFE identity does not carry broader permissions than the runtime actor should have. Pair the identity check with least privilege, because a relayed credential becomes more damaging as its scope grows.

Key takeaways

• Sidecar mTLS can authenticate the proxy while leaving the actual workload unproven, which creates an impersonation path inside the pod.
• The issue is not broken encryption but a trust model that assumes the proxy and process are the same security subject.
• Teams need process-bound identity evidence and tighter local proxy controls if they want workload identity to match zero trust claims.

Key terms

• Process Identity: The identity of the actual running process that generated a request, not just the pod, container, or proxy carrying it. In workload security, process identity matters because transport-level authentication can succeed even when the wrong runtime actor is speaking through a shared boundary.
• Sidecar Proxy: A companion process injected into a pod to handle network functions such as routing, encryption, and policy enforcement. In service-mesh designs, the sidecar can become the authenticated speaker unless the platform also proves which process inside the pod controls it.
• SPIFFE Identity: A standardised workload identity expressed as a cryptographic identifier for services and other machine actors. It is valuable for machine trust, but it only provides the security outcome intended when the identity is attached to the correct execution boundary and lifecycle governance is in place.
• Workload Attestation: Evidence that a workload is running in the expected form before it is trusted with credentials or access. Attestation becomes critical when sidecars, shared namespaces, or local proxies could otherwise let an unauthorised process borrow a legitimate identity.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Riptides: The Hidden Risk in Service Mesh mTLS: When Your Sidecar Becomes a Trojan Horse. Read the original.