---
{
  "title": "Mutual TLS (mTLS)",
  "summary": "Mutual TLS uses certificates to authenticate both sides of a TLS connection when configured for client authentication.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: Transport Layer Security",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Mutual TLS uses certificates to authenticate both sides of a TLS connection when configured for client authentication. It can establish a cryptographic service identity and protect transport. The application must still map that identity to permissions and manage issuance, rotation, and revocation appropriately.

## A practical example

An internal API accepts certificates from an approved issuer and verifies the expected client identity. It then applies a policy limiting that service to specific operations instead of treating any certificate from the issuer as an administrator credential.

## What to check

Review certificate trust, identity matching, lifetime and rotation, and how verified identities reach application policy. Test invalid, expired, and unexpected client certificates as well as authorized ones.

## A common pitfall

Encrypted communication and client authentication do not determine what the client may do. A broadly trusted certificate issuer can also enlarge the accepted identity set unexpectedly.

## Think it through

Does a successful mTLS handshake authorize every API action?

**Answer:** No. The service must use the verified client identity in an explicit operation-level authorization decision.

## Authentication stops at a defined connection boundary

A fictional billing worker connects to an invoice API using a client certificate. The TLS endpoint verifies the certificate under configured trust rules and establishes the authenticated client identity. The invoice API then decides which invoices that identity may process. Treating every certificate from a trusted issuer as equally privileged would discard the useful distinction between services.

Deployment architecture affects where this verification occurs. A load balancer or service proxy may terminate TLS before forwarding a request to the application. If the application relies on forwarded identity information, it must accept that information only through the trusted forwarding path. A caller must not be able to supply an ordinary header and impersonate the verified certificate identity.

Certificates also have lifecycles. Issuance should bind the right identity to the right key holder, and rotation should happen without requiring broad temporary trust. Decide how the environment handles revoked or compromised credentials and how quickly that decision reaches endpoints. An expired certificate can cause an outage even when the underlying application is healthy.

## Map identity to one permitted operation

For a learning exercise, define two service identities: invoice-reader and payment-worker. Give each a small set of permitted API operations and explain why a successful handshake does not merge those permissions. Add a certificate from an unapproved issuer and an expired certificate as expected connection failures.

Review both transport and application logs using non-secret test identifiers. The useful evidence is which verified identity reached the policy decision, not a copied private key or raw credential. mTLS can strengthen service-to-service identity when the trust, forwarding, and authorization boundaries remain explicit.

## Related concepts

- [[tls]]
- [[digital-certificates]]
- [[authorization]]