mTLS

In ordinary TLS the server proves who it is and the client stays anonymous at the transport layer. The browser checks the server’s certificate against a trusted authority and against the hostname, and whatever authenticates the user happens afterwards, inside the encrypted channel, usually with a password or a token.

mTLS adds the other direction. During the handshake the server asks the client for a certificate, the client presents one and signs with the corresponding private key, and the server verifies it against the authorities it trusts. Both ends now have a cryptographic identity established before any application data is exchanged.

The property that makes it valuable between services is that the identity is bound to a key rather than to a shared secret. A bearer token or an API key is valid for whoever holds it, so it can be copied out of a configuration file, a log, an environment variable or a repository, and reused anywhere. A private key that never leaves the workload cannot be replayed by presenting a captured value, which removes a whole category of credential theft.

In practice it is deployed as infrastructure rather than in application code. A service mesh, an ingress layer or a sidecar handles issuance, rotation and verification, and workloads receive short-lived certificates automatically. That automation is what makes it feasible: the reason mTLS had a reputation for being painful is that manual certificate management at scale genuinely is.

The failure we find most often is mTLS terminated at the edge and forgotten behind it. A load balancer or gateway verifies the client certificate, then forwards the request over plain HTTP to a back end that accepts anything reaching it. From inside the network, which is where an attacker is by the time this matters, the strong authentication is not in the path at all.

The second is the trust store. A server that verifies certificates against a broad set of public authorities will accept a certificate issued by any of them, to anyone. Internal mutual authentication needs a private public key infrastructure, and the trusted set must contain only what should be able to call this service.

The third is verifying the certificate and not the identity in it. A configuration that checks the chain and stops there accepts every workload in the estate, because they all have valid certificates from the same internal authority. Authentication succeeded; authorisation was never asked. In a mesh with a hundred services this is the difference between an identity system and an expensive encryption layer.

The fourth is the forwarded identity header. Where the edge terminates mTLS and passes the client’s identity onward in a header, that header is a claim. If any component can reach the back end directly, it can set the header itself, and the entire chain collapses to whoever can make an internal request. We look for this specifically, and it pairs directly with SSRF, where a forged internal request is exactly what an attacker obtains.

Then there is revocation, which is where most deployments quietly rely on hope. Checking revocation adds latency and a dependency, so many configurations do not, and a compromised certificate stays valid until it expires. The practical answer is very short lifetimes rather than reliable revocation.

The comparison people ask for, and the answer is narrower than expected: mTLS changes who is authenticated, not how the encryption works.

The encryption is identical. What changes is that the server knows which workload is calling before it processes anything, which is what makes it a zero trust building block: identity replaces network position as the basis for the decision.

Terminating at the edge and trusting the interior. The internal hop is where an intruder is.

Trusting public certificate authorities for internal clients. Use a private authority with a tightly scoped trust store.

Verifying the chain and not the subject. Every workload in the mesh holds a valid certificate. Authorisation still has to check which one.

Long-lived client certificates. Without reliable revocation, lifetime is your only control. Hours or days, issued automatically, not years.

Trusting a forwarded identity header without restricting who can set it. If a back end accepts the header from anything that can reach it, the edge check is decorative.

Automate issuance and rotation before expanding coverage. A workload identity system that issues short-lived certificates on start-up removes the operational objection and removes the temptation to use long lifetimes. Manual certificate handling does not scale past a handful of services and produces outages that get blamed on mTLS.

Verify the subject, not just the chain, and write the allowed callers per service explicitly. That list is the actual access control policy, and putting it in configuration where it can be reviewed is more valuable than the certificates themselves.

Keep mTLS end to end where the traffic is sensitive, rather than terminating once. Where termination at an edge is unavoidable, restrict which components can reach the back end at all, so that a forged internal request cannot bypass the check.

Keep the trust store minimal and inventoried. Every authority you trust is a way in, and internal authorities accumulate through mergers, pilots and vendor appliances.

For detection, log the client identity from the certificate on every connection. That single field turns internal traffic from anonymous into attributable, which is worth more for investigation than the encryption is, and it lets you alert on a service calling a peer it has never called before.

In an API or cloud report, mTLS is examined as an authentication control and the findings are about what was verified rather than about whether it is enabled. We record where the connection terminates, which authorities are trusted, whether the subject is checked, whether identity is forwarded and who can set that header, and what the certificate lifetimes are.

The evidence is a request we made that was accepted, and the identity under which it was accepted. A finding here is usually demonstrated by calling a back end directly, from a position an attacker would plausibly hold, and showing that the edge control was not in the path.

Severity depends on what the unauthenticated path reaches. A back end that accepts unauthenticated internal requests but exposes nothing sensitive is a moderate finding. The same configuration on a service that returns customer data, in an estate where an SSRF exists, is a critical one, and we write the two findings together because separately neither reads as urgent.

Verifying that service-to-service authentication holds where it is claimed is part of testing an API and the services behind it.

What is the difference between TLS and mTLS? In TLS, only the server presents a certificate. In mTLS both sides do, so the server knows which client is calling before any application data is processed. The encryption is the same; the difference is who is authenticated.

Does mTLS replace API keys and tokens? For service-to-service authentication it can, and it is stronger because the credential is a private key rather than a value that can be copied from a log or a repository. Authorisation still has to be decided separately, from the identity the certificate establishes.

Is mTLS hard to operate? It is hard by hand and manageable when automated. A mesh or workload identity system that issues and rotates short-lived certificates removes most of the cost, and the failures that gave it a bad name were almost all expiry-related.

How do we revoke a client certificate? Revocation checking is often not implemented because of the latency and the dependency it adds. The practical approach is short lifetimes, so a compromised certificate expires in hours, plus the ability to remove the client from the service’s allowed list immediately.