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.

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 will end issuance of client authentication certificates entirely 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.

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.

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 Does Certificate Inventory Matter 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.

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.

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, a managed private CA 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 organizations that need to look beyond immediate migration and build a long-term trust strategy, Encryption Consulting also offers dedicated advisory support.

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.