What is the difference between TLS and mTLS?

In standard TLS the server proves its identity with a certificate and the client verifies it against a trusted certificate authority. The client is not authenticated at the TLS layer, so it typically proves who it is afterwards with a password, an API key or a token inside the encrypted channel. In mutual TLS the server also requests a certificate from the client and verifies it, so both ends prove identity before any application data flows.

Is mTLS more secure than TLS?

It adds client authentication, which removes a class of attack: there is no bearer credential to steal and replay, because proving identity requires possession of a private key that never leaves the client. It does not make the encryption stronger, and it introduces a new failure mode in certificate management. It is more secure for the specific problem of proving who is connecting, and it is not a general upgrade.

How does the handshake differ?

The server sends a CertificateRequest message. The client responds with its certificate chain and a CertificateVerify message containing a signature over the handshake transcript, made with the private key matching that certificate. The server validates the chain against its trusted issuers and checks the signature. If either fails, the handshake aborts before any application data is exchanged.

Why is mTLS common between microservices but rare for websites?

Because the lifecycle problem is tractable for workloads and intractable for people. A service mesh can issue a short-lived certificate to every workload automatically, rotate it hourly and revoke it by letting it expire. A consumer website would have to get a certificate onto every user's every device, keep it there, and handle the case where somebody loses their phone. Passkeys solve the human version of this problem far better.

Does mTLS replace API keys and tokens?

It can replace them for authentication, and it does not replace authorisation. mTLS tells the server which client is connecting; it says nothing about what that client is allowed to do. Most systems using mTLS still carry an authorisation layer that maps the certificate identity to permissions, and many keep tokens for fine-grained scope while using mTLS for the transport-level identity.

What happens when a client certificate is stolen?

It is a valid identity until it expires or is revoked, in the same way a stolen password is. That is why the strong pattern is short lifetimes with automated renewal rather than long-lived certificates and a revocation list, since revocation checking is unreliable in practice and a certificate that expires in an hour limits the damage without needing it.

mTLS vs TLS: What Mutual Authentication Actually Adds

The names suggest two protocols. There is one protocol, and mTLS is TLS with an optional step switched on.

That step is the server asking the client for a certificate. Everything people say about mTLS, good and bad, follows from what happens when you turn it on and then have to run it.

Scope: How the TLS Handshake Works owns the handshake in detail, What Is mTLS owns deploying it, and What Is PKI owns the certificate infrastructure underneath both. This page owns the comparison.

The difference

	TLS	mTLS
Server proves identity	Yes, certificate verified against a trusted CA	Yes, identical
Client proves identity	No, at the TLS layer	Yes, with a certificate and a signature
Client credential	Whatever the application uses afterwards: password, API key, token	A private key that never leaves the client
Encryption	Same	Same
Extra infrastructure	The server's certificate	A CA for clients, plus issuance, rotation and revocation for every client
Typical use	The public web	Service to service, machine to machine, high-assurance APIs

In standard TLS the client is anonymous at the transport layer. It learns who the server is, opens an encrypted channel, and then proves who it is inside that channel with something the application understands.

In mTLS that proof moves down a layer and happens first.

What happens in the handshake

Three extra messages carry the whole difference.

CertificateRequest. The server tells the client it requires a certificate, and which issuers it trusts.

Certificate. The client sends its certificate chain.

CertificateVerify. The client signs the handshake transcript with the private key matching that certificate. This is the part that matters: it proves possession of the key rather than possession of the certificate, and the certificate alone is public information.

The server validates the chain to a trusted issuer, checks validity dates and any revocation information it consults, and verifies the signature. If anything fails, the handshake aborts and no application data is ever exchanged.

That last property is the security argument in one line: an unauthenticated client never reaches your application code. No request is parsed, no route is matched, no input is handled. The rejection happens in the TLS stack.

What it actually buys

No bearer credential to steal. An API key or token in a header is a bearer credential: whoever holds it is the client. Copy it from a log, a config file, a browser session or a compromised host and it works. A client certificate requires the private key to sign a fresh challenge, so copying the certificate alone achieves nothing.

Nothing to phish. There is no secret the client can be tricked into typing somewhere.

Rejection before the application. The attack surface an unauthenticated party can reach shrinks to the TLS implementation.

Cryptographic identity for workloads. In a service mesh, every workload gets an identity that survives rescheduling and is not tied to an IP address, which is exactly the property Zero Trust Architecture Explained requires for replacing network position with identity. SPIFFE is the common standard for expressing it.

What it costs

Certificate lifecycle for every client. Issuing, distributing, renewing and revoking. This is the entire practical difficulty and it scales with the number of clients.

Revocation is unreliable. CRLs get large; OCSP adds a network dependency and often fails open. The working answer is to make certificates short-lived and renew automatically, so expiry does the job revocation is bad at.

Expiry outages. A certificate that expires unnoticed takes the service down. This is one of the most common causes of self-inflicted outages in mTLS estates, and the fix is automation plus expiry monitoring rather than a calendar reminder.

Debugging is harder. A failed handshake produces an unhelpful error at both ends. Client certificate problems are consistently the least pleasant thing to diagnose in a mesh.

No authorisation. mTLS says who. It never says what they may do. You still need policy, which is why meshes pair identity with an authorisation layer.

Where each belongs

Use TLS alone for the public web, anything with anonymous users, and any case where the client population is unbounded. Authenticate users inside the channel, ideally with phishing-resistant credentials, which for humans means Passkeys Explained rather than certificates.

Use mTLS between services in a mesh, for machine-to-machine APIs with a known client population, for partner integrations where both organisations can manage certificates, for administrative interfaces, and for device fleets such as IoT where the manufacturer can provision a key at build time.

Do not use mTLS for consumer applications. Every user needs a certificate on every device, transferring to a new phone is a support ticket, and losing a device is a recovery problem with no good answer. The industry tried this and moved on.

The failure modes worth knowing

Long-lived certificates. A ten-year client certificate is a permanent credential. Short lifetimes with automated renewal are the pattern that works.
Private keys in the wrong place. Copied into a container image, committed to a repository, or left readable by every process on the host. The key is the credential, so it deserves the handling in Privileged Access Management Explained.
Verifying the certificate and ignoring the identity. Accepting any certificate signed by the CA rather than checking which client it is. If your CA issues to many clients, chain validation alone authorises all of them.
A CA that issues too broadly. The trust anchor for client certificates should not be a public CA, and its issuance policy is a security control.
Terminating mTLS at a proxy and forwarding plaintext. Common, sometimes correct, and it means the identity guarantee stops at the proxy. Whatever is behind it must not trust a client-supplied identity header.

The verdict

mTLS is TLS with client authentication turned on. It converts identity from something the client asserts into something the client proves with a key, before your application sees a byte.

It is close to ideal between services, where certificates can be issued and rotated automatically and there are no humans to inconvenience. It is close to unworkable for consumer users, where the lifecycle lands on people who lose devices. The decision is almost entirely about who or what is on the client side, and not about how much security you want.