[sgtcodfish]

At the BBC we use mutual TLS extensively in our cloud-deployed applications, across a lot of developers and different teams, for both service-to-service and developer-to-service auth (all devs get a client cert).

It works well for a lot of use cases, not least because most things are doing a TLS handshake anyway when communicating. That means that adding client certs into the mix isn't much of an overhead and you can avoid another authentication/authorization step if your CA hierarchy is well managed and you can trust that a cert which says "Joe Bloggs" is actually Joe's cert. Also obviously it avoids any 3rd parties, like you said!

That said, it only really works for us because a lot of apps are deployed through a centralised tool which adds relatively short-lived certificates to deployments and then automatically redeploys things before their certs expire. That ensures that certs stay valid. We also have a solution to handle revocation in the event that a cert is compromised, which is a massive pain.

So if you spend the time to set everything up it's pretty great, but the cost of setting it up is quite high. You'll also run into problems where you want to use some tool X but it doesn't support mutual TLS and you're forced to either find a different tool or hack in support if that's an option.

A big example of missing support is things like the Application Load Balancer in AWS (or equivalents in other clouds) - they tend not to support mutual auth, which means that you can't really use them and you're forced to use a more traditional load balancer with TLS passthrough and then terminate TLS somewhere else.