mTLS

What it means

Mutual TLS, or mTLS, is TLS with proof in both directions. In an ordinary connection the browser checks the server's certificate. With mTLS the server also asks the client for a certificate and refuses the connection if it is missing or not trusted.

The result is that a service knows which machine or program is calling before any request is read. It is used mostly between services, in partner integrations and for devices, rather than for people at a keyboard. That makes it a good fit for machine-to-machine traffic, where nobody is there to type a password.

Why it matters

It lets you close a service to everyone except known callers, without relying on a secret that could be copied out of a log. A stolen password can be used from anywhere. A private key that never leaves the device is much harder to replay, which suits zero trust designs.

It is not a complete answer, because it proves a caller's identity, not what that caller may do. A trusted partner certificate that can read every customer's record is still a flaw. Authorisation has to be checked after the handshake, on every request.

How it shows up

You meet it between internal services, often handled by a service mesh, and in banking and partner APIs, where certificate-bound access tokens are defined in RFC 8705. The work is in running a certificate authority, issuing, renewing and revoking certificates, and not letting expiry take a service down.

Typical mistakes are trusting any certificate signed by a public authority rather than your own, skipping the check on the client name, never revoking a lost certificate, and terminating mTLS at a gateway that then forwards plain requests with a header saying who the caller was. Check that header cannot be set from outside.