At A Glance
Mutual TLS (mTLS) is a security protocol where both sides of a connection (vs. just the server) present a certificate to prove their identity before any data moves. NetFoundry defines it as the missing half of standard TLS: instead of only the client trusting the server, both endpoints authenticate each other. mTLS is a foundational building block of Zero Trust, but running it at scale means operating a full PKI, solving secure certificate bootstrapping, and managing a certificate lifecycle that never stops — which is why most homegrown mTLS rollouts stall before they reach production. NetFoundry builds mutual authentication into the network itself, so every connection is mTLS by default, with no PKI to stand up and no certificates to manage by hand.
Ask any security architect where their Zero Trust rollout stalled, and there’s a good chance the answer is mTLS.
It’s the obvious fix for a gap standard TLS leaves wide open: the server proves who it is, but the client doesn’t. That’s fine for a public website. It’s not fine for API-to-API traffic, service meshes, IoT fleets, OT environments, or partner integrations — anywhere the server needs to know the client is legitimate before it responds. mTLS closes that gap by making both sides present certificates, which is exactly why it’s become a cornerstone of Zero Trust.
The concept is elegant, but the deployment is where good architectures die.
Where mTLS Deployments Go Wrong
mTLS deployments don’t usually fail all at once. They fail in stages, one uncomfortable discovery at a time, each one arriving just as the last one gets fixed.
The PKI Operations Gap
One OpenSSL command gets you a certificate. Running the infrastructure behind thousands of them is a different job entirely — protecting a root CA, designing an intermediate hierarchy, writing issuance policy, and keeping all of it available and auditable for years. Teams that set out to “just turn on mTLS” usually discover, too late, that they’ve signed up to operate a PKI — a discipline their org never planned to staff.
The Secret Zero Bootstrapping Problem
Before a workload can present a certificate, it needs a private key and a signed credential — and getting that first credential onto a device securely is the classic bootstrapping problem. Copy keys by hand and you don’t scale. Bake them into machine images or CI pipelines and you’ve created long-lived secrets that will leak. Every mTLS rollout needs a secure, automated enrollment story. Most homegrown ones quietly skip it.
The Certificate Lifecycle Trap
Certificates expire. Expired certificates cause outages — and it’s not just small shops that get burned by this; sophisticated engineering organizations at major telecoms and SaaS providers have taken public outages over forgotten renewals. The industry’s answer has been shorter certificate lifetimes, which is good for security and brutal for operations: more rotation, more automation, more 2 a.m. pages when a renewal pipeline breaks. Revocation is worse. CRLs and OCSP barely work in practice, so a compromised key often stays trusted long after anyone would admit to it.
The Legacy Application Blind Spot
Most legacy systems have no concept of presenting a client certificate. Load balancers and proxies terminate TLS mid-path, quietly breaking the end-to-end guarantee mTLS was supposed to provide in the first place. Teams paper over it with sidecars, custom middleware, and one-off exceptions — and every exception is a hole punched in the trust model you just built.
The Identity-Authorization Issue
Even a flawless mTLS deployment only proves identity. Without a policy layer on top, any client with a valid cert can often reach services it has no business touching. That’s authentication without least privilege — half of Zero Trust, at best.
How NetFoundry Simplifies mTLS Deployment
NetFoundry starts from a different premise: don’t retrofit mTLS onto your network — build the network so mTLS is the transport. Every connection is mutually authenticated by default. You don’t configure it. You can’t accidentally turn it off.
The PKI Comes Built In
NetFoundry operates the certificate authority infrastructure for you. No root CA to protect, no hierarchy to design, no issuance policy to write from scratch. Already run your own PKI? Bring your own CA instead. Nobody is forced into becoming a PKI operator just to get mutual authentication.
Enrollment Solves Secret Zero
Endpoints join the network through secure, one-time-token enrollment. The private key is generated on the endpoint itself and never crosses the network. One design decision, and the key-distribution problem that sinks most homegrown mTLS efforts is simply gone.
The Lifecycle Runs Itself
Renewal and rotation happen automatically as part of platform operation — no calendar, no expiry-driven outage, no rush to build rotation tooling before the first batch of certs age out. Need to cut someone off? Revoke the identity in the controller and access ends immediately, no dependence on CRL or OCSP behaving itself.
Nobody Has to Rewrite an Application
Want the strongest posture? Embed identity directly with NetFoundry SDKs and push mutual authentication into the application process itself. Can’t touch the code? Drop in a lightweight tunneler or edge router and get mTLS-protected connectivity with zero code changes. Either path keeps the trust model end-to-end — nothing terminates at a middlebox.
Identity Comes with Authorization Attached
Every endpoint carries a strong cryptographic identity, and NetFoundry layers least-privilege policy directly on top of it. Services stay dark — no inbound ports exposed to the internet — and an identity can only discover and reach what its policy explicitly allows. Authentication happens before connection, and a valid identity gets exactly the access it should. Nothing more. That’s the full Zero Trust model, not just the handshake.
mTLS Simplified with NetFoundry
mTLS doesn’t fail in production because the cryptography is weak. It fails because of the PKI burden, the bootstrapping problem, the lifecycle work that never ends, and the gap between proving identity and enforcing access. NetFoundry absorbs all four into the platform — turning mutual TLS from a multi-quarter infrastructure project into a property your network simply has.
NetFoundry was built by the same team that created and maintains OpenZiti, the world’s most widely used open-source Zero Trust platform. We already run this exact model at scale — securing billions of sessions for critical infrastructure across three continents, including Fortune 10 companies in healthcare, financial services, and energy.
Your team spends its time on the applications the network exists to serve. Your auditors see mutual authentication and least privilege enforced everywhere, by default — not documented as a goal, but observable as a fact.
Ready to see mutual authentication running by default across your environment??
Talk to our team to find out how fast you can get there.
Frequently Asked Questions
Mutual TLS is an authentication method where both the client and the server present certificates to verify each other’s identity before a connection is established. We use mTLS as the default transport for every connection on the NetFoundry platform, so mutual authentication happens automatically rather than requiring custom configuration.
Standard TLS only verifies the identity of the server, which is fine for a public website but leaves the server unable to confirm who — or what — is connecting to it. Mutual TLS closes that gap by requiring the client to present a certificate too. We built our platform so this two-way verification is the network’s default behavior, not an add-on layer applications have to implement themselves.
mTLS deployments typically stall on four things: standing up and protecting a PKI, securely bootstrapping the first certificate onto each device, keeping up with certificate renewal and revocation, and retrofitting legacy applications that were never built to present a certificate. Our platform absorbs all four of these into the network layer, so teams get mutual authentication without taking on PKI operations as a new discipline.
No — mTLS proves identity, but identity alone doesn’t enforce least privilege. A valid certificate can still let a client reach services it has no business touching unless a policy layer sits on top of it. We pair every authenticated identity with least-privilege access policy, so authentication and authorization work together instead of stopping at the handshake.
We operate the PKI, handle secure enrollment so private keys never leave the device, automate certificate renewal and revocation, and let teams choose between embedding identity in the application or deploying it with zero code changes via a tunneler or edge router. The result is mutual authentication and least-privilege access as a property of the network, not a multi-quarter infrastructure project.
