For years, a convenient shortcut has quietly held together a lot of machine-to-machine authentication: organizations reused their public TLS certificates for mutual TLS. A certificate issued for a web server often carried both the server authentication and client authentication extended key usages, so the same certificate that secured a public endpoint could also authenticate a client in an mTLS handshake. That shortcut is about to stop working, and the systems that depend on it will fail not with a warning but on their next renewal.
This article explains the clientAuth EKU cliff, why it exists, exactly when it bites, and what to do about it. The answer for most affected organizations is to stop borrowing public certificates for client authentication and stand up a private PKI built for the purpose. We will cover the timeline, the technical reason public and private trust are diverging, the risks of inaction, and a practical path to building private-PKI mTLS before the deadline.
Why This Matters Now
Three forces make this urgent rather than theoretical. The public CAs that issue most TLS certificates are removing the clientAuth EKU through 2026, Chrome is completing its move to dedicated server-only hierarchies, and the failures land silently on renewal rather than on any single announced date. Together they turn a quiet configuration detail into a deadline that arrives certificate by certificate.
Chrome sets the deadlines
Google’s Chrome Root Program is driving the change through its move to dedicated, server-only TLS hierarchies. Under Chrome Root Program policy, any new intermediate (subordinate) CA certificate must carry the serverAuth EKU only from June 15, 2026, and every newly issued leaf certificate must be serverAuth-only from March 15, 2027, the point at which Chrome stops trusting public TLS certificates that carry the clientAuth EKU. Certificates issued before those dates remain valid until they expire, which is what makes this a slow-motion cliff: nothing breaks on the deadline itself, but every renewal after it strips out the capability that mTLS relied on.
The CAs move even earlier
The practical deadline is sooner than Chrome’s leaf date, because several certificate authorities are removing the EKU well ahead of it. Let’s Encrypt eliminates the clientAuth EKU from certificates issued on or after May 13, 2026, and Sectigo removes it by May 15, 2026. DigiCert stopped including it by default on October 1, 2025, now issues it only on explicit request, and will remove it entirely on March 1, 2027. The effective deadline is therefore set by whichever CA issues your certificate, not by Chrome’s headline date: if your mTLS depends on a Let’s Encrypt or Sectigo certificate that renews after mid-May 2026, it can break months before Chrome’s enforcement, because the renewed certificate simply will not carry clientAuth.
This is part of a deliberate move to dedicated hierarchies
The change is not arbitrary. It reflects an industry-wide shift toward dedicated, single-purpose PKI hierarchies, presented through the Chrome Root Program’s policy updates. The intent is to eliminate multipurpose certificate trust chains to improve the security of server certificates and simplify their management. The era of one certificate serving many purposes is ending by design. The direction was set at the CA/Browser Forum’s October 2024 discussions and formalized in successive Chrome Root Program policy versions, and the other major root programs, including Apple and Mozilla, are expected to align, so this is an industry trajectory rather than one vendor’s preference.
How mTLS and the clientAuth EKU Work
Before planning the migration, it helps to understand what the extended key usage controls, why mutual TLS is the specific thing that breaks, and why private PKI is exempt. The sections below take each in turn, along with why public trust was the wrong tool for internal client authentication in the first place.
What the EKU does
The extended key usage is a certificate extension that declares what a certificate may be used to authenticate. Two values are central here, and they are identified by object identifiers: server authentication, id-kp-serverAuth, is OID 1.3.6.1.5.5.7.3.1, and client authentication, id-kp-clientAuth, is OID 1.3.6.1.5.5.7.3.2. For years, public TLS certificates were issued with both extended key usages, which is exactly what allowed a single certificate to act as both a server’s identity and a client’s identity in mutual TLS. Browsers only ever check the serverAuth EKU to establish an HTTPS connection, so removing clientAuth from public server certificates costs nothing for ordinary web serving while closing a real misuse path.
Why mutual TLS is the thing that breaks
In ordinary TLS, only the server presents a certificate; the client authenticates by other means or not at all. In mutual TLS, both ends present certificates, and the client’s certificate must assert the clientAuth EKU to be accepted as a client identity. Organizations that reused their public, dual-EKU server certificates for the client side of mTLS, or for server-to-server authentication, were leaning on the clientAuth value being present. Once CAs stop including it, a renewed certificate carries serverAuth only, and the mTLS handshake that expected a client EKU fails. The change impacts organizations that use server certificates for client-authentication purposes such as mutual TLS and server-to-server authentication. Mutual TLS is now the default authentication primitive in zero-trust and service-mesh architectures, and in distributed systems such as Kafka, Cassandra, and API gateways where certificate rotation is automated, a single renewal can cascade into authentication failures across an entire cluster.
The critical exemption: private PKI is unaffected
The single most important technical fact for planning is that this change applies only to publicly trusted certificates. The exemption is explicit: these changes have no impact on private PKI client authentication, because they affect only publicly trusted certificates. A private certificate authority, one whose root is trusted only within your own environment rather than by public browsers, can issue certificates with the clientAuth EKU freely. The cliff is a public-trust phenomenon, and private PKI is the designed way around it. A private CA can run on platforms such as Microsoft AD CS, HashiCorp Vault, AWS Private CA, or a managed service, and client certificates can be enrolled and renewed automatically through EST, ACME, or SCEP, which is what keeps short-lived client certificates practical at scale.
Why public trust was the wrong tool for mTLS anyway
The change is also a correction. Public certificates were never the right vehicle for internal client authentication, and the broader certificate ecosystem has been making that point. DigiCert’s own guidance on reducing revocation risk argues for moving connected devices and internal services off public trust, noting that there is no five-day revocation timeline for privately trusted certificates and that internal apps and private-network device communication do not require public trust. Using public certificates for mTLS exposed internal systems to public-CA revocation events and root program policy changes that have nothing to do with the internal use case. Private PKI removes that coupling entirely. It also positions internal authentication for the wider shift to short-lived certificates and automated issuance, where manual certificate handling is no longer viable.
Risks and Pitfalls
The clientAuth cliff creates risk both for those who do nothing and for those who migrate hastily. The table below sets out where each path tends to go wrong.
| Risk | Cause | Consequence |
|---|---|---|
| Silent failure on renewal | Public cert renews without the clientAuth EKU after the issuing CA drops it. | mTLS handshakes fail; service-to-service auth breaks. |
| Hidden dependence | No inventory of where public certs are used for mTLS. | Breakage in systems nobody knew relied on the shortcut. |
| Rushed migration | Discovering the dependence only at renewal time. | Emergency cutover with little testing and high error risk. |
| Public-trust coupling | Internal mTLS tied to public-CA policy and revocation. | Internal outages caused by external CA events. |
| Unmanaged private CA | Standing up private PKI without lifecycle discipline. | New key sprawl and an unmonitored internal trust root. |
The danger is that the dependence is invisible
The hardest part of the clientAuth cliff is not the fix; it is knowing where you are exposed. Reuse of public certificates for mTLS is often undocumented, set up years ago by a team that has since moved on, and embedded in service-to-service links that work fine right up until a renewal removes the EKU. Without an inventory that records which certificates carry clientAuth and where they are used as client identities, an organization cannot know which systems will break on their next renewal until they do. Discovery is the first and most urgent task.
Financial services and similar sectors are disproportionately affected
Some industries lean on this pattern more than others. The change particularly affects sectors such as financial services and technology services that use server certificates for client-authentication purposes, and organizations in these sectors should treat the discovery exercise with urgency. For those that genuinely need publicly rooted client authentication across organizational boundaries, a dedicated X9 PKI, governed by ASC X9 standards and operated outside the Chrome Root Store, can still issue certificates carrying both EKUs, and it is being adopted in the financial sector for exactly this purpose.
Implementation Best Practices
Building private-PKI mTLS before the cliff is a contained project if it starts with discovery and ends with automation. The seven steps below run in sequence, because you cannot scope what you have not discovered, and you cannot cut over safely what you have not first tested.
- Discover every mTLS dependence on public certificates: Inventory which certificates carry the clientAuth EKU and where they are used as client identities or for server-to-server authentication. This tells you the exact scope of what will break and by when, based on each certificate’s renewal date. Encryption Consulting’s CBOM Secure automates this discovery, cataloguing every certificate, the EKUs it carries, and the systems that depend on it.
- Confirm renewal dates against the CA deadlines: Map each affected certificate’s renewal against its issuing CA’s removal date, May 13 for Let’s Encrypt and May 15 for Sectigo, with DigiCert issuing clientAuth only on request until its March 1, 2027 removal, so you know which dependencies have the least runway.
- Stand up a private CA for client authentication: Establish a private PKI whose root is trusted only within your environment, and issue client certificates carrying the clientAuth EKU from it. Private PKI is explicitly unaffected by the public-trust change and is the intended path for internal mTLS. Encryption Consulting’s PKI-as-a-Service provides exactly this, a governed private CA that issues clientAuth certificates without the burden of building and running the infrastructure.
- Separate server and client trust cleanly: Keep public, serverAuth-only certificates for public-facing servers, and use private client certificates for the client side of mTLS, embracing the dedicated-hierarchy model rather than fighting it. In practice that means a public, serverAuth-only certificate on the load balancer and a private, clientAuth certificate on every service that authenticates as a client.
- Protect the private root and automate issuance: Anchor the private CA’s signing keys in an HSM and use an automated enrollment protocol such as EST or ACME so that short-lived client certificates are issued and renewed without manual effort. A private CA without lifecycle automation simply trades one problem for another. HSM-as-a-Service anchors the private root in validated hardware, and CertSecure Manager automates issuance and renewal so short-lived client certificates never lapse.
- Migrate and validate before the renewal date: Cut each mTLS dependency over to private client certificates and test the handshake end to end well before the public certificate would renew without the EKU, so the change is planned rather than triggered by an outage.
- Govern the private PKI like production infrastructure: Maintain an inventory of issued client certificates, enforce ownership and rotation, and monitor the private root, so the new PKI does not become a fresh source of unmanaged trust. CertSecure Manager provides this governance from one place, with a live inventory of issued client certificates plus ownership, rotation, and monitoring.
How Encryption Consulting Can Help
Surviving the clientAuth cliff cleanly comes down to three things: finding where public certificates are used for mTLS, replacing them from a governed private CA, and automating issuance so the new client certificates renew themselves. This is exactly where Encryption Consulting’s PKI-as-a-Service fits. It provides a fully managed private certificate authority that issues clientAuth certificates under your control, with the profile control, issuance policy, and lifecycle management that internal mTLS needs, and without the burden of building and operating a CA from scratch.
Around the private CA, the same engagement draws on a coordinated set of Encryption Consulting services, each playing a distinct role:
- PKI-as-a-Service provides the fully managed private certificate authority that issues clientAuth certificates under your control, with the profile control, issuance policy, and lifecycle management that internal mTLS needs, without the burden of building and running a CA from scratch.
- CBOM Secure discovers every hidden mTLS dependence on public trust, cataloguing each certificate, the EKUs it carries, and the systems that depend on it, so you know the exact scope of what will break and by when.
- CertSecure Manager automates certificate issuance and renewal across public and private CAs and keeps a live inventory with ownership, rotation, and monitoring, so short-lived client certificates never lapse and the private PKI stays governed.
- HSM-as-a-Service anchors the new internal root of trust in validated hardware, protecting the private CA’s signing keys without deploying and maintaining new appliances.
The unifying principle is that internal authentication should rest on infrastructure you control, governed and automated and decoupled from public-CA policy, so a change like the clientAuth cliff becomes a non-event rather than an outage. To map your exposure and stand up private-PKI mTLS before your next renewal, talk to Encryption Consulting about a certificate discovery and private-PKI assessment.
Conclusion
The clientAuth EKU cliff is a textbook example of a convenient shortcut coming due. Reusing public TLS certificates for mutual TLS worked for years, but the industry’s move to dedicated, single-purpose hierarchies has ended it. Chrome will stop trusting public certificates that carry the clientAuth EKU, with intermediate hierarchies going server-only from June 15, 2026, and leaf certificates from March 15, 2027, and because several CAs remove the EKU earlier in 2026, mTLS that depends on the shortcut will break on its next renewal, quietly and without warning.
The fix is well defined: discover where you depend on public certificates for client authentication, stand up a private PKI that can issue clientAuth certificates freely because it is unaffected by the public-trust change, separate server and client trust, and automate issuance so the new client certificates renew themselves. Start with discovery now, because your effective deadline is set by whichever CA renews your certificates, not a single headline date. Build private-PKI mTLS deliberately before the cliff, and the change becomes a planned modernization toward infrastructure you control rather than an outage you did not see coming.
