IDSync — identity software buyer platform
Run Stack Finder

Authentication

Mutual TLS (mTLS)

Mutual TLS (mTLS) is TLS where both the client and the server present X.509 certificates and authenticate each other — used for strong, phishing-resistant, machine-to-machine authentication in service meshes, Zero Trust networks, and high-security APIs.

Last reviewed 5/30/2026

Key points

  • Standard TLS authenticates the server to the client; mTLS adds client-cert authentication so the server also verifies the client.
  • Foundation of service mesh identity: Istio, Linkerd, Consul Connect, AWS App Mesh all use SPIFFE/SPIRE-issued certs for mTLS.
  • Eliminates shared secrets (API keys, bearer tokens) for service-to-service auth — certs can be short-lived and auto-rotated.
  • Used in financial APIs (Open Banking / PSD2), zero-trust network access (BeyondCorp, Cloudflare Access), and IoT.
  • Operational cost: certificate lifecycle (issuance, rotation, revocation) is the hard part — automate with SPIRE, cert-manager, or your service mesh.

What is mTLS?

Mutual TLS (mTLS) is the version of TLS where both sides of the connection present a certificate and verify each other. In ordinary HTTPS, only the server proves who it is (your browser checks the cert chain to a CA it trusts). In mTLS, the client also presents an X.509 certificate, the server checks its chain, and only then is the TLS handshake completed.

mTLS is the dominant pattern for machine-to-machine authentication in modern infrastructure: service meshes, Zero Trust networks, regulated financial APIs, and any environment where shared secrets like API keys are too risky or too painful to rotate.

How it works

  1. TLS handshake starts as usual; server presents its cert.
  2. The server's CertificateRequest message asks the client for a cert.
  3. Client presents its X.509 cert and signs the handshake transcript with its private key.
  4. The server validates the client cert against a trusted CA (often an internal one — SPIRE, Vault PKI, AWS Private CA, cert-manager).
  5. Application-layer authorization runs after the handshake (e.g. matching the cert's SPIFFE ID to an authorization policy).

When buyers care

  • Service mesh — Istio, Linkerd, Consul Connect, Kuma all default to mTLS between sidecars.
  • Zero Trust network access — BeyondCorp, Cloudflare Access, Tailscale, Teleport use client certs (or short-lived cert-equivalents) instead of VPNs.
  • Financial-grade APIs — Open Banking (UK), PSD2 (EU), FAPI profile all require mTLS-bound tokens.
  • Eliminating long-lived API keys — short-lived (1–24 hour) certs rotated automatically replace static secrets that live in env vars and .env files.

mTLS vs JWT for service auth

| | mTLS | JWT | | --- | --- | --- | | Authentication scope | Transport layer | Application layer | | Revocation | CRL / OCSP / short cert TTL | Token introspection / short JWT TTL | | Crosses proxies | Terminates at TLS endpoint | Travels in headers | | Operational complexity | High (PKI) | Medium (key rotation, JWKS) |

In practice, modern systems combine them: mTLS authenticates the workload, and a JWT carries fine-grained claims about the request.

Editorial note

mTLS is excellent but punishing if you build the PKI yourself. Pick a tool that automates issuance, rotation, and revocation (SPIRE, Istio with cert-manager, HashiCorp Vault PKI, AWS Private CA) and never roll your own.

Standards & references