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

Chrome Root Program Policy v1.8 requires every public certificate hierarchy trusted by Chrome to serve TLS server authentication only, removing the clientAuth Extended Key Usage from public certificates in two phases. New subordinate CA certificates must be serverAuth-only starting June 15, 2026, and new leaf certificates must be serverAuth-only starting March 15, 2027, after which organizations must migrate any client authentication use case to a private CA.

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.

Key Takeaways

• Chrome Root Program Policy v1.8 eliminates the clientAuth Extended Key Usage from public certificates, phased across two enforcement dates: June 15, 2026 for subordinate CA certificates and March 15, 2027 for leaf certificates.
• This is a separate policy from the earlier 2020 proposal to shorten overall TLS validity to 90 days; the current CA/Browser Forum schedule phases maximum public TLS validity to 200 days (March 2026), 100 days (March 2027), and 47 days (March 2029).
• DigiCert’s Trust Pulse Survey found that 45% of organizations experienced certificate-related downtime in the past year, and 37.5% traced an outage specifically to an expired certificate, the same failure mode an unmigrated clientAuth certificate can reproduce.
• Any organization using public certificates for VPN, Wi-Fi, mTLS, SSO, or DevOps client authentication must migrate to a private CA before the applicable deadline.
• PKI, security, platform, and compliance teams each own a distinct action; the owner/action matrix and timeline table below break out exactly what and when.

Jump to: Executive Summary | Readiness Checklist | Timeline | Policy Sources | Owner/Action Matrix | What to Do Next | Update Log | FAQ

Executive Summary for PKI, Security, Platform, and Compliance Teams

If you lead one of these functions, here is the decision this article supports and the quick-reference action for it.

• PKI teams: inventory every certificate carrying the clientAuth EKU today and confirm whether it is issued by a public or private CA.
• Security teams: confirm no VPN, Wi-Fi, mTLS, or SSO workflow depends on a public certificate that will lose clientAuth after June 15, 2026 or March 15, 2027.
• Platform/DevOps teams: stand up or confirm a private CA that supports automated enrollment protocols before the migration deadline arrives.
• Compliance teams: confirm the migration plan and its completion date are documented against the March 15, 2027 enforcement date.

Quick Readiness Checklist

Use this checklist to gauge whether your organization is actually ready for Chrome Root Program Policy v1.8, not just aware of it.

• Confirmed which certificates in your environment currently carry the clientAuth EKU and whether each is issued by a public or private CA.
• Verified your CA’s own transition plan for removing clientAuth from newly issued certificates ahead of the June 15, 2026 and March 15, 2027 dates.
• Deployed, or scoped, a private CA capable of issuing clientAuth certificates for VPN, Wi-Fi, mTLS, and SSO use cases.
• Checked whether your certificate lifecycle management platform supports bulk migration between CAs, rather than manual reissuance certificate by certificate.
• Confirmed IT, DevOps, and security teams are aligned on the migration timeline and who owns each step.

Policy Source and Effective Dates

This post is based directly on the primary sources below. Check the live policy text before treating any date here as final, since Google and the CA/Browser Forum both publish updates to their own sites first.

• Chrome Root Program Policy, version 1.8: published by the Chrome Root Program at chromium.org/Home/chromium-security/root-ca-policy, with the machine-readable policy history at github.com/GoogleChrome/chromerootprogram. Version 1.8 is the version in effect as of this review.
• CA/Browser Forum Ballot SC-081v3: approved April 14, 2025, governing the 200-day, 100-day, and 47-day TLS certificate validity phase-down, summarized by Sectigo at sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-days.

One framing worth retiring: this change is sometimes confused with an earlier, separate 2020 proposal to shorten overall TLS certificate lifetimes to 90 days. That proposal is not what is discussed in this post. The clientAuth removal covered here is a distinct policy, tracked under Chrome Root Program Policy v1.8, with its own June 15, 2026 and March 15, 2027 dates.

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.

Timeline: Key Dates for Chrome Root Program Policy v1.8

Use this timeline to see exactly which certificates are affected, when, and what to do before each date arrives.

Effective Date	Requirement	Who Is Impacted	Action Needed	Source
February 5, 2026	Chrome Root Program Policy v1.8 published	All public CAs in the Chrome Root Store	Confirm your CA has published its transition plan for dropping clientAuth	chromium.org/Home/chromium-security/root-ca-policy
June 15, 2026	New intermediate (subordinate) CA certificates disclosed to the CCADB must carry serverAuth only	Public CAs and any organization operating a subordinate CA under a Chrome-trusted root	Confirm your CA’s subordinate hierarchy has already dropped clientAuth from new intermediates	chromium.org/Home/chromium-security/root-ca-policy
March 15, 2027	Newly issued leaf certificates chaining to a Chrome-trusted root must be serverAuth-only	Every organization using public certificates for VPN, Wi-Fi, mTLS, SSO, or DevOps client authentication	Complete migration of all client authentication certificates to a private CA before this date	chromium.org/Home/chromium-security/root-ca-policy
March 2026 / March 2027 / March 2029	CA/Browser Forum Ballot SC-081v3 phases maximum public TLS validity to 200, 100, then 47 days	Every organization managing public TLS server certificates	Confirm certificate automation is in place before renewal frequency increases roughly eightfold	sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-days

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.

DigiCert’s Trust Pulse Survey, published July 2, 2025, found that 45% of organizations experienced certificate-related downtime in the past year, and 37.5% traced an outage specifically to an expired certificate, per DigiCert’s Trust Pulse Survey. Losing clientAuth from public certificates without a migration plan adds a second, avoidable way to land in that same statistic: an authentication workflow that quietly breaks the day a browser update or a renewal enforces the new policy.

The timing compounds an existing pressure. The CA/Browser Forum’s Ballot SC-081v3, approved April 14, 2025, phases maximum public TLS validity from 398 days today to 200 days (March 2026), 100 days (March 2027), and 47-day TLS certificates (March 2029). Teams that are still manually tracking certificates will be renewing far more often at the exact moment they also need to migrate every client authentication certificate off the public CA path.

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 certificate 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.

The same discipline extends beyond certificates. Our CBOM Secure platform runs that same certificate discovery across an organization’s full cryptographic estate, and our CBOM: from inventory to intelligence guide covers turning that inventory into an ongoing program. Because certificate automation in CertSecure Manager is CA-agnostic, migrating off public clientAuth certificates today also builds in the crypto agility teams need heading into the post-quantum transition. Our 9-phase PQC readiness roadmap and PQC Center of Excellence help you plan that migration alongside the Chrome policy work described above.

Owner and Action Matrix by Team

Team	Responsibility	Key Action
PKI team	Owns the full certificate inventory and knows which certificates carry the clientAuth EKU	Complete a discovery pass across public and private CA estates before June 15, 2026
Security team	Owns confirming no authentication workflow silently breaks when clientAuth disappears from public certificates	Map every VPN, Wi-Fi, mTLS, and SSO workflow to its certificate source and renewal date
Platform/DevOps team	Owns deploying and operating the private CA that replaces public clientAuth issuance	Stand up a private CA supporting ACME, EST, or SCEP automation before migration begins
Compliance team	Owns documenting the migration plan and its completion against the enforcement dates	Track migration status against the March 15, 2027 deadline and retain evidence for audit

What to Do Next

• PKI teams: run the certificate discovery pass this quarter and flag every clientAuth certificate still issued by a public CA.
• Security teams: confirm a rollback or fallback path exists for any authentication workflow being migrated ahead of the deadline.
• Platform teams: validate the private CA’s automation protocols against your existing enrollment tooling before cutover.
• Compliance teams: confirm your next audit can show migration status against both the June 15, 2026 and March 15, 2027 dates.

Related Reading From Encryption Consulting

• Stronger Security With TLS Certificates in 47-Day Validity by 2029 covers the full CA/Browser Forum validity glide path referenced throughout this post.
• CBOM: From Inventory to Intelligence covers turning cryptographic discovery into an ongoing program beyond certificates.
• PQC Center of Excellence covers how to plan the post-quantum migration alongside this certificate authentication migration.

Update Log

• August 14, 2026: Reviewed against the live Chrome Root Program Policy v1.8 text and CA/Browser Forum Ballot SC-081v3; no change to the June 15, 2026 or March 15, 2027 enforcement dates. Added timeline table, policy-source citations, executive summary, readiness checklist, owner/action matrix, and FAQ.
• June 16, 2026: Original publication, covering Chrome Root Program Policy v1.8 (published February 5, 2026) and the clientAuth removal timeline.

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.

As a policy-tracking explainer, this guide is reviewed every six months, and immediately whenever the Chrome Root Program updates its policy version, the CA/Browser Forum passes a new ballot, or a major public CA changes its clientAuth removal timeline.

Frequently Asked Questions

What Is the Main Takeaway From Understanding Chrome’s Root Program Policy v1.8: What Changes on June 15, 2026?

Chrome Root Program Policy v1.8 removes the clientAuth Extended Key Usage from public certificates in two phases: subordinate CA certificates must be serverAuth-only starting June 15, 2026, and leaf certificates must be serverAuth-only starting March 15, 2027. Any organization using public certificates for client authentication needs a private CA in place before its applicable deadline.

Why Does This Matter for Enterprise Certificate Lifecycle Management?

DigiCert’s Trust Pulse Survey found that 45% of organizations experienced certificate-related downtime in the past year, and 37.5% traced an outage specifically to an expired certificate. A client authentication certificate that silently loses its clientAuth EKU after a renewal produces that same kind of outage, except the root cause is a policy change rather than a missed expiry date.

What Teams Are Responsible for Acting on This Guidance?

PKI teams own inventorying every certificate that carries the clientAuth EKU today; security teams own confirming no VPN, Wi-Fi, mTLS, or SSO workflow depends on a public certificate that will lose clientAuth; platform and DevOps teams own standing up the replacement private CA; and compliance teams own documenting the migration against the enforcement dates. The owner/action matrix above breaks this out by team.

What Risks Increase If This Topic Is Handled Manually?

Without a complete certificate inventory, a team can miss exactly which authentication workflows depend on public clientAuth certificates, and discover the gap only when a renewal silently drops client authentication support and an application, VPN, or Wi-Fi login starts failing in production. Manually tracking every certificate across public and private CAs also makes it easy to miss the March 15, 2027 hard deadline entirely.

How Does Automation Reduce Certificate Outage Risk?

Automating certificate discovery and CA migration means a platform, not a spreadsheet, identifies every certificate carrying the clientAuth EKU and moves it to a private CA in bulk, rather than requiring someone to track down and reissue each one by hand. That removes the two most common causes of a clientAuth-related outage: an undiscovered certificate and a missed migration deadline.

What Metrics Should Teams Track After Implementation?

Track the percentage of clientAuth certificates successfully migrated from public to private CAs against the total discovered; the number of authentication workflows (VPN, Wi-Fi, mTLS, SSO) confirmed unaffected by the policy change; time remaining before the March 15, 2027 deadline versus migration progress; and any authentication failures traced back to an unmigrated public certificate. Report these quarterly until migration is complete.

How Does This Connect to 47-Day TLS Certificate Readiness?

The CA/Browser Forum’s Ballot SC-081v3 phases maximum public TLS certificate validity from 200 days (March 2026) to 100 days (March 2027) to 47 days (March 2029), roughly an eightfold increase in renewal frequency. Teams migrating clientAuth certificates off public CAs right now should build the same certificate automation into that migration, since manual processes that cannot keep up with clientAuth removal will not keep up with 47-day renewals either.

How Should This Be Handled in Multi-Cloud or Hybrid PKI Environments?

Apply the same clientAuth discovery and private-CA migration consistently across every cloud, on-premises, and hybrid environment rather than migrating one environment and leaving others on public clientAuth certificates past the deadline. A partial migration leaves exactly the gap Chrome’s policy is designed to close, just confined to whichever environment was deprioritized.