What is mutual TLS (mTLS), and how does it work?

What is mutual TLS?

In an ordinary handshake, the client stays anonymous at the TLS layer. It verifies the server's certificate, but the server has no idea who is connecting until the application itself asks for a password, an API key or a session cookie, after the encrypted connection is already up. Mutual TLS moves that identity check down into the handshake itself: the server asks the client for a certificate, the client presents one, and the server verifies it the same way a browser verifies a website's certificate, against a trusted certificate authority and a matching private-key signature.

Nothing about the encryption changes. The same key exchange, the same cipher suites, the same Finished check all still happen. mTLS only adds an extra identity check running in the other direction, so a connection can be rejected for a bad client certificate before either side has exchanged a single byte of application data.

How does a client certificate change the handshake?

In TLS 1.3 (RFC 8446), the server signals that it wants a client certificate with a CertificateRequest message, sent in Section 4.3.2 right after its own Certificate and CertificateVerify. That message carries a certificate_request_context, described in the RFC as "an opaque string which identifies the certificate request and which will be echoed in the client's Certificate message," plus extensions naming which signature algorithms and which certificate authorities the server will accept.

The client answers with its own Certificate message and its own CertificateVerify, a signature over the handshake transcript made with its private key, the same structure the server used to prove itself earlier. RFC 8446 Section 4.4.2 is explicit that both directions are optional at the protocol level: the Certificate message "is omitted by the server if not authenticating with a certificate and by the client if the server did not send CertificateRequest." One detail is different from TLS 1.2: in TLS 1.3 this entire exchange happens after the ServerHello, inside the already-encrypted part of the handshake, so a client's certificate never travels in plain text the way it did in TLS 1.2, where CertificateRequest and the client's Certificate were both sent before encryption started.

If the client either sends no certificate when one was required, or sends one the server does not trust, the server ends the handshake. No application-layer request ever gets a chance to run.

Where is mTLS actually used?

• Service-to-service traffic inside a data center or a service mesh. When every call is between services the organization itself controls, both ends can hold a certificate issued by an internal certificate authority, and mTLS becomes the access control layer between them, not just the encryption layer.
• IoT device fleets. A device with a certificate burned in at manufacturing time can authenticate to a backend without ever handling a username or password, which matters for hardware that has no keyboard and no user sitting in front of it to log in.
• Some banking and payment APIs. Open banking style integrations, where a third-party application calls a bank's API on a customer's behalf, commonly require the calling application to present its own certificate as part of proving it is the registered, approved integration and not an impostor holding a stolen API key.
• Zero Trust internal networks. Where the security model assumes no network segment is automatically trusted, mTLS lets every internal connection carry its own proof of identity instead of relying on network location (being "inside the firewall") as a stand-in for trust.

What does mTLS cost to operate?

The handshake cost itself is small, one extra certificate and one extra signature verification. The operational cost is where mTLS gets expensive, and it is the reason it stays mostly in service-to-service and closed-fleet settings rather than showing up on public consumer-facing sites:

• Certificate distribution. Every client that needs to authenticate needs its own certificate and private key, issued by a certificate authority the server trusts, delivered to that client securely before it ever makes a first connection.
• Rotation and expiry. Client certificates expire the same way server certificates do, and a fleet of thousands of devices or services all needs a working renewal process, or connections start failing the day certificates lapse, the same failure mode a normal handshake has, multiplied by every client instead of just the server.
• Revocation. If a client's private key is compromised, the server needs a way to reject that specific certificate before its expiry date, which means running and checking a revocation list or an OCSP responder for every connection attempt.
• Private key storage on the client. The client's private key has to live somewhere it cannot be casually extracted, which is straightforward on a server and much harder on a mobile device, a browser, or hardware with no secure enclave.

None of this is impossible to run, but it is a real PKI operation, with its own certificate authority, issuance workflow and revocation process, not a one-line configuration change.

How is mTLS different from an API key or a bearer token?

An API key or a bearer token is a shared secret string sent inside the request itself, typically in a header, after the TLS connection is already established. Anyone who obtains that string, from a log file, a misconfigured proxy or a compromised client, can replay it from anywhere until it is revoked or expires. The server has no way to tell a legitimate holder of the token from someone who merely copied it.

A client certificate proves possession of a private key as part of the handshake itself, through the CertificateVerify signature, rather than proving knowledge of a string that travels with every request. The private key itself never crosses the network; only signatures made with it do. That is a stronger guarantee against a leaked credential being replayed, but it comes with the PKI overhead described above, and it does not fit every architecture: many CDNs, load balancers and reverse proxies terminate TLS themselves and re-establish a fresh connection to the origin, which breaks the client certificate's chain of trust unless every hop in between is deliberately built to pass it through. A bearer token, being an application-layer value, survives a TLS-terminating proxy without any special handling.

In practice, the two are often combined rather than treated as a choice: mTLS authenticates the connection itself, and a token or scoped credential still handles per-request authorization on top of it. Checking that a certificate-authenticated endpoint's handshake still succeeds, the same way the SSL/TLS check tool verifies a certificate chain on an ordinary server, catches an expiring or misconfigured client certificate before it starts failing every service that depends on it. HostTracker has monitored websites since 2004, checks from 300+ checkpoints in 158 cities, and can alert by email, SMS, voice call, Slack, Telegram and more the moment a certificate check finds a handshake that no longer completes.

Frequently asked questions

Does mTLS replace passwords and API keys entirely?

Not usually. mTLS authenticates the connection; most systems still layer an application-level credential or authorization scope on top for fine-grained permissions, since a certificate proves which service or device is connecting, not necessarily what that caller is allowed to do once connected.

Can a browser use mutual TLS?

Yes, though it is uncommon outside enterprise settings. A browser can be configured to present a client certificate, and the operating system or browser will prompt to select one if a server requests it, but the certificate distribution problem makes this rare for anything consumer-facing.

Is mTLS the same as a VPN?

No. A VPN creates a private network tunnel that traffic of any kind can travel through. mTLS is an authentication method for a single TLS connection, and does not by itself route or tunnel any traffic; the two are sometimes combined, but they solve different problems.

What happens if a client certificate expires unnoticed?

Every connection that requires it starts failing the handshake at the CertificateVerify or Certificate step, the same way an expired server certificate fails, except the failure hits every dependent service or device at once rather than everyone visiting a single site.

Does mTLS make the connection slower?

The extra cost is one more certificate and one more signature verification during the handshake, which is small next to a typical round trip time. It does not add an extra network round trip in TLS 1.3, since the client certificate exchange rides inside the same encrypted flight as the rest of the handshake.