A security questionnaire asks whether data is encrypted in transit and the team answers yes because the load balancer serves TLS 1.3. What happens if an attacker gets code execution on one host behind that load balancer, and what has the TLS answer actually bought?

What is being tested

Whether you can say where the ciphertext stops. TLS termination is a location, not a property. Everything on the client side of that point is encrypted; everything past it is plaintext on a wire somebody owns. The questionnaire answer is true and nearly useless on its own, because it describes one hop out of four.

What the attacker can do, minute by minute

The load balancer decrypts the request and forwards it. If the hop to the application is plain HTTP, then an attacker with code execution on that host, or on the node hosting it, can read full request bodies and full request headers for every request that machine handles.

The headers matter more than the bodies. Session cookies and bearer tokens travel in headers, and a token is replayable against every service that accepts it. Within minutes the attacker holds live credentials for the accounts whose traffic happened to land on that host, and the revocation window is the token lifetime unless you have a revocation list in the request path. A request body is one customer's data; a token is that customer's whole session.

What bounds it is narrower than people fear. In a managed cloud network, reading another host's traffic normally requires either that host or a traffic-mirroring permission, so the blast radius is the traffic this host handles, not the fleet. That is the honest answer: one host's share of requests, for as long as the foothold lasts.

What the TLS answer did buy

A real thing. TLS 1.3 at the edge gives confidentiality and integrity over the open internet, where the path is genuinely hostile, and it authenticates the server so the client knows it reached you. The handshake is one round trip, and resumption makes it effectively free, which is why there is no excuse for not having it. It buys nothing about the internal hop, nothing about data at rest, and nothing about an authenticated client behaving badly.

When mTLS everywhere is the wrong answer

The reflex fix is a service mesh with mutual TLS between every pair of services. For twelve services in one account with no multi-tenant compute, that is a new control plane, a certificate lifecycle and a fresh class of outage, bought to close a hop you can close more cheaply:

• Re-encrypt from the load balancer to the backend with ordinary TLS. One listener setting and a server certificate. This closes the wire without a mesh and is the move almost everyone should make first.
• Stop putting bearer tokens where they get logged, since the plaintext hop is only one of several places they leak.

Mutual TLS earns its cost when you need the caller's identity for an authorisation decision, not when you only need the bytes encrypted. If your answer to "who called this service?" is a header the caller sets, you need mTLS or signed workload identity. If it is "we do not authorise service-to-service calls at all", a mesh will not fix that.