What Is mTLS? Mutual TLS Authentication Explained

mTLS, or mutual TLS, is a form of TLS where both sides of a connection present and verify certificates, so the client authenticates the server and the server authenticates the client. Ordinary TLS only proves the server's identity to the client. mTLS adds the reverse check, which is why it is the default way to authenticate services, workloads, and increasingly AI agents to each other, where there is no human to log in.

If you have seen "mutual authentication," "mutually authenticated TLS," or "certificate-based authentication" and wondered whether they mean the same thing, they do, and this is it. This guide covers what mTLS is, how the handshake actually works, when to use it, how it connects to OAuth through certificate-bound tokens, and the operational parts teams underestimate.

What is the difference between TLS and mTLS?

Regular TLS authenticates one party, the server. When your browser connects to a site over HTTPS, the server presents a certificate, your client checks that it chains to a trusted certificate authority, and an encrypted channel is set up. The client stays anonymous at the TLS layer, and identifies itself later through something else, like a password or a token.

mTLS authenticates both parties. The server still presents its certificate, and additionally asks the client for one. The client presents its own certificate and proves it holds the matching private key. Each side verifies the other's certificate against the certificate authorities it trusts. The result is a connection where both ends are cryptographically identified before any application data flows. TLS is defined in RFC 8446, and client authentication is a built-in, optional part of that same handshake, not a separate protocol.

How does the mTLS handshake work, step by step?

The mTLS flow is the standard TLS handshake with the client-certificate steps switched on. It runs in this order:

The client opens the connection and the server responds, agreeing on TLS parameters.
The server presents its own certificate, as in ordinary TLS.
The server sends a certificate request, asking the client to authenticate with a certificate. This request is what makes the handshake mutual.
The client presents its certificate, then sends a signed value proving it possesses the private key for that certificate. Presenting a certificate is not enough on its own, the proof of possession is what prevents someone from replaying a copied certificate.
Each side validates the other's certificate: that it chains to a trusted CA, is within its validity dates, and has not been revoked.
With both identities verified, the two sides finish establishing session keys and the channel is encrypted.

The important idea is that identity is established during the connection setup, by cryptography, before a single request is served. Nothing downstream has to re-ask "who is calling."

When should you use mTLS?

Use mTLS wherever the caller is a machine rather than a person. The clearest cases are service-to-service and microservice traffic, where you want each service to prove which service it is instead of trusting the network it sits on. It is the backbone of zero-trust architectures and service meshes for exactly that reason, and it fits API access between businesses, IoT and device fleets, and AI agents or workloads that call your systems without a human present.

It is a poor fit for ordinary end-user login in a browser, because issuing and installing a client certificate on every user's device is painful and the user experience is worse than passwordless options like passkeys. The rule of thumb: mTLS for non-human callers, human-facing authentication for people. Which of the two a given request is closer to is the same distinction covered in authentication vs authorization.

What are certificate-bound access tokens, and how does mTLS relate to OAuth?

mTLS also solves a specific OAuth problem: a stolen bearer token. A normal OAuth access token is a bearer token, meaning whoever holds it can use it, so a leaked access token is enough for an attacker to impersonate the client until it expires. Certificate-bound access tokens close that gap by tying the token to the client's certificate.

This is standardized in RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens. The client authenticates to the authorization server with its certificate over mTLS, and the token the server issues carries a thumbprint of that certificate in a confirmation claim, the `cnf` claim. When the client later calls an API, the API checks that the certificate presented on the mTLS connection matches the `cnf` thumbprint in the token. If a token is copied and replayed from a different client, the certificates will not match and the call is rejected, so possession of the token alone is no longer enough. This is why certificate-bound tokens are effectively a requirement in high-assurance profiles like open banking and FAPI, where a leaked token must never be replayable.

What are the operational challenges of mTLS?

The hard part of mTLS is not the handshake, it is the certificates behind it. You need a public key infrastructure to issue certificates, a way to distribute them to every client, and a plan to rotate them before they expire, because an expired certificate breaks the connection outright. Certificate expiry and rotation is the most common cause of mTLS outages in production.

Revocation is the other piece. When a certificate is compromised, you need to stop trusting it quickly, which is what certificate revocation lists (RFC 5280) and the Online Certificate Status Protocol (RFC 6960) exist to do. Both add a validation step and a decision about how fresh that status check needs to be. None of this is a reason to avoid mTLS, but it is the reason teams reach for a platform that manages the PKI plumbing rather than hand-rolling it.

How does MonoCloud implement mTLS?

MonoCloud supports mTLS as part of its identity platform, built on the OAuth 2.0 Mutual-TLS standard (RFC 8705). It authenticates clients by certificate and issues certificate-bound access tokens, so a token only works for the client holding the matching certificate and a stolen token is unusable from any other client, device, or workload. Certificate-bound tokens work across OAuth flows, machine-to-machine, device, and interactive, not only M2M.

You bring your own PKI as the source of trust, using AWS Private CA, Google Cloud, HashiCorp Vault, a SPIRE trust bundle for SPIFFE workload identities, or your own online or offline certificate authority, including air-gapped setups via uploaded issuer chains and revocation lists. Revocation is centralized: MonoCloud validates certificates against CRLs and live OCSP, with local deny lists when online checks are unavailable, so revoking a compromised certificate blocks it before another token is issued. Validation is tunable per truststore, covering revocation depth and mode, key-purpose and expiry checks, cache windows, OCSP timeouts, and clock-skew tolerance. And because MonoCloud evaluates access policy at the moment a token is issued, whether a valid client certificate was presented can itself be a condition in that policy, which you can read more about in What Are Cedar Policies?. To see the full feature, visit the MonoCloud mTLS page, or start building on MonoCloud for free.

Frequently asked questions

What is mTLS in simple terms?

mTLS, or mutual TLS, is a connection where both sides present certificates, so the client verifies the server and the server verifies the client. Regular TLS only proves the server's identity. mTLS adds the reverse check, which makes it the standard way for services, workloads, and agents to authenticate each other without a human logging in.

What is the difference between TLS and mTLS?

Regular TLS authenticates only the server: the server presents a certificate and the client verifies it. mTLS is mutually authenticated, meaning the server also requests a certificate from the client, and each side verifies the other against trusted certificate authorities. The result is a connection where both ends are cryptographically identified before any data flows.

How does the mTLS handshake work?

It is the normal TLS handshake with the client-certificate steps enabled. The server presents its certificate and then requests one from the client. The client presents its certificate and proves it holds the matching private key. Each side validates the other's certificate against a trusted CA, then the encrypted session begins.

When should you use mTLS?

Use mTLS when the caller is a machine rather than a person: service-to-service and microservice traffic, zero-trust networks, API access between businesses, device fleets, and AI agents or workloads. It is a poor fit for ordinary end-user browser login, where passwordless methods like passkeys give better security and experience.

Does mTLS replace OAuth or OpenID Connect?

No. mTLS authenticates the connection and the client. OAuth and OpenID Connect handle authorization and user identity. They work together: with certificate-bound access tokens (RFC 8705), a client authenticates over mTLS and the issued token is tied to its certificate, so a stolen token cannot be replayed from another client.