mTLS (mutual TLS)

mTLS (mutual TLS) is the TLS handshake mode where BOTH the client and the server present a certificate. The client proves its identity in addition to the server proving theirs. The server only completes the handshake if it trusts the client's cert.

In normal TLS, the server has a cert and the client doesn't. mTLS makes the client also present one.

Why use mTLS

• Machine-to-machine auth without API keys. Internal services can authenticate each other via cert instead of passing tokens.
• Strong client identity. No replay attacks; private key never leaves the client.
• Zero-trust networks. Used by Service Mesh setups (Istio, Linkerd) for east-west traffic between microservices.
• Enterprise customer requirements. Some regulated industries require mTLS for API access.

How clients enroll

You issue each authorized client a cert signed by your internal CA. The cert lives on the client (file on disk, hardware token, OS keychain). When the client connects to your service, it presents the cert; your server checks the signature against your CA's root.

The operational cost

• Certificate distribution. Every client needs a cert. Distribute, rotate, revoke.
• CA management. You either run an internal CA or use a service like AWS Private CA or Smallstep.
• Revocation. If a cert is compromised, you need to revoke it. CRLs and OCSP exist; both are awkward at scale.
• Client-side breakage. mTLS doesn't work in browsers without a UI prompt. So it's not great for human-facing web apps.

SaaS practical use

For your customer-facing API, mTLS is often overkill; API keys + HMAC are simpler and more familiar. mTLS shines for:

• Machine-to-machine API calls between your services.
• Webhook delivery where you need to prove your identity to the receiver.
• Enterprise customers who explicitly require it.