Skip to content

Archive

Service Identity

3 articles
Cybersecurity 15 Sep 2026 7 min read

Mutual TLS Moves Client Identity Into the Handshake

Mutual TLS Moves Client Identity Into the Handshake An internal API can receive a perfectly encrypted TLS connection and still have no cryptographic evidence about the process at the other end. Ordinary server-authenticated TLS proves the server’s identity to the client and protects traffic in transit, but the application still needs another mechanism to identify its caller. Mutual TLS, commonly shortened to mTLS, adds certificate-based client authentication to that exchange. The server requests a client certificate, validates the presented chain according to its trust policy, and verifies a signature proving possession of the corresponding private key. The result is a transport connection associated with a cryptographic client identity before ordinary application requests are processed.

Cybersecurity 13 Sep 2026 7 min read

Mutual TLS Makes Service Identity a Certificate Lifecycle Problem

A service can encrypt every connection and still have only a vague idea of what is calling it. Conventional server-authenticated TLS proves the server’s identity to the client, but the reverse direction is usually left to an application credential, a network location, or infrastructure convention. Mutual TLS changes that relationship by requiring the client to present a certificate as well. The transport can then carry authenticated identities in both directions before application data is exchanged.

Cybersecurity 12 Sep 2026 9 min read

Service Identity Does Not End at mTLS

A successful mutual TLS handshake can establish that both endpoints hold credentials accepted by their respective trust policies. In modern service platforms, that often happens inside sidecars, node agents, gateways, or transparent proxies rather than inside application code. The connection is encrypted, a workload identity has been authenticated, and the transport looks secure. That is still only part of the security decision. The authenticated peer may be the wrong workload for the requested operation. A proxy may know the peer identity while the application sees only a local connection. A certificate may remain valid after the workload’s authority has changed. A broad trust bundle may allow credentials from an environment that was never meant to reach a production service.