Every HTTPS connection on the internet runs on one-way TLS: your browser checks the server’s certificate, and that’s it. The server never asks who you are. Mutual TLS, or mTLS, flips that arrangement so both sides present certificates and both sides get verified before a single byte of application data moves. As zero trust architecture becomes the default posture for banks, cloud platforms, and Kubernetes clusters in 2026, the question engineering teams keep asking is simple: when is standard TLS 1.3 enough, and when does the extra certificate plumbing of mTLS actually pay for itself?

This comparison breaks down the protocol mechanics, the real performance cost, the pricing of running a private certificate authority at scale, and the migration path teams are using to move from perimeter-based TLS to full mutual authentication. We pulled handshake data from a 2026 TLS benchmarking paper, current pricing from AWS and Cloudflare, and configuration defaults straight from Istio and Google Cloud’s own documentation, so every number here traces back to a dated, checkable source rather than a vendor sales page.

The short version, for anyone skimming: TLS 1.3 is the baseline every connection should run on, full stop. mTLS is an optional layer on top of it, worth adding only where both sides of a connection are entities you can actually enroll into a certificate authority. The rest of this piece works through exactly where that line sits, with specs, benchmarks, pricing, and a step-by-step migration path.

What TLS 1.3 Actually Verifies

TLS 1.3, standardized in RFC 8446, is the protocol behind nearly every padlock icon on the web. A client connects, the server sends back a certificate signed by a trusted certificate authority, and the client checks that signature chain before trusting the connection. The server, meanwhile, never asks the client to prove anything. That’s fine for a retail website: the server needs to prove it’s really your bank, but your bank doesn’t need your laptop to carry a certificate just to load a product page.

The protocol improvement that made TLS 1.3 worth the upgrade cycle is round-trip count. A full TLS 1.3 handshake completes in one round trip, down from two round trips in TLS 1.2. Resumed sessions can use zero round trips under the right conditions, though 0-RTT carries replay-risk tradeoffs that most production deployments handle with strict request idempotency rules. That single round-trip saving is why TLS 1.3 adoption climbed steadily after its 2018 publication and why it’s now the default minimum version across major browsers and CDNs.

The TLS 1.3 Handshake, Step by Step

Stripped down, a standard TLS 1.3 handshake runs through a small set of messages defined in RFC 8446: the client opens with a ClientHello that proposes cipher suites and a key share, the server answers with a ServerHello plus its own key share, then sends its Certificate, a CertificateVerify signature proving it holds the private key matching that certificate, and a Finished message. The client validates the certificate chain against a trusted root, checks the signature, and sends its own Finished message. Encrypted application data can then flow. Nowhere in that sequence does the server ask the client to identify itself beyond whatever happens at the application layer, which is usually a password, a session cookie, or an API key — none of which are cryptographically bound to the TLS connection itself.

Critically, mTLS is not a separate TLS version or a competing protocol. It’s TLS 1.3 (or 1.2) with an additional instruction: the server requests a certificate from the client during the same handshake, and the client has to produce one. The handshake structure doesn’t fundamentally change; what changes is who has to show identification at the door.

What Mutual TLS Adds to the Handshake

Mutual TLS authentication is formalized for OAuth flows in RFC 8705, which defines mutual-TLS client authentication and certificate-bound access tokens. Outside the OAuth context, mTLS is simply a TLS configuration choice: the server sets its handshake to request and require a client certificate, and the client must present one signed by a certificate authority the server trusts.

Because mTLS under TLS 1.3 still fits inside the same one-round-trip handshake structure, it doesn’t automatically add a network round trip the way moving from TLS 1.2 to a hypothetical four-way handshake would. What it adds instead is computational and operational weight: the client has to transmit its certificate chain, the server has to validate that chain, both sides perform an extra signature verification, and somebody has to issue, rotate, and revoke client certificates at scale. That last part is the real cost center, and it’s where most of this comparison’s pricing section lives.

The exact latency penalty is deployment-dependent. It moves with certificate chain length, the signature algorithm in use, whether the proxy terminating TLS does local or remote validation, and how aggressively the client reuses connections. There’s no universal “mTLS adds X milliseconds” figure that holds across every stack, which is why the benchmarks below are presented with their specific test conditions rather than as one flat percentage.

Where the Extra Cost Really Lives: Certificate Lifecycle

Standard TLS has a trivial certificate lifecycle problem: a handful of server certificates per domain, renewed automatically by something like Certbot or a managed load balancer, with almost no human intervention required. mTLS multiplies that problem by the number of clients, devices, or workloads that need to authenticate. A service mesh with 200 microservices needs certificates for all 200. An IoT fleet with 50,000 devices needs 50,000 certificates, plus a way to revoke any one of them instantly if a device is compromised in the field. That operational surface area, not the handshake math, is what actually determines whether mTLS is worth adopting for a given system.

TLS 1.3 vs Mutual TLS: Specs Comparison

The table below lines up the two approaches across the dimensions that matter for an architecture decision: what gets verified, what it costs operationally, and where each one tends to land in production.

AttributeStandard TLS 1.3Mutual TLS (mTLS)
Governing specRFC 8446RFC 8446 + RFC 8705 (OAuth client auth)
Who presents a certificateServer onlyServer and client
Full handshake round trips1-RTT1-RTT (same structure, added payload)
Resumed session0-RTT possible0-RTT possible with cached client identity
Identity verifiedServer domain onlyBoth server and client/workload identity
Certificate issuance volumeOne cert per server/domainOne cert per client, device, or workload
Typical issuerPublic CA (e.g., Let’s Encrypt via ACME)Private CA (internal PKI)
Revocation/rotation burdenLow (few server certs)High (certs scale with client/workload count)
Common deployment layerPublic-facing websites, CDNs, APIsService mesh, internal APIs, IoT fleets, zero trust networks
Browser/client supportUniversal, no extra client configRequires client to hold and present a cert
Failure mode if misconfiguredConnection untrusted, user sees warningConnection rejected on both sides; outages if cert rotation fails
Zero trust alignmentPartial (encrypts transport only)Stronger (verifies both endpoints per NIST SP 800-207)

Two rows are worth dwelling on. The “typical issuer” row is the practical crux of the whole decision: a public CA like Let’s Encrypt is built to hand out certificates to anonymous domains at internet scale for free, while a private CA exists specifically because you don’t want to, and usually can’t, get a public CA to vouch for an internal service name or a device serial number. The “failure mode” row is the one that bites teams in production — a broken public TLS cert shows users a browser warning they can click past; a broken mTLS cert rotation can take down an entire internal traffic path with no user-facing warning page to even look at.

Performance Benchmarks: What the Data Actually Shows

Benchmarking mTLS against plain TLS is harder than it sounds because so few published studies isolate the client-certificate step from everything else happening in a handshake. Here’s what current, dated research actually supports, pulled from three distinct sources rather than a single vendor claim.

SourceWhat it measuredKey figure
2026 TLS handshake benchmarking paperFull TLS 1.3 handshake completion time, classical vs. hybrid post-quantum key exchange5.547ms (X25519) vs. 5.879–6.495ms (hybrid PQC)
Istio documentation (updated October 2026)Default peer-authentication enforcement mode across the meshPERMISSIVE by default; STRICT is opt-in
Google Cloud Service Mesh documentationAutomatic mTLS negotiation behavior since version 1.5Auto mTLS on by default, PERMISSIVE mode

A 2026 TLS handshake benchmarking paper measured median full-handshake completion at approximately 5.547 milliseconds for a standard X25519 key exchange, compared with 5.879 milliseconds and 6.495 milliseconds for two hybrid post-quantum key exchange configurations tested in the same environment. That study measured handshake mechanics generally rather than isolating mTLS specifically, but it establishes the baseline millisecond range that any added certificate-validation step is working against: single-digit milliseconds, not the tens or hundreds of milliseconds that dominate most page-load budgets.

Istio’s own documentation, last updated in October 2026, describes the mesh’s default peer-authentication mode as PERMISSIVE: workloads accept both plaintext and mutual-TLS traffic simultaneously, which lets operators migrate services into mTLS gradually rather than forcing a hard cutover. Switching to STRICT mode rejects any connection that doesn’t present a valid client certificate. Google Cloud’s Service Mesh documentation confirms the same PERMISSIVE default and states that automatic mTLS has been enabled by default since Service Mesh version 1.5, meaning the sidecar proxy detects whether a peer supports mTLS and upgrades the connection automatically without application code changes.

What neither Istio’s nor Google’s documentation provides is a universal CPU-overhead percentage for mTLS termination, and independent benchmarks on that exact metric are thin enough in 2025-2026 literature that citing a specific number here would mean guessing. The honest takeaway from the available data: the handshake-time cost of adding client certificate validation is small relative to total connection setup time, but the operational cost of running a private CA that can issue and rotate potentially thousands of client certificates is the part that actually shows up in budgets and headcount.

It’s also worth noting what the data doesn’t support. Marketing material from PKI vendors sometimes implies mTLS roughly doubles handshake cost, but none of the three sources above back a specific multiplier, and the millisecond-scale numbers from the 2026 handshake paper suggest that even a generous estimate of added certificate-validation overhead stays well under the thresholds that affect user-perceived latency for anything other than extremely high-frequency, low-latency trading-style systems.

Sample Istio Mutual TLS Configuration

Since Istio’s PERMISSIVE default is the reference point most teams start from, it helps to see what flipping a workload to STRICT mTLS actually looks like in configuration. This is a standard PeerAuthentication resource, the same pattern documented in Istio’s own security configuration guides.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: payments
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: legacy-service
  namespace: payments
spec:
  selector:
    matchLabels:
      app: legacy-billing
  mtls:
    mode: PERMISSIVE

The first block enforces STRICT mTLS for every workload in the payments namespace by default. The second block carves out a namespace-level exception for a single legacy service that can’t yet present a client certificate, letting it run in PERMISSIVE mode while every other service in the namespace is locked down. That selector-based override is exactly how teams avoid an all-or-nothing cutover when migrating a large, mixed-maturity service inventory.

Pricing: Running TLS vs Running mTLS at Scale

Standard server-side TLS is close to free at this point. Let’s Encrypt issues domain-validated certificates at no cost through the ACME protocol, and every major cloud provider bundles basic TLS termination into its load balancer pricing. Current AWS Private CA pricing and Cloudflare Access pricing are the two reference points used throughout this section. Mutual TLS changes the economics because now you’re running a certificate authority, not just holding a handful of server certs.

ServiceWhat it coversPrice
Let’s Encrypt (ACME)Public server TLS certificatesFree
AWS Private CA — general-purpose modeIssuing client/workload certs for mTLS, longer validity$400 per CA, per month
AWS Private CA — short-lived certificate modeIssuing short-lived client certs, suited to automated rotation$50 per CA, per month
Cloudflare Access (Zero Trust, pay-as-you-go)Identity-aware access including mTLS, billed annually$7 per user, per month
Cloudflare Access (Free plan)Basic access controlmTLS not included on Free plan
Smallstep step-caOpen-source private CA for internal mTLSFree, self-hosted

The jump from $400 a month to $50 a month between AWS’s general-purpose and short-lived certificate modes is worth sitting with. Short-lived certificates reduce the blast radius of a leaked key because they expire fast, but that only works if your automation can reliably reissue certificates before they lapse. Teams that pick short-lived mode without rock-solid rotation automation tend to discover the tradeoff during an outage, not during planning.

Open-source alternatives like step-ca remove the per-CA monthly fee entirely, but they shift the cost into engineering time: someone has to run, patch, and monitor the CA infrastructure instead of paying AWS or Cloudflare to do it. For small-to-mid-size deployments with a handful of services, that tradeoff usually favors self-hosting. For organizations issuing certificates to thousands of IoT devices or ephemeral containers, the managed services start winning on reliability even before you factor in headcount cost.

Cloudflare’s $7-per-user, pay-as-you-go pricing is also a useful anchor because it prices mTLS as part of a broader Zero Trust access product rather than as a standalone certificate service. That bundling makes sense for organizations that want device-level authentication for employees hitting internal tools, but it’s a poor fit for a pure service-to-service mTLS use case inside a Kubernetes cluster, where a per-seat price has nothing to do with the number of workloads actually authenticating to each other. Matching the pricing model to the actual authentication pattern, rather than defaulting to whichever vendor is easiest to procure, is where a lot of the real savings in this decision live.

Real-World Deployments: Six Examples

Mutual TLS isn’t a theoretical architecture pattern. It’s already running in production across several categories of infrastructure, each with documented defaults you can check yourself.

  • Istio service mesh — ships with mTLS support built in, defaulting to PERMISSIVE mode so services can be migrated to STRICT mTLS enforcement incrementally rather than all at once. The PeerAuthentication resource shown earlier in this piece is the exact mechanism teams use to flip that default per namespace or per workload.
  • Google Cloud Service Mesh — enables automatic mTLS by default starting at version 1.5, with sidecar proxies negotiating encryption and client identity without application changes. This removes the need for developers to write any certificate-handling logic into the services themselves.
  • Cloudflare Access — offers mTLS as part of its Zero Trust product line on Enterprise and pay-as-you-go plans, used by organizations enforcing device-level authentication for internal tools and admin dashboards that shouldn’t be reachable from an arbitrary browser.
  • AWS Private Certificate Authority — used by enterprises to issue and manage the client certificates that make mTLS between internal services and devices operationally possible at cloud scale, with separate pricing tiers for long-lived versus short-lived certificate strategies.
  • Smallstep step-ca deployments — a common choice inside Kubernetes clusters and service meshes where teams want certificate issuance and short-lived rotation without a recurring per-CA fee, trading a managed service for self-hosted operational responsibility.
  • Federal zero trust rollouts — NIST’s SP 1800-35, “Implementing a Zero Trust Architecture,” published June 10, 2025, documents practical zero trust builds that lean on mutual authentication between workloads as one of several required controls, not a standalone fix.

When to Use Standard TLS 1.3

Standard TLS 1.3 remains the right default for anything the public connects to directly. A marketing site, a customer-facing web app, a public REST API consumed by third-party developers who can’t realistically be expected to provision and manage a client certificate — all of these should stay on one-way TLS. Forcing client certificates onto a general public audience creates a support burden that outweighs the security benefit, since most attacks against public-facing services target application logic, credentials, or dependencies rather than the TLS handshake itself.

One-way TLS is also the right call when the client population is large, diverse, and outside your administrative control. You can’t mandate a client certificate on every browser that might load your checkout page. You can mandate one on every microservice you operate inside your own VPC. That distinction, who controls the client, is the single most useful filter for deciding which side of this comparison a given connection belongs on.

There’s also a cost argument for staying on standard TLS wherever mTLS isn’t clearly justified. Every certificate you issue is something your team has to track, renew, and eventually revoke. Adding that overhead to a connection that doesn’t need stronger authentication just because mTLS feels more secure in the abstract is how security initiatives quietly turn into unmanageable PKI sprawl a year later.

When Mutual TLS Earns Its Complexity

mTLS pays for itself when both ends of a connection are entities you control or can enroll into a PKI: service-to-service traffic inside a Kubernetes cluster, device-to-cloud traffic from a fleet of IoT sensors you manufactured, API traffic between two companies that have already exchanged certificates as part of a B2B integration contract, or any internal admin tool where “anyone with the URL and a password” isn’t an acceptable trust model anymore.

It’s also the right fit anywhere a breach of one service shouldn’t automatically grant lateral movement to every other service on the same network. That’s the core zero trust argument NIST SP 800-207 makes: stop trusting traffic just because it originated inside your perimeter, and instead verify identity on every connection, including internal ones. mTLS is one practical mechanism for doing that verification at the transport layer, though NIST’s own guidance is explicit that mTLS alone doesn’t constitute a complete zero trust architecture — it still needs to sit alongside authorization policy, segmentation, and continuous monitoring.

A good rule of thumb for engineering leads evaluating this decision: if a compromised credential at the client would still let an attacker reach the server undetected, mTLS closes a real gap. If the client is already anonymous and untrusted by design, like a public website visitor, mTLS has nothing extra to verify and just adds friction.

Five Use-Case Recommendations

  • Public website or SaaS frontend: standard TLS 1.3 only. Adding mTLS here just breaks browser compatibility for no security gain against your actual threat model, since the vast majority of public-facing breaches target credentials and application logic, not the TLS handshake.
  • Kubernetes service mesh: mTLS via Istio or Linkerd in PERMISSIVE mode first, then STRICT once every workload is confirmed to support it. Use namespace-scoped PeerAuthentication resources to carve out exceptions for legacy services during the transition.
  • Partner or B2B API integration: mTLS with certificates issued through a private CA like AWS Private CA or step-ca, since both sides are known, finite, and willing to manage a cert as part of a signed integration agreement.
  • IoT device fleet: mTLS with short-lived certificates where possible, since devices are harder to patch quickly if a long-lived key leaks, and automated reissuance limits how long a stolen credential stays useful.
  • Internal admin dashboards and infrastructure tooling: mTLS through a product like Cloudflare Access, layering device-level certificate checks on top of normal authentication so a stolen password alone can’t grant access from an unenrolled machine.

Migration Guide: Moving From TLS to mTLS

Teams that try to flip every internal service to STRICT mTLS in one deployment usually cause an outage. The migration pattern that shows up repeatedly in service mesh documentation and practitioner write-ups follows a staged rollout instead, moving one layer of risk at a time rather than all of them simultaneously.

  • Step 1 — Inventory your internal traffic. Map which services talk to which, and note anything still running plain HTTP internally. You can’t secure a connection you don’t know exists.
  • Step 2 — Stand up a private CA. Choose between a managed option like AWS Private CA and a self-hosted option like step-ca based on your certificate volume, team size, and tolerance for operating your own PKI infrastructure.
  • Step 3 — Issue certificates to a small pilot group. Start with two or three low-risk internal services, not anything customer-facing, so you can validate the issuance and renewal workflow before it matters.
  • Step 4 — Deploy in permissive mode. Configure the mesh or proxy (Istio’s PERMISSIVE mode is the reference example) so services accept both mTLS and plaintext simultaneously during transition, giving you a rollback path at every stage.
  • Step 5 — Monitor for handshake failures. Watch for clients that fail to present valid certificates; these are services you missed in your inventory or automation that hasn’t been updated to request a cert yet.
  • Step 6 — Automate rotation before going strict. Certificate expiry is the single most common cause of mTLS outages. Confirm automated reissuance works under load, including failure retries, before removing the plaintext fallback.
  • Step 7 — Flip to strict mode service by service. Move to STRICT enforcement one service or namespace at a time rather than mesh-wide, so a single misconfiguration doesn’t take down everything at once.
  • Step 8 — Extend to external partners last. Internal migration risk is fully within your control; partner integrations depend on another organization’s timeline and certificate infrastructure, so sequence those after your own house is in order.

Pros and Cons: Standard TLS 1.3

Pros:

  • Universal client compatibility with every browser and HTTP client without extra configuration.
  • Free certificates via Let’s Encrypt and the ACME protocol, with automated renewal.
  • Single round-trip handshake, with zero-round-trip resumption available for repeat connections.
  • Decades of battle-tested tooling, library support, and operational familiarity across every major platform.

Cons:

  • Verifies only the server, so a stolen session token or compromised client still looks legitimate to the server.
  • Provides no defense against lateral movement once an attacker is inside the network perimeter.
  • Doesn’t on its own satisfy zero trust identity requirements for internal, service-to-service traffic.

Pros and Cons: Mutual TLS

Pros:

  • Verifies both endpoints, directly supporting zero trust architecture goals under NIST SP 800-207.
  • Limits lateral movement, since compromised credentials alone aren’t enough without a valid client certificate.
  • Works transparently once automated inside a service mesh like Istio or Google Cloud Service Mesh, with no code changes required.
  • Pairs well with short-lived certificates to shrink the window a stolen key stays useful.

Cons:

  • Requires standing up and maintaining a private CA, whether managed or self-hosted.
  • Adds certificate issuance and rotation as an ongoing operational task that scales with client count.
  • Can cause hard outages if certificates expire without renewal, with no user-facing warning page to fall back on.
  • Incompatible with arbitrary public clients like browsers without custom certificate installation.
  • Costs real money at scale: $400 per month per AWS Private CA in general-purpose mode, plus usage-based issuance fees.

Common Mistakes Teams Make Adopting mTLS

Most mTLS rollouts that go badly fail for operational reasons, not cryptographic ones. The protocol math is solid; the certificate lifecycle management around it is where teams stumble.

  • Going straight to STRICT mode. Skipping the PERMISSIVE transition period removes the rollback path and turns any missed service into an immediate outage instead of a warning in the logs.
  • Treating certificate rotation as a manual process. A private CA that depends on someone remembering to renew certificates before expiry will eventually fail; automated reissuance tied to a short validity window is what makes short-lived certificate mode actually safe to use.
  • Applying mTLS to public-facing traffic. Requiring a client certificate from anonymous browser traffic breaks compatibility for a population of users who have no practical way to obtain one, and solves a threat model that mTLS was never designed to address.
  • Underestimating certificate volume growth. A pricing model that looks cheap at 50 workloads can look very different at 5,000, particularly if the CA tier chosen charges per issuance rather than a flat monthly rate.
  • Skipping the inventory step. Flipping a namespace to STRICT mode without first mapping every service that talks to it is the single most common cause of mTLS-related outages reported in service mesh migration write-ups.

The Verdict

Standard TLS 1.3 and mutual TLS aren’t competing standards fighting for the same job. TLS 1.3 is the floor: every connection, public or private, should run on it, full stop. mTLS is an addition you layer on top for the specific slice of traffic where both ends are known, enrollable, and worth the operational cost of a private CA.

The data backs a narrow, practical rule: if the client is the general public, stay on one-way TLS 1.3. If the client is a service, device, or partner you control or contract with, and the traffic matters enough to justify a $400-a-month private CA and a rotation pipeline, move it to mTLS, starting in permissive mode and only flipping to strict enforcement once rotation automation is proven. Istio and Google Cloud Service Mesh both ship with that exact staged default for a reason — it’s the path least likely to end in a 3 a.m. outage.

For most organizations, the realistic end state isn’t “TLS everywhere” or “mTLS everywhere.” It’s TLS 1.3 at the edge, facing the public, and mTLS inside the perimeter, facing your own services, devices, and trusted partners, with the boundary between the two drawn exactly where anonymous traffic stops and enrollable traffic starts.

Key Terms to Know

A handful of terms show up constantly in this comparison and are worth defining plainly before implementing either approach.

  • Certificate authority (CA): an entity that signs certificates, vouching that a given public key belongs to a given identity. Public CAs like Let’s Encrypt serve the entire internet; private CAs like AWS Private CA or step-ca serve only the organization that runs them.
  • ACME: the automated protocol, defined in RFC 8555, that lets services like Let’s Encrypt issue and renew certificates without manual steps. Most public TLS certificates today are issued through ACME.
  • PKI (public key infrastructure): the combined set of policies, roles, and systems — CAs, certificate stores, revocation lists — needed to issue, distribute, and revoke certificates. Running mTLS at scale means running a PKI, whether you built it or rented it.
  • PeerAuthentication: the Istio resource type that controls whether a workload accepts plaintext, mTLS, or both, as shown in the configuration example earlier in this piece.
  • Zero trust architecture: the security model described in NIST SP 800-207, which assumes no connection should be trusted by default, including internal ones, and requires continuous verification of identity, device posture, and policy at every access point.
  • Sidecar proxy: a small network proxy deployed alongside each service in a mesh like Istio, responsible for handling the TLS and mTLS handshake transparently so the application code never has to manage certificates directly.

Frequently Asked Questions

Is mTLS more secure than standard TLS?

For internal and service-to-service traffic, yes — mTLS verifies both the server and the client, closing the gap where a server has no way to confirm who’s actually connecting. For public-facing traffic where the client is an anonymous browser, standard TLS 1.3 is the only practical option, since you can’t require a certificate from every visitor.

Does mTLS slow down connections?

Under TLS 1.3, mTLS keeps the same one-round-trip handshake structure as standard TLS; it adds certificate transmission and validation overhead rather than an extra network round trip. The exact cost varies by certificate chain size and infrastructure, and no universal millisecond figure applies across every deployment, though published 2026 handshake benchmarks suggest the added cost stays in the single-digit-millisecond range.

Can I use mTLS with a regular web browser?

Technically yes, if the user installs a client certificate in their browser, but this is impractical for general public websites. mTLS is almost always used for service-to-service, device-to-cloud, or controlled B2B traffic rather than ordinary consumer browsing.

What’s the difference between TLS 1.3 and mTLS?

TLS 1.3 is a protocol version defined in RFC 8446. mTLS is a configuration choice within TLS — either 1.2 or 1.3 — where the server also requires the client to present a certificate. They aren’t alternatives; mTLS is built on top of a TLS version like 1.3, not a replacement for it.

How much does it cost to run mTLS at scale?

Using AWS Private CA, general-purpose mode runs $400 per CA per month, while short-lived certificate mode runs $50 per CA per month, plus usage-based issuance costs. Self-hosted open-source options like Smallstep’s step-ca avoid the recurring fee but require engineering time to operate, patch, and monitor.

Do Istio and other service meshes require mTLS by default?

No. Istio’s default PeerAuthentication mode is PERMISSIVE, meaning it accepts both plaintext and mTLS traffic, which lets teams migrate gradually. Google Cloud Service Mesh follows the same PERMISSIVE default since version 1.5. STRICT mode, which requires mTLS exclusively, is an explicit configuration choice teams opt into.

Is mTLS the same thing as zero trust?

No. mTLS is one mechanism that supports zero trust principles by verifying both connection endpoints. NIST SP 800-207 and the June 2025 SP 1800-35 implementation guidance both describe zero trust as requiring additional controls — authorization policy, segmentation, continuous monitoring — beyond transport-layer authentication alone.

Should a new startup bother with mTLS?

Only once there’s meaningful internal service-to-service traffic worth protecting beyond the perimeter, or a specific partner or compliance requirement demanding it. Standing up a private CA before you have more than a couple of internal services is usually premature operational overhead; standard TLS 1.3 everywhere, plus normal application-layer authentication, covers most early-stage needs.