Why mTLS Is Not Optional in Our Architecture
Service-to-service trust should never be assumed. Why every internal call in our deployments is mutually authenticated, and what it costs to do that properly.
Many of the architectures we inherit still treat perimeter security as enough. A load balancer terminates TLS, everything behind it talks in plaintext or with one-way certificates, and any request that got past the edge is trusted. We don't build that way, and when we take over a project built that way, we change it.
The assumption we don't make
One-way TLS proves the server is who it says it is. It says nothing about the client. In a microservices layout, that means any workload inside the network boundary can call any internal service and be treated as legitimate traffic: a compromised sidecar, a misconfigured debug pod, a dependency with a supply-chain problem. Segmentation slows that down. It doesn't stop it.
Mutual TLS closes that gap. Every service proves its identity to every other service, on every call, with short-lived certificates issued by an internal CA. Without a certificate there is no connection. There are no exceptions for internal-only traffic, because internal traffic is exactly where the assumption fails.
What it costs
mTLS by default has a real price:
- Certificate issuance and rotation must be automated from day one. Doing it by hand stops working beyond a handful of services.
- Local development needs its own chain of trust. Otherwise engineers start disabling verification “just for testing”, and sooner or later that flag reaches production.
- Debugging a failed mTLS handshake is a different skill from debugging an HTTP 500. The team has to learn it before go-live.
Where we draw the line
We treat mTLS as part of the platform. A team can't switch it off to meet a deadline. The same pipeline that provisions a service provisions its certificates and rotates them automatically, and a service without mTLS fails the build, just as a missing test or a failed SAST check does.
mTLS doesn't replace network segmentation, least privilege or monitoring. It closes one specific and common gap: the assumption that anything inside the perimeter can be trusted by default. We never make that assumption.