TLS encrypts traffic and proves the server's identity. Mutual TLS, or mTLS, also makes the client present a certificate, so the server knows which service is calling. For service to service gRPC, mTLS is the stronger choice, but that holds if you can automate certificate issuance and rotation. Otherwise you trade one risk for another.
Definitions
TLS gives a client confidence it is talking to the right server and hides the data from observers. The client usually verifies the server certificate against a trusted authority.
Mutual TLS adds a step: the server also requests a certificate from the client and verifies it. Both sides are authenticated at the connection level.
OWASP's gRPC security cheat sheet recommends TLS in production, with version 1.2 or higher and strong cipher suites, and recommends mTLS for service to service communication because both sides verify certificates, which enables zero trust style communication. It also suggests short lived certificates of 90 days or less with automated rotation to limit the impact of compromised keys.
Decision table
| Situation | TLS | mTLS |
|---|---|---|
| Public API called by outside users with tokens | Yes | Rarely practical |
| Internal services in one trust zone | Minimum | Recommended |
| Services across clusters or networks | Not enough alone | Recommended |
| Services handling regulated or sensitive data | Not enough alone | Recommended |
| No way to automate certificates | Yes | Risky to run manually |
The last row is practical. Manual certificate handling leads to expired certificates, outages and eventually long lived certificates nobody dares to rotate. If you cannot automate, start with TLS plus token based call credentials, and plan the automation.
What mTLS gives you and what it does not
mTLS tells the server which certificate the caller holds. It does not say what the caller may do. You still need authorization per method. OWASP's guidance calls for method level checks based on least privilege, log of authorization failures, and tokens in metadata for user context. A service identity from a certificate and a user identity from a token answer different questions, and many systems need both.
A compromised service with a valid certificate can still call anything its identity is allowed to call, so keep permissions narrow.
Steps to adopt mTLS
- Choose a certificate authority for internal identities and protect its keys.
- Define a service identity scheme, for example one certificate per service, not per instance shared widely.
- Automate issuance and renewal, with lifetimes of 90 days or less as OWASP suggests, or shorter.
- Configure servers to require and verify client certificates, and clients to verify servers.
- Write method level authorization rules keyed on the verified service identity.
- Monitor expiry dates and alert well before a certificate lapses.
- Test failure cases: no client certificate, expired certificate, certificate from another authority, certificate for a different service.
- Document how to revoke a service identity quickly.
OWASP also mentions service meshes that provide automatic mTLS and centralized policy. Whether a mesh fits your team depends on your stack and size. The principle holds either way.
Rotation without outages
Roll out new certificates before old ones expire, accept both for a window, and confirm every client has switched before retiring the old authority. Test the process in staging on a schedule so the first real rotation is not the first rotation.
Related reading: how channel and call credentials combine.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how API findings are categorized and consider which relate to transport and identity.
Quick check
Does mTLS replace authorization?
No. It proves which service connected. You still need method level authorization and, where relevant, user tokens.
How long should service certificates live?
OWASP suggests 90 days or less with automated rotation. Shorter is fine if your automation supports it.
Safeguard scans your dependencies and SBOMs for known vulnerabilities, including gRPC and TLS libraries. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
