Term · 32. Workload Identity & Cloud-native
mTLS (mutual TLS) mTLS
Mutual TLS (mTLS) extends standard TLS so that both client and server present and verify X.509 certificates — not just the server. It gives machines and services strong, cryptographic identity, which is why it is foundational to Zero Trust and service-mesh architectures. mTLS authenticates workloads to each other without shared secrets, but requires automated certificate issuance and rotation to operate at scale.
Definition
Mutual TLS — both client and server authenticate each other via certificates during TLS handshake. RFC 8705 specifies OAuth 2.0 mTLS profile. Replaces shared secrets in service-to-service communication with cryptographic mutual authentication. Foundation of workload identity in service mesh architectures.
- Synonyms
-
- Mutual TLS
- Application
- Regulatory: IETF RFC (e.g., 7519 JWT, 6749 OAuth 2.0) · NIST SP 800-63 (Digital Identity Guidelines)
- Standards & regulations
-
- IETF
- NIST
- Sources
-
- OAuth 2.0 mTLS — RFC 8705 primary source
- TLS 1.3 — RFC 8446 (mutual authentication) industry commentary
Related terms
-
Kerberos
Network authentication protocol developed at MIT (Kerberos v5: IETF RFC 4120, 2005) using symmetric-key cryptography and …
-
Public Key Infrastructure (PKI)
Public Key Infrastructure (PKI) — distributed system of services, components, and policies supporting cryptographic oper …
-
DPoP (Demonstration of Proof of Possession) (DPoP)
Demonstration of Proof-of-Possession — IETF RFC 9449, OAuth 2.0 mechanism binding an access token to a private key held …
-
FAPI 2.0 (Financial-grade API) (FAPI 2.0)
OpenID Foundation Financial-grade API Security Profile 2.0 — high-security authorization profile for financial APIs (ope …
-
OAuth 2.1 (OAuth 2.1)
IETF draft consolidating OAuth 2.0 (RFC 6749) with security best practices and deprecating insecure patterns: removes im …
-
OIDC PAR (Pushed Authorization Requests) (PAR)
OAuth 2.0 Pushed Authorization Requests — IETF RFC 9126. Client sends authorization request parameters directly to the a …
Frequently asked questions
How is mTLS different from regular TLS?
In regular TLS only the server proves its identity with a certificate; the client stays anonymous at the transport layer. mTLS adds client-side certificates, so each party authenticates the other — ideal for service-to-service traffic where both ends must be trusted.
Where is mTLS used?
mTLS is common in microservices and service meshes (Istio, Linkerd), API gateways, IoT and Zero Trust networks. It replaces network-location trust with verifiable workload identity.
What is the hardest part of running mTLS?
Certificate lifecycle management. At scale you need automated issuance, short lifetimes and rotation (via SPIFFE/SPIRE or a service mesh) — manual certificates do not work for thousands of ephemeral workloads.