Build a Private PKI for mTLS Before Public Certificates Drop clientAuth

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.

Quick Answer: What Is the clientAuth EKU Cliff and How Do You Avoid It?

Public CAs are removing the clientAuth EKU (OID 1.3.6.1.5.5.7.3.2) from publicly trusted TLS certificates through 2026. mTLS systems that reused public dual-EKU certificates for client authentication will fail silently on renewal. Private PKI is explicitly exempt from the change and can issue clientAuth certificates freely. Effective deadlines: Let’s Encrypt May 13, 2026; Sectigo May 15, 2026; DigiCert March 1, 2027; Chrome leaf enforcement March 15, 2027.

Key Takeaways

• The clientAuth EKU cliff is set by whichever CA renews your certificates, not by Chrome’s headline date. Let’s Encrypt removes clientAuth from certificates issued on or after May 13, 2026; Sectigo removes it by May 15, 2026; DigiCert stopped including it by default on October 1, 2025 and will remove it entirely on March 1, 2027. Chrome’s leaf certificate enforcement date is March 15, 2027. Systems depending on a Let’s Encrypt or Sectigo certificate that renews after mid-May 2026 can break months before Chrome’s enforcement date.
• Private PKI is explicitly unaffected by the public-trust change. The exemption is technically explicit: the clientAuth EKU removal applies only to publicly trusted certificates. A private CA whose root is trusted only within the organization’s own environment can issue certificates carrying the clientAuth EKU freely, with no CA/Browser Forum or Chrome Root Program restriction. Private PKI is not a workaround; it is the designed solution.
• The DigiCert Trust Pulse Survey (July 2025) found that 45 percent of enterprises experienced certificate-related downtime in the prior year. Silent EKU removal on renewal, where mTLS breaks because a renewed certificate no longer carries clientAuth, is a form of that same downtime pattern. The mTLS failure arrives without warning because the renewed certificate is otherwise valid.
• Discovery is the first and most urgent task. Reuse of public certificates for mTLS is often undocumented, set up years ago by teams that have since moved on, and embedded in service-to-service links that work fine until a renewal removes the EKU. Without a certificate inventory that records which certificates carry clientAuth and where they are used as client identities, an organization cannot scope the migration.
• Standing up private PKI without lifecycle automation trades one problem for another. A private CA that issues client certificates manually produces certificate sprawl and an unmonitored internal trust root. Automated enrollment via EST, ACME, or SCEP and CLM platform coverage from day one are prerequisites for a private PKI that stays governed at scale. For post-quantum algorithm migration planning for private client certificate profiles following NIST FIPS 203, 204, and 205 (August 13, 2024), check the PQC Center of Excellence.

Who Should Care About the clientAuth EKU Migration

The clientAuth EKU cliff touches every team responsible for mTLS, certificate governance, service authentication, and infrastructure security. A failure to migrate before an issuing CA’s removal deadline produces silent mTLS authentication failures that are difficult to diagnose without prior knowledge of the EKU change.

Role	Why It Matters	Action Item
PKI and Certificate Teams	Own the private CA design and deployment: selecting the CA platform, defining the clientAuth certificate profile with the correct EKU (OID 1.3.6.1.5.5.7.3.2), configuring HSM-backed key storage for the private root, and setting up automated enrollment via EST, ACME, or SCEP; also own the discovery of existing public certificates carrying clientAuth across the certificate estate before migration can be scoped	Run a full certificate inventory using CBOM Secure to identify all certificates carrying the clientAuth EKU and their renewal dates; design the private CA hierarchy with a dedicated clientAuth issuing CA separate from the server CA hierarchy; configure automated enrollment before migrating any mTLS service; add all issued private client certificates to CertSecure Manager from day one
Security Architects	Own the trust model design: defining which systems trust the new private root, ensuring the private root is not inadvertently distributed to public trust stores, separating the private client CA hierarchy from the public server CA hierarchy, and aligning the private CA design with zero-trust architecture principles; the change from public dual-EKU certificates to dedicated private client certificates is also an opportunity to adopt short-lived client certificates and automated rotation	Design a dedicated private CA hierarchy for clientAuth that is separate from the public server CA hierarchy; specify that the private root must not be distributed to public browsers or external devices; define the client certificate validity period and rotation policy using automated enrollment; include the private CA cryptographic inventory in CBOM Secure; plan post-quantum algorithm adoption for private client certificate profiles through PQC Readiness assessment
Platform and DevOps Teams	Own integrating the private CA enrollment into service provisioning pipelines and updating mTLS configurations to use private client certificates instead of public dual-EKU certificates; in distributed systems such as Kafka, Cassandra, and API gateways where certificate rotation is automated, a single renewal without the expected clientAuth EKU can cascade into authentication failures across an entire cluster if the migration is incomplete before the CA deadline	Audit all service provisioning pipelines and mTLS configurations for references to public certificates used as client identities; update each pipeline to request certificates from the new private CA via EST or ACME; test mTLS handshakes end-to-end with private client certificates before cutting over production services; add mTLS handshake success rate monitoring to platform observability alerting
Compliance Teams	Must demonstrate that the migration is complete before the issuing CA’s clientAuth removal deadline; CA/Browser Forum Ballot SC-081v3 (approved April 14, 2025) and Chrome Root Program Policy v1.8 (effective June 15, 2026 for subordinate CAs, March 15, 2027 for leaf certificates) are the governing policy documents; a production environment where mTLS continues to depend on public dual-EKU certificates after the CA’s removal deadline is a compliance gap against published industry policy	Include clientAuth EKU migration completion in the PKI compliance evidence package with deadline dates mapped against each issuing CA’s removal timeline; confirm that the private CA CP/CPS documents the clientAuth certificate profile and issuance policy; include private client certificate populations in the quarterly certificate compliance review
CISOs	Internal mTLS authentication that depends on public-CA policy is coupled to external CA events and root program decisions that have nothing to do with internal security requirements; the clientAuth cliff is the industry’s mechanism for enforcing the separation of server and client trust hierarchies; organizations that complete the migration gain a private authentication infrastructure they fully control, decoupled from public-CA revocation events and root program policy changes; post-quantum migration planning for private client certificate algorithms is the next horizon	Fund the clientAuth EKU migration as a dedicated program with named owners for discovery, private CA deployment, service migration, and CLM governance; require that PKI as a Service is evaluated for organizations that need a governed private CA without building and operating the infrastructure internally; mandate that the private CA is covered by CLM tooling from day one; track post-quantum migration planning for private client certificates through the PQC Center of Excellence

clientAuth EKU Migration Checklist: Issue, Business Impact, Recommended Action, and Owner

Use this checklist to identify which migration gaps apply to your environment, understand the business impact of inaction, and assign remediation ownership before an issuing CA’s removal deadline produces a silent mTLS failure.

Issue	Business Impact	Recommended Action	Owner
No certificate inventory identifying which public certificates carry the clientAuth EKU	Cannot scope the migration; undiscovered mTLS dependencies break on renewal after the CA deadline with no advance warning; emergency discovery under production pressure is high-risk	Run a full certificate discovery using CBOM Secure to catalogue every certificate, the EKUs it carries, and the systems that depend on it; map each clientAuth-carrying certificate’s renewal date against its issuing CA’s removal deadline to prioritize migration order	PKI Team
No private CA deployed for clientAuth issuance	No compliant alternative exists when the public CA removes the EKU; all mTLS dependencies on public dual-EKU certificates will break on renewal with no replacement certificate source	Deploy a private CA hierarchy with a dedicated clientAuth issuing CA separate from the server CA hierarchy; use a managed PKIaaS offering to accelerate deployment if internal CA infrastructure build time exceeds the migration deadline	PKI Team + Security Architect
Private CA root not protected by HSM-backed key storage	Compromise of an unprotected private CA root invalidates all client certificates issued under it; recovery requires reissuing all client certificates and redistributing the new root to all trusting systems	Anchor the private CA root signing key in a FIPS 140-3 Level 2 or higher validated HSM or use an HSM-backed PKIaaS offering; mark the root private key non-exportable	PKI Team + Security Architect
No automated enrollment configured for private client certificates	Manual private client certificate management at scale fails the same way manual public certificate management does; certificate sprawl, missed renewals, and unmonitored expiry produce the same outages the migration was intended to prevent	Configure EST, ACME, or SCEP enrollment for all private client certificate populations before migrating mTLS services; integrate enrollment into service provisioning pipelines so private client certificates are issued and renewed automatically with no manual steps	PKI Team + Platform Team
mTLS service configurations not updated to use private client certificates	Even after the private CA is deployed, services still configured to present public dual-EKU certificates as client identities will break on their next renewal when the public certificate no longer carries clientAuth	Audit all mTLS service configurations and update each to present a private client certificate from the new private CA; test the mTLS handshake end-to-end with the private client certificate before cutting over production; confirm both ends of each mTLS connection trust the private root	Platform Team
Private client certificates not in CLM platform inventory	Without CLM coverage, private client certificate expiry events produce the same silent failures after the migration that the public certificate EKU removal produced before it; the new private PKI becomes a new source of unmonitored certificates	Add all private client certificates to CertSecure Manager with expiry monitoring and renewal alerts from the first day of issuance; confirm renewal automation is active for all private client certificate populations before migrating production services	PKI Team
Private CA root inadvertently distributed to public trust stores or external devices	A private CA root in a public trust store allows the private CA to issue certificates trusted by external parties, expanding the blast radius of any CA compromise and violating the private-trust model the migration is designed to establish	Confirm the private CA root is distributed only to internal systems under organizational control; audit trust store configuration on all devices and services that were updated to trust the private root; do not submit the private root to any public root program	Security Architect
No quarterly review of new public certificates carrying clientAuth added after migration	New services deployed after the migration may reintroduce public dual-EKU certificate dependencies that were not present at migration time; without a quarterly audit, the dependency rebuilds invisibly until the next renewal failure	Schedule quarterly certificate inventory scans to identify any new public certificates carrying the clientAuth EKU added since the last review; include this check in the quarterly PKI compliance evidence package	PKI Team + Compliance Team

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.

Frequently Asked Questions

What is the main takeaway from Build a Private PKI for mTLS Before Public Certificates Drop clientAuth?

Public CAs are removing the clientAuth EKU (OID 1.3.6.1.5.5.7.3.2) from publicly trusted TLS certificates through 2026. Let’s Encrypt from May 13, 2026; Sectigo from May 15, 2026; DigiCert by March 1, 2027. mTLS systems that reused public dual-EKU certificates for client authentication will fail silently on renewal when the renewed certificate no longer carries clientAuth. Private PKI is explicitly unaffected and is the designed solution: a private CA can issue clientAuth certificates freely because its root is not in the public browser trust store.

Why does the clientAuth EKU removal matter for enterprise PKI teams?

Enterprise PKI teams that have not inventoried which public certificates carry clientAuth face silent mTLS failures on renewal with no warning. The DigiCert Trust Pulse Survey (July 2025) found that 45 percent of enterprises experienced certificate-related downtime in the prior year; silent EKU removal on renewal is a form of that same downtime. The change also requires standing up private PKI infrastructure that many organizations have never formally designed, turning a certificate renewal event into an infrastructure project with a deadline set by whichever CA renews certificates first.

What risks increase if the clientAuth EKU migration is handled manually or reactively?

Four specific risks increase: hidden dependency discovery failure (without a certificate inventory, an organization cannot scope the migration); emergency cutover risk (discovering the dependency at renewal time forces an emergency migration with little testing); unmanaged private CA risk (a private CA without lifecycle automation creates unmonitored certificate sprawl); and cascade failure in automated environments (in systems like Kafka and API gateways, a single renewal without the expected clientAuth EKU can cascade into authentication failures across an entire cluster).

Which teams should own the clientAuth EKU migration to private PKI?

PKI and certificate teams own the private CA design, clientAuth certificate profile, HSM-backed root key storage, and automated enrollment via EST, ACME, or SCEP. Security architects own the trust model: dedicated private CA hierarchy separate from the server CA, private root trust scope, and zero-trust alignment. Platform and DevOps teams own updating service provisioning pipelines and mTLS configurations to use private client certificates. Compliance teams own evidence that migration is complete before each CA’s removal deadline. CISOs own the governance mandate that migration is a funded, tracked program.

How does the clientAuth EKU migration connect to certificate lifecycle management?

The migration requires two distinct CLM capabilities: discovery (identifying which certificates carry clientAuth and where they are used as client identities) and ongoing governance (tracking private client certificates with expiry monitoring, renewal automation, and ownership metadata). CertSecure Manager provides both: certificate discovery cataloguing EKUs and dependent systems, and automated issuance and renewal for short-lived private client certificates so they never lapse after the migration.

How should organizations measure success in the clientAuth EKU migration?

Key metrics: discovery completeness (all certificates carrying clientAuth identified with renewal dates mapped against CA removal deadlines); migration completeness (all mTLS dependencies migrated to private client certificates before the issuing CA’s deadline, zero systems breaking on renewal after the deadline); private CA inventory coverage (all private client certificates in CLM platform with expiry monitoring and renewal automation active); and zero unplanned mTLS authentication failures attributable to the EKU removal after migration is complete.

What should be audited or monitored regularly after migrating to private PKI for mTLS?

Monitor continuously: private client certificate expiry with renewal alerts; private CA root and intermediate validity and revocation status; and mTLS handshake success rates on migrated services. Audit quarterly: scan for any new public certificates carrying clientAuth added since the last audit; confirm private CA enrollment automation is functioning; verify the private root is trusted in expected trust stores and not in unintended public trust stores; and review the private CA CP/CPS for alignment with current organizational security policy.

How does the clientAuth EKU removal affect cloud, hybrid, or multi-CA PKI environments?

In cloud and hybrid environments, cloud workloads that authenticate as mTLS clients using public certificates must be migrated to private client certificates issued by the new private CA. In multi-CA environments, the private CA for clientAuth must be a dedicated hierarchy separate from the public server CA hierarchy. CBOM Secure provides the cross-environment cryptographic inventory needed to identify all cloud and hybrid clientAuth dependencies before CA deadlines arrive.

What common mistakes should teams avoid when migrating to private PKI for mTLS?

The most frequent mistakes: skipping discovery and assuming all mTLS dependencies are known; standing up a private CA without HSM-backed root key storage; not configuring automated enrollment before migrating (manual private certificate management at scale fails the same way manual public certificate management does); deploying the private root into an unintended public trust store; and not separating the private client CA hierarchy from the public server CA hierarchy, which defeats the dedicated-hierarchy model the industry is converging on.

What should be refreshed quarterly for private PKI mTLS governance?

Quarterly: run a certificate inventory scan to identify any new public certificates carrying clientAuth added since the last audit; review the private CA issuance log for unexpected certificate profiles or unauthorized issuance; confirm enrollment automation is active for all migrated mTLS services; review private client certificate expiry timelines; check CA/Browser Forum and Chrome Root Program announcements for policy changes; and review the post-quantum migration roadmap for private client certificate algorithms following NIST FIPS 203, 204, and 205 (August 13, 2024). For post-quantum migration planning, check the PQC Center of Excellence.