mTLS
Mutual TLS. Both the client and server present and validate X.509 certificates during the TLS handshake. The cryptographic identity binding makes mTLS a strong fit for service-to-service authentication and high-assurance API access.
mTLS gives the strongest identity binding available for service-to-service traffic because the credential is proven during the handshake and cannot be replayed elsewhere. The reason it is not universal is operational: every workload needs a certificate, and certificates expire. Service meshes and SPIFFE exist largely to make that lifecycle automatic, which is what turns mTLS from a good idea into something a platform team can actually run.
See also: X.509, certificate lifecycle, workload identity, SPIFFE
Related on Start with Identity
- GlossaryCAEP
Continuous Access Evaluation Protocol. A specification for communicating security-relevant session events, such as a credential change, a device falling out of
- GlossaryConditional Access
Policy-driven access decisions evaluated at sign-in time. Inputs include identity, device, location, risk signals, and application sensitivity. Microsoft Entra
- GlossaryDevice Posture
The state of a device at the time of access: OS patch level, disk encryption status, EDR presence, jailbreak detection, certificate enrollment. Posture is an in
- CVEKeycloak TLS 1.2 renegotiation denial of service
Keycloak could be knocked over by TLS 1.2 renegotiation. Availability of the IdP is an identity incident. Not an auth bypass.
- PodcastKuppingerCole Analyst Chat
Weekly conversations between KuppingerCole analysts on identity architecture, governance, AI agents, and the market. Over 300 episodes since 2020.
- BlogNGINX session ticket bug can skip client certificate checks in mTLS setups
CVE-2026-97629 lets a forged TLS session resume on NGINX 1.23.2 through 1.31.6 when a shared session cache is set without a ticket key file, which can bypass cl