Use mutual TLS when the clients are known machines or partners and the API is high value, so you can issue and revoke client certificates. OWASP says client certificates should be considered for high-value applications or APIs, and notes they are rarely used in public systems because of administrative overhead.
What mutual TLS adds
In ordinary TLS, only the server proves who it is. In mutual TLS, the client also presents a certificate during the handshake, and the server checks it. You get a cryptographic identity for the caller before any request is read.
OWASP notes that in TLS 1.3 this proof is bound to the handshake transcript, which prevents relaying the authentication to another connection.
What it does not do
OWASP also states that mutual TLS does not provide confidentiality against a server whose certificate the client accepts, so the client must still validate the server's identity and trust configuration independently. It also says nothing about what the caller is allowed to do. You still need authorization on every request.
Decision table
| Situation | Mutual TLS fit |
|---|---|
| Service to service inside your own platform | Good, if certificate issuance is automated |
| A small number of partners calling a sensitive API | Good |
| A public API with millions of unknown clients | Poor, use tokens |
| Mobile or browser clients | Usually poor, key handling is hard for users |
| You want to bind tokens to a client | A fit, as an extra layer |
The real cost is operations
The cryptography is easy. The work is certificate lifecycle: issuing, distributing, renewing and revoking. If renewal is manual, an expired client certificate becomes an outage on a Friday night.
Questions to answer before you start:
- Who is the certificate authority for client certificates, and who guards its key?
- How is a certificate issued to a new client, and how fast?
- How are certificates renewed, automatically or by hand?
- How do you revoke one, and how quickly does the server notice?
- How do you map a certificate to an identity and to permissions?
- What do you log, and who reads it?
Rollout steps
- Start with one internal service pair and automate issuance.
- Enforce at the edge or a proxy first, so applications need no change.
- Run in an optional mode where the server logs missing certificates without rejecting them.
- Fix the logged gaps, then switch to required.
- Keep authorization checks in the application after the handshake.
- Practice a revocation drill.
Alternatives
Signed tokens, request signing with a shared secret and a MAC, and network level controls solve parts of the same problem with less certificate work. Mutual TLS works well together with them rather than replacing them.
Try it yourself
Open the API scan demo and see how authentication and authorization findings are reported for endpoints. Ask which of your findings a client certificate would address, and which it would not.
Click through it at your own pace, or open it full screen.
Safeguard can generate an SBOM and scan your dependencies, so outdated cryptography libraries with known advisories show up in one inventory, and policies can gate a build on them. A free scan is at gold.safeguard.sh/scan.
Quick check
Does mutual TLS replace API keys?
It can replace them for identifying a client, but you still decide what each client may do.
Is it safe to terminate mutual TLS at a proxy?
It can be, if the proxy passes the verified identity to the app over a trusted path that clients cannot spoof.
Sources
Last reviewed: 19 October 2026.
