Client Authentication Certificate Changes: Chrome’s 2026 mTLS Shift

A client authentication certificate is a digital certificate that proves the identity of a user, device, workload, or service to a server, most often inside a mutual TLS (mTLS) handshake. Chrome’s 2026 change, delivered through the Chrome Root Program, changes the trust requirements for publicly trusted certificates. Under these requirements, Chrome will no longer trust newly issued public certificates that combine server and client authentication. New certificates issued under compliant public hierarchies are limited to server authentication, while certificates issued earlier keep working until they expire. Client authentication moves to private or enterprise PKI.

For years, many organizations have used publicly trusted Transport Layer Security (TLS) certificates for both server authentication and client authentication in mTLS deployments. That approach is now coming to an end.

As of June 15, 2026, changes introduced through Google’s Chrome Root Program are accelerating the separation of public server authentication and client authentication into distinct Public Key Infrastructure (PKI) hierarchies. As a result, publicly trusted certificate authorities (CAs) are moving away from issuing certificates that contain both Server Authentication and Client Authentication Extended Key Usages (EKUs).

June 15, 2026 marks the requirement for newly disclosed subordinate CAs; all newly issued public TLS subscriber certificates must carry only the Server Authentication EKU from March 15, 2027, per Chrome Root Program Policy v1.8.

This does not mean Chrome is eliminating mTLS. Mutual TLS remains an important security mechanism for authenticating users, devices, workloads, and services. Instead, Chrome is driving a shift toward purpose-specific PKI, where public certificate authorities focus on server identity while client authentication is handled through private PKI or dedicated enterprise trust infrastructures.

For organizations that still rely on publicly trusted certificates for client authentication, this is not a minor policy update. It is a trust architecture change that requires planning before renewal cycles begin exposing hidden dependencies.

Quick Answer: What Is the Chrome 2026 Client Authentication Change?

Chrome Root Program Policy v1.8 removes the Client Authentication EKU (id-kp-clientAuth, OID 1.3.6.1.5.5.7.3.2) from new publicly trusted TLS certificates. Subordinate CAs must be serverAuth-only from June 15, 2026; leaf certificates from March 15, 2027. mTLS is not eliminated. Client authentication moves to private PKI or dedicated enterprise CA hierarchies not subject to Chrome’s trust store requirements.

Key Takeaways

• Chrome is not eliminating mutual TLS. Chrome Root Program Policy v1.8 removes the clientAuth EKU from new publicly trusted certificates, not from certificates issued by private CAs. mTLS deployments that migrate client certificates to a private CA hierarchy continue working without disruption.
• Two hard deadlines apply: June 15, 2026 for newly disclosed subordinate CAs in Chrome-trusted hierarchies (must be serverAuth-only), and March 15, 2027 for all newly issued leaf subscriber certificates. Certificates issued before the applicable date remain valid until expiry, but renewal after the deadline drops clientAuth.
• Let’s Encrypt ended clientAuth EKU issuance permanently on July 8, 2026. DigiCert, Sectigo, and other major public CAs operating under Chrome Root Program requirements are following similar timelines, completing the transition ahead of the March 15, 2027 date.
• The DigiCert Trust Pulse Survey (July 2025) found that 45 percent of enterprises experienced certificate-related downtime in the prior year. An unmigrated mTLS deployment that silently loses clientAuth at renewal produces exactly that outage, without an obvious root cause in the initial error logs.
• The CA/Browser Forum Ballot SC-081v3 (approved April 14, 2025) simultaneously phases maximum public TLS certificate lifetimes from 200 days (March 2026) to 100 days (March 2027) to 47 days (March 2029). Teams managing the clientAuth migration manually will face both pressures at the same time without automation.

Who Should Care About This Change

This policy change affects every team that issues, depends on, or governs certificates used for client authentication. The consequences of a missed migration materialize across the organization when an mTLS handshake begins failing in production.

Role	Why It Matters	Action Item
PKI Admins	Own certificate inventory and migration execution; must identify every certificate carrying the clientAuth EKU issued by a public CA and coordinate the migration to a private CA before the March 15, 2027 deadline; discovery gaps leave hidden dependencies that break at renewal	Run a certificate discovery pass across all environments using CertSecure Manager to identify all clientAuth EKU certificates from public CAs; deploy or configure a private CA to issue replacement client authentication certificates; confirm the private CA root is distributed to all relying party trust stores before migrating
Security Architects	Own the new trust architecture design; the private CA hierarchy issuing client authentication certificates must be designed with appropriate policy constraints, HSM-backed key storage, and revocation infrastructure; cryptographic inventory across all CA sources is a prerequisite for planning	Design the private CA hierarchy for client authentication with certificate policy separating it from server authentication CAs; require FIPS 140-3 Level 3 HSM-backed key storage for the private CA private key; build a cryptographic bill of materials using CBOM Secure to confirm all clientAuth EKU certificates are identified across hybrid and multi-CA environments; include post-quantum migration planning for the new private CA via PQC Readiness
Platform and DevOps Teams	Own updating CI/CD pipelines, Kubernetes clusters, service mesh configurations, and API gateway trust stores; workload identity certificates issued automatically through service mesh control planes using public ACME providers (Let’s Encrypt ended clientAuth on July 8, 2026) must be migrated to private CA issuers; failures in these environments appear as authentication errors, not certificate events	Audit all service mesh, Kubernetes, and CI/CD certificate issuers for clientAuth EKU; migrate automated issuance from public ACME providers to private CA ACME endpoints; distribute private CA trust roots to all container images, Kubernetes trust stores, and service mesh configurations before cutover; test mTLS handshake behavior after migration in staging before production rollout
Compliance Teams	Must document migration completion against the June 15, 2026 subordinate CA deadline and the March 15, 2027 leaf certificate deadline; certificate governance frameworks under NIST SP 800-53 SC-17, PCI-DSS, and ISO 27001 require evidence that certificate lifecycle controls cover private CA-issued certificates after migration, not just public certificates	Build a migration tracking record mapping each discovered public CA clientAuth certificate to its migration status and target private CA; include Chrome Root Program Policy compliance in the quarterly certificate compliance review; confirm CLM audit reports cover private CA-issued client authentication certificates after migration
CISOs	Own the governance decision that this is a formal project with hard deadlines; an unmigrated mTLS dependency discovered after March 15, 2027 produces an authentication failure across every service in the affected path; the operational risk compounds as public TLS lifetimes shrink toward 47 days and renewal frequency increases	Authorize this as a formal project with dedicated resources, a tracked deadline against March 15, 2027, and a CLM platform budget that covers private CA deployment and automated lifecycle management; require quarterly migration status reporting; mandate PKI as a Service evaluation for organizations that cannot deploy internal CA infrastructure before the deadline

Key Terms and Concepts

Use this table to understand the key concepts in Chrome’s 2026 client authentication change, when each term matters operationally, and the implementation consideration that governs how each is handled.

Term	Definition	When It Matters	Implementation Consideration
Client Authentication Certificate	A digital certificate carrying the id-kp-clientAuth EKU (OID 1.3.6.1.5.5.7.3.2) that proves the identity of a user, device, workload, or service to a server during a TLS handshake	VPN, Wi-Fi, mTLS API, SSO, DevOps workload identity, device authentication	After March 15, 2027, must only be issued by private CAs not subject to Chrome’s trust store; public CA-issued clientAuth certificates become unsustainable for new issuance
Server Authentication Certificate	A digital certificate carrying the id-kp-serverAuth EKU (OID 1.3.6.1.5.5.7.3.1) that proves the identity of a server to a connecting client during HTTPS or TLS connections	All public-facing websites, HTTPS APIs, internet-facing services	Continues on public CAs; Chrome policy restricts new public certificates to serverAuth only after the applicable deadlines
Dual-EKU Certificate	A TLS certificate containing both serverAuth and clientAuth EKUs, historically issued by public CAs for convenience in mTLS deployments	Legacy mTLS configurations using one certificate for both server and client authentication	No longer issuable from public CAs after June 15, 2026 (subordinate CAs) and March 15, 2027 (leaf certificates); existing dual-EKU certificates remain valid until expiry
Chrome Root Program Policy v1.8	Google’s policy governing which public CA hierarchies Chrome trusts, requiring dedicated server-authentication hierarchies and prohibiting new public certificates from including the clientAuth EKU	Every organization using public certificates for client authentication must comply with its enforcement dates	Version 1.8 was last updated February 5, 2026; check the live policy at chromium.org before treating any date here as final
Private CA	A Certificate Authority operated by an organization or a managed service provider, not included in browser trust stores, and therefore not subject to Chrome Root Program requirements	Any client authentication use case after March 15, 2027; replaces public CA as the issuer of clientAuth certificates	Private CA root must be distributed to all relying party trust stores before deploying private CA-issued client certificates; supports ACME, EST, SCEP enrollment protocols
Mutual TLS (mTLS)	A TLS handshake in which both the server and the client present certificates for mutual authentication; requires the client certificate to carry the clientAuth EKU	API gateways, microservice communication, zero-trust enforcement, partner integrations	mTLS continues after Chrome’s policy change; client certificates move from public CAs to private CAs; the mTLS protocol and server-side configuration remain unchanged
Cryptographic Bill of Materials (CBOM)	A structured inventory of all cryptographic assets, algorithms, certificates, and keys across the enterprise; the prerequisite for identifying which certificates carry the clientAuth EKU and which CA issued them	At the start of the migration; without CBOM-level visibility, discovery gaps leave hidden clientAuth dependencies that break at renewal	CBOM Secure from Encryption Consulting automates this discovery across hybrid and multi-CA environments including on-premises AD CS, cloud-native CAs, and service mesh identity components

What Did Chrome Actually Change

Chrome changed the rules for what a publicly trusted certificate is allowed to do: new public TLS certificates may assert only the Server Authentication EKU, so they can no longer double as client authentication credentials. Much of the discussion around this topic has been framed as the death of mTLS, but that characterization is misleading.

The Chrome Root Program’s policy changes focus on reducing the attack surface of the public WebPKI by encouraging dedicated TLS server authentication hierarchies. Beginning June 15, 2026, newly disclosed subordinate CAs in Chrome-trusted hierarchies must assert only the Server Authentication EKU (id-kp-serverAuth, OID 1.3.6.1.5.5.7.3.1), per Chrome Root Program Policy v1.8.

Subscriber certificates issued under these hierarchies must be limited to server authentication purposes from March 15, 2027, while certificates already issued remain valid until they expire.

The goal is simple: separate server identity from client identity.

Think of it this way: a server certificate is like a storefront sign that proves a shop is legitimate, while a client certificate is like an employee badge that proves you belong inside. Chrome is asking each certificate to do only one of those jobs.

Historically, some public certificates could be used for both purposes because they contained both Server Authentication (OID 1.3.6.1.5.5.7.3.1) and Client Authentication (OID 1.3.6.1.5.5.7.3.2) EKUs. While convenient, this created multi-purpose credentials that were often overprivileged and harder to govern.

Chrome’s policy pushes the ecosystem toward dedicated trust models where certificates perform one role well instead of multiple roles simultaneously.

Why Are Public CAs Moving Away From Client Authentication

The change aligns with a broader industry movement toward purpose-specific trust architectures.

Client authentication requirements differ significantly from public website authentication requirements. Enterprise device identity, workload authentication, API authentication, and internal service-to-service communications often require tighter control over issuance, revocation, lifecycle management, and identity governance than public WebPKI was designed to provide.

Let’s Encrypt has been particularly clear on this point. The organization removed the Client Authentication EKU from its default certificate profile on February 11, 2026, and permanently ended issuance of client authentication certificates on July 8, 2026, because many client authentication use cases are better served by private certificate authorities. The change is directly tied to Chrome Root Program requirements for dedicated server-authentication hierarchies, making private or enterprise PKI the preferred approach for client authentication.

Major public certificate authorities operating within the Chrome Root Program are following similar timelines, with most completing the transition ahead of the March 15, 2027 deadline.

In other words, Chrome is not removing client authentication. It is moving client authentication out of the public trust ecosystem.

Timeline: Key Dates Organizations Need to Know

Several important milestones affect organizations currently using public certificates for client authentication.

Date	Change
October 1, 2025	Let’s Encrypt introduces the temporary tlsclient profile for organizations needing additional migration time
February 11, 2026	Let’s Encrypt removes Client Authentication EKU from its default certificate profile
May 13, 2026	Access to the tlsclient profile closes for new users; existing users may continue through July 8, 2026
June 15, 2026	Newly disclosed subordinate CAs in Chrome-trusted hierarchies must assert only the Server Authentication EKU (Chrome Root Program Policy v1.8)
July 8, 2026	Let’s Encrypt permanently ends issuance of certificates containing Client Authentication EKU through the tlsclient profile
March 15, 2027	All newly issued public TLS subscriber certificates must contain only the Server Authentication EKU (id-kp-serverAuth), per Chrome Root Program Policy v1.8

For many organizations, the operational impact will not appear immediately. Existing certificates typically continue functioning until expiration. The real disruption occurs when renewal time arrives and newly issued certificates no longer contain the expected Client Authentication EKU that the application expects.

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

Use this checklist to identify which migration issues apply to your environment and assign remediation ownership before a renewal cycle forces a reactive response.

Issue	Business Impact	Recommended Action	Owner
No certificate discovery across all environments	ClientAuth EKU certificates in uncovered environments are invisible until renewal fails; VPN, Wi-Fi, mTLS APIs, and SSO workflows break without an obvious root cause	Deploy automated discovery across all environments (Windows certificate stores, Linux, cloud workloads, Kubernetes, service mesh) and filter results for certificates with the clientAuth EKU from public CAs	PKI Admin
No private CA deployed for client authentication	No replacement issuer exists when public CA certificates expire; migration cannot begin until the private CA is operational and its root is distributed to relying party trust stores	Deploy a private CA (on-premises AD CS, cloud PKI, or PKI as a Service) capable of issuing clientAuth certificates before migration begins; distribute the private CA root to all relying party trust stores before cutover	PKI Admin + Platform Team
Service mesh or DevOps pipeline using public ACME for client certificates	Let’s Encrypt ended clientAuth EKU issuance on July 8, 2026; automated pipelines that request certificates from public ACME providers for workload identity are already broken or about to break	Replace public ACME issuer with private CA ACME endpoint in service mesh control plane configuration; validate workload identity certificates after migration in staging before production rollout	Platform Team
Certificates with no assigned owner identified during discovery	Orphaned clientAuth certificates have no renewal owner; they expire unnoticed, breaking the authentication workflow they support	Assign every discovered clientAuth certificate to a named owner with a documented renewal responsibility before beginning migration; do not migrate orphaned certificates without first establishing ownership	PKI Admin + System Owners
No CLM platform covering private CA-issued certificates after migration	Migrating to a private CA without CLM coverage recreates the same visibility gap that exists for public CA certificates; private CA certificates expire unnoticed just as public CA certificates do without monitoring	Confirm CLM platform (CertSecure Manager) covers all private CA-issued client authentication certificates with expiry alerting, renewal automation, and policy enforcement after migration	PKI Admin
No test of mTLS handshake after migration	Private CA root not distributed to a relying party trust store causes mTLS handshake failure even though the client certificate has the correct clientAuth EKU; the failure appears identical to an EKU error without detailed TLS debug logging	Test mTLS handshake end-to-end from each client type (device, service, API gateway) after migration and before revoking old public CA certificates; confirm both the clientAuth EKU and private CA trust are present at all relying parties	Platform Team + PKI Admin
No PQC migration plan for the private CA hierarchy	The private CA hierarchy now handling client authentication will need to migrate to ML-DSA or ML-KEM (NIST FIPS 203/204/205, August 13, 2024) when quantum-safe algorithm requirements apply; planning now avoids a second emergency migration	Include the new private CA hierarchy in the organization PQC readiness assessment; use CBOM Secure to inventory the algorithms used in client authentication certificates; track migration timelines through the PQC Center of Excellence	Security Architect

Public PKI vs Private PKI: The New Reality

The most important architectural change is the separation of certificate roles.

Area	Traditional Approach	Modern Approach
Public TLS Certificates	Server Authentication and Client Authentication together	Server Authentication only
mTLS Authentication	Often uses public certificates	Uses private PKI or dedicated client-auth hierarchy
Trust Model	Shared trust purpose	Purpose-specific trust architecture
Certificate Governance	Multi-purpose certificates	Dedicated certificate roles
Security Posture	Broader credential scope	Reduced attack surface and stronger policy enforcement

This shift aligns with the principle of least privilege. A certificate intended to authenticate a public website should not automatically become a credential for authenticating devices, users, APIs, or internal services.

By separating these functions, organizations gain stronger control over identity management and reduce the risk associated with credential misuse.

What Breaks First

At first, nothing breaks, and that is exactly the risk. Systems often continue operating normally until certificate renewal occurs.

An mTLS deployment may function perfectly today because it relies on certificates issued before the policy changes. However, when those certificates expire and administrators attempt renewal, the replacement certificate may no longer contain the Client Authentication EKU that the application expects.

This creates a dangerous scenario where hidden dependencies remain undiscovered until a routine certificate replacement becomes an outage. According to the DigiCert Trust Pulse Survey (July 2025), 37.5 percent of enterprises traced an outage specifically to an expired certificate in the prior year. The clientAuth migration adds a second failure mode that produces the same outage pattern: the certificate renews successfully, but the renewed certificate no longer contains the EKU the application expects.

The most likely environments to be affected include:

• API gateways using certificate-based client authentication
• Internal service-to-service communications
• Device authentication platforms
• Partner integrations using mTLS
• Legacy workload identity architectures
• Enterprise applications relying on public certificates for client identity

Organizations often discover these dependencies only when a renewal fails or a handshake begins rejecting new certificates.

Why Certificate Inventory Matters More Than Ever

This transition reinforces a lesson that PKI teams have been emphasizing for years: you cannot manage what you cannot see.

Many organizations maintain excellent visibility into website certificates while having little understanding of where client certificates are being used. Some client authentication implementations were deployed years ago and have since become operational blind spots.

The first step in any migration should be identifying certificates that contain the Client Authentication EKU and determining whether they originate from publicly trusted certificate authorities. This discovery process mirrors what practitioners increasingly call a Cryptographic Bill of Materials (CBOM), a structured inventory of all cryptographic assets, algorithms, certificates, and keys across the environment, which is also becoming a recommended practice under broader crypto-agility planning frameworks.

Once discovered, organizations can classify certificates into three categories:

• Public website TLS
• Client authentication
• Internal mTLS and workload identity

In many environments, only the first category truly belongs in public PKI.

Common Mistakes Organizations Are Making

A common misconception is that Chrome is eliminating mutual TLS entirely. This is incorrect.

Chrome’s policy affects how public certificate authorities issue certificates. Mutual TLS remains fully supported and continues to be a critical authentication mechanism across enterprise environments.

Another mistake is waiting until renewal time to investigate dependencies. By then, certificate replacement may already be on a critical path for business operations.

Some organizations also continue using public certificate authorities for internal authentication simply because it is familiar. However, public WebPKI was never designed to manage enterprise device identities, workload identities, or internal trust relationships at scale.

The current transition highlights why these functions increasingly belong within enterprise-controlled PKI environments.

Security Best Practices Moving Forward

The industry direction is becoming clear: use public PKI for public trust and private PKI for private trust.

Public certificates should primarily be used for securing public-facing websites and internet-facing services. Client authentication, service identity, machine identity, and internal workload authentication should be managed through enterprise PKI systems designed specifically for those purposes.

Organizations should also prioritize certificate lifecycle automation. As certificate lifetimes continue shrinking across the industry, manual processes become increasingly difficult to sustain. The CA/Browser Forum Ballot SC-081v3 (approved April 14, 2025) phases maximum public TLS validity from 200 days (March 2026) to 100 days (March 2027) to 47 days (March 2029), roughly an eightfold increase in renewal frequency from today’s baseline.

Certificate inventories should be continuously monitored, renewal workflows automated, and private keys protected using secure key management practices such as Hardware Security Modules (HSMs) validated to FIPS 140-3 where appropriate.

The organizations that navigate this transition successfully will be the ones that treat it as a trust modernization initiative rather than a certificate replacement project. As post-quantum cryptography adoption accelerates following the publication of NIST FIPS 203, 204, and 205 (August 13, 2024), the private CA hierarchy now handling client authentication will also need to plan migration to ML-DSA-based certificates. PQC Readiness assessment services and the PQC Center of Excellence help organizations sequence that migration alongside the Chrome policy work.

How Encryption Consulting Can Help

For many organizations, the challenge is not replacing a certificate. It is redesigning trust architecture.

Encryption Consulting helps organizations modernize PKI environments, separate public and private trust models, and build scalable certificate lifecycle management strategies.

Through Enterprise PKI Services, organizations can assess existing mTLS deployments, identify public certificate dependencies, and design private PKI architectures that support secure client authentication and workload identity management. For organizations that need enterprise-grade certificate authority capabilities without the overhead of building and operating internal CA infrastructure, PKI as a Service provides the issuance, lifecycle management, and policy governance required to support client authentication going forward.

Once the architecture is defined, the next priority is operational visibility across the full certificate environment and lifecycle automation to keep pace with renewal cycles.

CertSecure Manager provides centralized certificate discovery, inventory management, monitoring, and lifecycle automation, helping organizations identify certificates affected by the upcoming policy changes and automate migration activities before renewal deadlines create operational risk. For complete cryptographic visibility across hybrid and multi-CA environments, CBOM Secure builds the cryptographic bill of materials that identifies every clientAuth EKU certificate regardless of issuing CA or deployment environment.

For organizations planning broader trust modernization initiatives, our Encryption Advisory Services can help align certificate management, workload identity, crypto-agility, and PKI governance into a unified roadmap.

Conclusion

Chrome’s 2026 policy changes do not signal the end of mutual TLS. They signal the end of using public WebPKI as a catch-all solution for both server and client authentication.

The industry is moving toward dedicated trust architectures where public certificate authorities focus on server authentication and private PKI platforms manage client identities, workload identities, and enterprise trust relationships.

Organizations that map their certificate estate, identify client authentication dependencies, and begin migrating to purpose-specific PKI models now will avoid disruptive renewal surprises later.

The most successful migrations will not be driven by certificate replacement alone. They will be driven by thoughtful trust architecture modernization that separates server identity from client identity and prepares organizations for the next generation of PKI.

Frequently Asked Questions

What is the main takeaway from Client Authentication Certificate Changes: Chrome’s 2026 mTLS Shift?

Chrome Root Program Policy v1.8 removes the Client Authentication EKU (id-kp-clientAuth, OID 1.3.6.1.5.5.7.3.2) from new publicly trusted TLS certificates in two phases: newly disclosed subordinate CAs must be serverAuth-only from June 15, 2026, and all newly issued leaf subscriber certificates must be serverAuth-only from March 15, 2027. mTLS is not being eliminated; client authentication moves to private PKI or dedicated enterprise PKI hierarchies.

Why does Chrome’s 2026 client authentication change matter for enterprise PKI teams?

Enterprise PKI teams must identify every certificate carrying the clientAuth EKU issued by a public CA, map the services and workflows that depend on it, and migrate those dependencies to a private CA before March 15, 2027. The DigiCert Trust Pulse Survey (July 2025) found that 45 percent of enterprises experienced certificate-related downtime in the prior year. An unmigrated mTLS deployment that silently loses clientAuth at renewal produces exactly that outage. As public TLS certificate lifetimes simultaneously shrink to 47 days by March 2029, renewal cycles arrive more frequently, compressing the discovery window.

What risks increase if this migration is handled manually?

Manual approaches produce discovery gaps (certificates in uncovered environments remain invisible until renewal fails), deadline misses (manual tracking across multiple environments cannot reliably account for every certificate against a hard deadline), and cascade failures (an mTLS handshake that begins rejecting certificates because clientAuth was silently dropped at renewal disrupts every service in the authentication path before the root cause is identified). The 2026 Ponemon Institute global study found only 47 percent of organizations have practical visibility into their certificate estate, making manual tracking of this migration inherently unreliable at enterprise scale.

Which teams should own the client authentication certificate migration?

PKI admins own certificate inventory and migration execution. Security architects own the private CA trust architecture design. Platform and DevOps teams own updating CI/CD pipelines, Kubernetes clusters, and service mesh configurations. Compliance teams own documenting migration completion against the June 15, 2026 and March 15, 2027 enforcement dates. CISOs own the governance decision that this is a formal project with a hard deadline and dedicated resources.

How does this connect to certificate lifecycle management?

The migration requires three CLM capabilities: discovery (identifying every certificate with the clientAuth EKU across all environments); CA migration (moving certificate issuance from a public CA to a private CA in bulk rather than certificate by certificate); and ongoing governance (ensuring future renewals issue from the private CA with the clientAuth EKU and that no new public certificates accidentally pick up clientAuth). CertSecure Manager is built for exactly this workflow: automated discovery, policy enforcement, and bulk CA migration.

How should organizations measure success in the client authentication migration?

Key metrics: clientAuth EKU inventory completeness (all certificates with the clientAuth EKU discovered and categorized by issuing CA before migration begins); migration progress against deadline (percentage of public CA-issued clientAuth certificates migrated to private CA, tracked monthly against March 15, 2027); zero post-migration authentication failures (no VPN, Wi-Fi, mTLS API, SSO, or DevOps workflow broken by the removal of clientAuth from a renewed certificate); and zero new public clientAuth certificates (CLM policy blocking issuance of any new certificate with both serverAuth and clientAuth EKUs from a public CA after the applicable deadline).

What should be audited or monitored regularly after migration?

Monitor continuously: private CA certificate expiry for all migrated client authentication certificates with renewal alerts configured per environment; authentication failures in VPN, Wi-Fi, mTLS API, and SSO workflows that may indicate a missed migration dependency; and CLM policy violations flagging any new certificate with the clientAuth EKU issued from a public CA. Audit quarterly: confirm private CA trust roots are distributed to all relying party trust stores and that no new dependencies on public clientAuth certificates have been introduced.

How does Chrome’s client authentication change affect cloud, hybrid, or multi-CA PKI environments?

In cloud and hybrid environments, clientAuth EKU certificates may come from multiple public CA sources including Let’s Encrypt (which ended clientAuth issuance on July 8, 2026), DigiCert, Sectigo, and cloud-native ACME providers. Each source must be audited independently. In Kubernetes and service mesh environments, workload identity certificates issued automatically through the service mesh control plane using public ACME providers must be migrated to private CA issuers. CBOM Secure spans all CA sources to identify every clientAuth EKU certificate across multi-CA hybrid environments.

What common mistakes should teams avoid?

The most frequent mistakes: assuming Chrome is eliminating mTLS entirely (it is not); waiting until renewal time to investigate dependencies (by then the certificate is on a critical path); treating this as only a certificate replacement project without distributing the private CA root to relying party trust stores before cutover (the mTLS handshake will fail even with the correct EKU); not automating renewal for the new private CA certificates; and not testing authentication workflows after migration before the deadline arrives.

What should be refreshed quarterly for client authentication certificate governance?

Quarterly: verify that CLM platform discovery agents are detecting all private CA-issued client authentication certificates and that no new public CA clientAuth dependencies have been introduced; review the private CA certificate policy and profile to confirm the clientAuth EKU is present and serverAuth is absent on all client authentication certificates; confirm private CA trust roots are still distributed to all relying party trust stores; check Chrome Root Program Policy and CA/Browser Forum ballots for updates; and confirm post-quantum migration planning covers the private CA hierarchy via the PQC Center of Excellence.