mTLS vs TLS vs IPSec - Encryption in Transit

Encryption-in-transit questions show up in almost every networking or security round because they separate people who've memorized acronyms from people who've actually deployed these protocols. Knowing the one-line definition of TLS, mTLS, and IPSec is the easy part. Knowing when to reach for each one, and what it costs you operationally, is what interviewers are actually testing.

The answer interviewers want

Start with what each protocol actually does, then move to where you'd use it.

TLS encrypts traffic from client to server. It's a one-way trust model: the client verifies the server's certificate, but the server doesn't verify the client's identity through the same mechanism.

mTLS (mutual TLS) adds mutual authentication on top of that. Both sides present certificates, and both sides verify each other before the connection is trusted.

IPSec operates at the network layer, not the application layer. It encrypts traffic at a lower level in the stack, independent of whatever protocol is riding on top of it.

That maps to three distinct use cases:

• TLS for web traffic, standard client-to-server connections like browsers hitting an API or a load balancer.
• mTLS for service mesh, where every service needs to prove its identity to every other service it talks to, not just encrypt the pipe.
• IPSec for site-to-site VPNs, where you're encrypting traffic between networks rather than individual application connections.

The detail most candidates skip: mTLS requires certificate management on both sides of the connection, not just the server. That means issuing, rotating, and revoking client certificates at scale, which is why service meshes (Istio, Linkerd) usually bundle a certificate authority to automate it. Without that automation, mTLS becomes an operational burden fast.

Why interviewers ask this

This question filters for people who understand the trust model behind each protocol, not just the acronym. Anyone can say "mTLS is more secure." Interviewers want to hear that you know why, that it's about mutual identity verification, and that you understand the operational tax that comes with it, specifically certificate lifecycle management.

Follow-ups to expect

"Why would you choose mTLS over plain TLS inside a service mesh?" Because internal services need to verify each other's identity, not just encrypt the connection, since a compromised pod on the network shouldn't be able to impersonate another service.

"What happens if certificate rotation fails in an mTLS setup?" Services start rejecting each other's connections because their certs no longer validate, which is why mesh platforms automate rotation rather than relying on manual cert management.

"How does IPSec differ from a TLS-based VPN?" IPSec works at the network layer and encrypts traffic independent of the application protocol, while TLS-based VPN solutions still operate higher up the stack.

The common wrong answer

Most candidates recite the definitions correctly, TLS is one-way, mTLS is mutual, IPSec is network layer, but then say "we'd use mTLS everywhere for better security" without mentioning the certificate management overhead. That answer signals you've read the marketing material but haven't run mTLS in production, where cert rotation and revocation at scale is the actual hard part.