What is mTLS, how does it work, and why does almost nobody use it?

Mutual TLS, or mTLS, is TLS in which both sides present certificates and verify each other before any data is exchanged, instead of only the server proving who it is. It is widely used between machines, such as internal services, CDNs and origin servers, banking APIs and IoT devices. It is rare for people, because issuing and managing certificates on everyone's phones and laptops is painful, and passkeys now do that job better.

In a normal HTTPS connection, only the server shows a certificate, and you stay anonymous at that level until you log in with a password or an OTP. So why don't the websites you use every day ask for mTLS? The answer says a lot about the difference between securing machines and securing people.

One-way TLS vs mutual TLS

Think of visiting a government office with security at the gate. With ordinary TLS, the building proves it's the genuine office, with its official board and registered address, and anyone may walk into the lobby. You identify yourself later, at a counter. That's the equivalent of logging in after the connection is set up.

With mutual TLS, the guard at the gate checks your ID card too. Without a valid card, you never reach the lobby at all.

How the mTLS handshake works

mTLS is ordinary TLS with a few extra messages; our guide to how SSL/TLS works covers the standard handshake. Using TLS 1.3:

1. The client sends its hello and its half of the key exchange, as usual.
   
   
2. The server replies with its key share, its certificate and proof that it owns that certificate, and adds a certificate request: "Now show me yours", along with the certificate authorities it accepts.
   
   
3. The client sends its own certificate.
   
   
4. The client signs a summary of the handshake with its private key. As with the server, this digital signature proves it holds the key, not merely a copy of the certificate.
   
   
5. The server validates the client's certificate. Was it issued by a CA the server trusts, often a private CA run by the organisation itself, as our explainer on PKI and certificate authorities describes? Is it within its validity dates? Has it been revoked?
   
   
6. If all is well, the handshake completes and encrypted traffic flows. The server now knows exactly which client is connected, say "billing-service" or "device 4821", and can apply permissions accordingly.
   
   

If the client has no valid certificate, the handshake simply fails, and the request never reaches the application code. That is a big part of the appeal. In TLS 1.3 the client's certificate also travels encrypted; in TLS 1.2 it was sent in the clear, exposing the client's identity to anyone watching the network.

Why mTLS is attractive

• Strong identity. A private key can't be phished the way a password can, and it can live in tamper-resistant hardware.
  
  
• A smaller attack surface. Attackers without a certificate can't even open a connection to a protected endpoint, let alone probe it for bugs.
  
  
• No secrets in requests. API keys and session tokens can leak through logs, screenshots or code. With mTLS, the private key never leaves the client.
  
  
• Zero trust. Instead of trusting everything inside the company network, every service proves its identity on every connection.
  
  

Where mTLS is actually used

"Almost nobody uses mTLS" is only half true. It's common, just in places ordinary users never see:

• Inside cloud infrastructure. Kubernetes components authenticate one another with certificates. Service meshes such as Linkerd and Istio can give every service a short-lived certificate and rotate it automatically; Linkerd turns mTLS on by default for traffic between the services it manages.
  
  
• Between a CDN and your servers. An origin server can be set to accept only connections that present the CDN's client certificate, so attackers can't bypass the CDN and hit the server directly. Major load balancers can verify client certificates too; AWS added this to its Application Load Balancer in late 2023.
  
  
• Banking and payments. Open-banking systems in several countries use mTLS for server-to-server APIs, and many bank and partner integrations require what they call "two-way SSL".
  
  
• Internet of Things. Sensors, cameras and other devices commonly authenticate to cloud platforms with per-device certificates.
  
  
• Corporate networks. Managed laptops often carry device certificates for VPN and office Wi-Fi access.
  
  

So a more accurate version of the question is: why does almost nobody use mTLS for people?

Why it's rare for people

Getting certificates onto devices is hard

Every user needs a certificate and private key installed on every device they use. Imagine asking fifty thousand students to install a certificate on their phones, their laptops and the family computer, and to repeat the process every time they change devices. The support load alone would be enormous.

The browser experience is poor

When a site asks for a client certificate, browsers show a bare system dialog that the site can't style or explain. Failures appear as cryptic connection errors rather than friendly messages, and logging out is awkward because the browser keeps presenting the chosen certificate.

The lifecycle is a lot of work

Certificates expire and need renewing. Lost or stolen phones need their certificates revoked, and revocation checking is itself notoriously unreliable. Each of these needs tooling and support processes.

Infrastructure gets in the way

Public sites usually terminate TLS at a CDN or load balancer. For mTLS to work, that edge has to check client certificates and pass the verified identity on to your servers, which must in turn trust that information only when it comes from the edge. It's all achievable, but it's more to configure and more to get wrong.

Passkeys do the job better for humans

The core idea behind mTLS, proving identity by showing you hold a private key, has found a friendlier home in passkeys. A passkey is a key pair whose private key stays in the phone's or laptop's secure hardware and is unlocked with a fingerprint, face scan or screen lock. The platform handles syncing and recovery, and the website gets strong, phishing-resistant sign-in without anyone handling certificates by hand.

Should you use mTLS?

mTLS is a strong fit when:

• both ends are machines you control, such as internal services, servers behind a CDN, or partner systems;
  
  
• the endpoint is high-value, such as an admin API, a payment callback or an internal service that handles sensitive data;
  
  
• you can automate issuing and rotating certificates, with a service mesh, a private CA or a managed certificate service.
  
  

It's a poor fit for consumer sign-in, where passwords with OTPs and, increasingly, passkeys are the practical choices.

One common confusion is worth clearing up. Certificate pinning, used by some mobile apps, is a different technique: the app checks the server's certificate more strictly than usual. mTLS is the reverse: the server checks the client.

Key takeaways

• mTLS makes both sides of a TLS connection prove their identity with certificates during the handshake.
  
  
• Clients without a valid certificate can't even connect, which shrinks the attack surface.
  
  
• It's widely used between machines: service meshes, CDNs and origin servers, banking APIs, IoT and corporate devices.
  
  
• It's rare for consumer logins because issuing and managing certificates for people, across all their devices, is painful.
  
  
• Passkeys bring the same private-key idea to people, with a far better experience.
  
  

mTLS isn't unpopular; it's specialised. Wherever machines talk to machines and certificates can be issued automatically, it is one of the strongest tools available. Wherever people are involved, the same cryptographic idea works better hidden behind a fingerprint prompt. Knowing which world you're designing for tells you whether mTLS belongs in your architecture.

Frequently asked questions

What is the difference between TLS and mTLS?

In standard TLS, only the server presents a certificate, and the client checks it; the user proves their identity later, inside the application, with a password, OTP or token. In mutual TLS, the client presents a certificate too and proves it holds the matching private key during the handshake. A client without a valid certificate can't complete the connection at all.

Where is mTLS used?

Mostly between machines. Service meshes such as Linkerd and Istio use it between internal services, origin servers use it to accept traffic only from their CDN, banks and payment partners use it for server-to-server APIs, and IoT devices and managed corporate laptops often carry per-device certificates. It is rare for ordinary website logins.

Is mTLS the same as certificate pinning?

No. Certificate pinning is done by a client, usually a mobile app, which accepts only a specific server certificate or key instead of any certificate a trusted authority has issued. mTLS works the other way round: the server asks the client for a certificate and verifies it. An app can use both, but they solve different problems.

Why don't websites use mTLS for logins?

Because it is hard on people. Every user would need a certificate installed on every device, renewed before it expires and revoked when a phone is lost, and browsers show bare, confusing dialogs when a site asks for one. Passkeys give the same private-key protection with a fingerprint or face prompt, so they have become the practical choice for people.