Understanding Chrome’s Root Program Policy v1.8: What Changes on June 15, 2026

In the ever-evolving landscape of internet security, few changes have the potential to reshape foundational practices like Google Chrome’s root program policy update. Over a series of deadlines starting in 2026, Chrome is changing how SSL/TLS certificates can be used. Public certificate hierarchies now have to be dedicated to TLS server authentication alone, which means support for TLS client authentication is going away in the public certificate world. If your organization relies on public certificate authorities (CAs) for authenticating users, devices, or applications, this change demands immediate attention.

Let’s unpack what this means, why it’s happening, and how you can prepare.

The Heart of the Change: Chrome Root Program Policy v1.8

At the core of this transition is Chrome Root Program Policy v1.8 (last updated February 5, 2026), which continues the program’s push toward dedicated TLS server authentication PKI hierarchies. Under this policy, certificate hierarchies included in Chrome’s trust store must serve only TLS server authentication, and multi-purpose roots are being phased out.

What this means in practice is that public CAs are stepping away from certificates that carry both the id-kp-serverAuth and id-kp-clientAuth Extended Key Usages (EKUs). These EKUs define what a certificate can be used for, either server or client authentication, but not both. The change happens on two dates worth marking on your calendar.

From June 15, 2026, any new intermediate (subordinate) CA certificate disclosed to the CCADB under a root in the Chrome Root Store has to carry the serverAuth EKU only. Then, from March 15, 2027, the same rule reaches the certificates you actually deploy: every newly issued leaf certificate that chains to a Chrome-trusted root must be serverAuth-only too. After that, clientAuth is effectively gone from public certificates.

Certificates issued before the applicable cutoff will remain valid until they expire (unless revoked), but new and renewed public certificates will no longer include clientAuth. Most major CAs, including DigiCert, Sectigo, and Let’s Encrypt, began removing the clientAuth EKU by default well ahead of these deadlines.

Why This Matters

TLS client authentication is a critical mechanism used to verify the identity of clients, be it users, devices, or applications, when they connect to a server. It’s distinct from server authentication, which is what most people associate with HTTPS.

Client authentication is commonly used in:

• VPN access: Verifying employee devices connecting remotely.
• Wi-Fi onboarding: Authenticating devices without static passwords.
• Mutual TLS (mTLS): Securing API communication in microservices.
• Single Sign-On (SSO): Embedding certificates in endpoint devices.
• DevOps environments: Identifying workloads and containers.

Many organizations have been using public CAs for these purposes, often unknowingly, because it’s convenient and cost-effective. But with Chrome’s new policy, this approach will no longer be viable.

Why Is This Happening?

The move is part of a broader industry trend toward dedicated PKI hierarchies. Multipurpose certificates, those used for both server and client authentication, introduce complexity and potential security risks. By separating these use cases, browsers like Chrome aim to:

• Improve certificate management.
• Strengthen trust in public PKI.
• Reduce the risk of misuse or misconfiguration.

Public CAs were never designed for internal authentication workflows. They’re subject to external audits, compliance mandates, and browser policies. This makes them ill-suited for the flexibility and control required in client authentication scenarios.

The Solution: Transition to Private CAs

If your organization uses public certificates for client authentication, the path forward is clear: migrate to a private certificate authority (CA).

Benefits of private CAs include:

• Customizable certificate profiles.
• Full control over issuance and revocation.
• No dependency on browser trust stores.
• Support for protocols like ACME, EST, and SCEP.

This shift empowers organizations to design authentication workflows tailored to their needs, without being constrained by public CA limitations.

What You Should Do Next

Here’s a practical roadmap to get ready for Chrome’s 2026 and 2027 deadlines:

1. Audit Your Certificate Usage: Identify where TLS client authentication is used. Are you relying on public ACME workflows like Let’s Encrypt? Which devices and services are affected?
2. Assess Your Risk: Determine which certificates will be impacted and when. Plan to replace them before they expire or become untrusted.
3. Deploy a Private CA: Choose a solution that fits your environment: cloud-based, on-prem, or hybrid. Ensure it supports automation and integration with your existing tools.
4. Implement CLM and Migrate Your Public CA Certificates to a Private CA: With your private CA in place, implement a CLM platform to manage certificate lifecycles, enforce policies, and maintain visibility across your environment. Before migrating, define the appropriate certificate templates and EKUs on the private CA so the reissued certificates carry the right usages (for client authentication, the clientAuth EKU without serverAuth). With that in place, use the CLM’s switch CA capability to move your existing public CA client authentication certificates over to the private CA in bulk, rather than tracking down and reissuing each one by hand.
5. Educate Your Teams: Ensure that IT, DevOps, and security teams understand the implications and are aligned on the migration strategy.

How Can Encryption Consulting Help?

Encryption Consulting’s CertSecure Manager is a vendor‑neutral certificate lifecycle management solution that centralizes discovery, automation, enrolment, policy enforcement, and integrations. It prevents outages with automated renewals, enhances compliance, streamlines IT operations, and unifies management of public and private CAs through a single, automated, scalable platform.

For the Chrome change specifically, its discovery and inventory let you find exactly which of your certificates carry the clientAuth EKU today, and its one-click public CA migration helps you move those workloads onto a private CA in bulk, without the manual effort of tracking down and reissuing certificates one by one.

Additionally, if you need somewhere to issue client authentication certificates once they leave the public trust store, Encryption Consulting’s PKI-As-A-Service gives you a fully managed private CA. It handles your PKI deployment end to end, with certificate issuance, automated lifecycle management, policy enforcement, and compliance with industry security standards, so you can stand up a dedicated private hierarchy for VPN, Wi-Fi, mTLS, and SSO without building and operating the infrastructure yourself.

Conclusion

Chrome’s root program update isn’t just a technical tweak; it marks a fundamental shift in how digital identity and trust are managed across the internet. While it may disrupt existing authentication workflows, it also provides organizations with a timely opportunity to modernize their PKI architecture and build a more secure, scalable, and resilient foundation.

If your organization is still using public certificates for client authentication, now is the time to act. The deadlines are fixed, the enforcement is strict, and Chrome’s move toward dedicated server-auth-only public PKI makes private CAs the only sustainable path forward.

At the same time, the rising volume of certificates, shrinking certificate lifetimes, and the increasing complexity of distributed environments make Certificate Lifecycle Management (CLM) essential, not optional. A robust CLM solution prevents outages, automates renewals, enforces compliance, and gives organizations full visibility and control over their cryptographic assets.

In an ecosystem where browser trust requirements continue to tighten, PKI environments diversify, and digital identities multiply across cloud, DevOps, IoT, and zero‑trust architectures, effective certificate lifecycle management becomes foundational to a secure, efficient, and future-ready authentication strategy.