Understanding Chrome’s Root Program Policy v1.6 and its implications in 2026 

Quick Answer: Chrome Root Program Policy v1.6 mandates that all PKI hierarchies in Chrome’s trust store must be dedicated exclusively to TLS server authentication. From June 15, 2026, any new TLS certificate that also includes the id-kp-clientAuth EKU will be rejected by Chrome. Organizations must migrate client authentication workflows from public CAs to private CAs before this date.

From June 15, 2026, Google Chrome will reject any new publicly trusted TLS certificate that includes the id-kp-clientAuth Extended Key Usage (EKU). This change, introduced in Chrome Root Program Policy v1.6 and carried forward in v1.8, ends the era of dual-purpose public TLS certificates used for both server and client authentication. If your organization uses public certificate authorities for VPN access, Wi-Fi onboarding, mutual TLS, or SSO, this deadline demands action now.

Key Takeaways

• Hard deadline: June 15, 2026. Chrome will distrust new public TLS certificates containing the id-kp-clientAuth EKU from this date. Certificates issued before the deadline remain valid until natural expiry.
• This change applies to any organization using public CAs for VPN, Wi-Fi authentication, mTLS API security, SSO, or DevOps workload identity.
• The fix is to migrate client authentication from public CAs to a private CA, which is not subject to Chrome’s browser trust store requirements.
• According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of all enterprises experienced certificate-related downtime in the past year. An unmanaged migration to private CAs adds significant outage risk without automated certificate lifecycle management.
• The CA/Browser Forum’s Ballot SC-081v3 (April 2025) is simultaneously reducing public TLS certificate validity to 200 days (March 2026), 100 days (March 2027), and 47 days (March 2029). Both changes together make manual certificate management unsustainable.

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

At the core of this transition is Chrome Root Program Policy v1.6 (now also reflected in the current v1.8), which mandates that certificate hierarchies included in Chrome’s trust store must be dedicated solely to TLS server authentication.

This means public CAs will no longer be allowed to issue certificates containing both the id-kp-serverAuth and id-kp-clientAuth Extended Key Usages (EKUs). These EKUs define what a certificate can be used for: server authentication, client authentication, or both. Starting June 15, 2026, Chrome will distrust any new public TLS certificate that includes the clientAuth EKU. Certificates issued before this date will remain valid until their natural expiration, but no new dual-EKU certificates will be accepted.

Key Terms and Decision Guide

Use this table to understand the key concepts, identify when each applies to your environment, and determine the right implementation path.

Concept	Definition	When It Matters	Implementation Consideration
id-kp-serverAuth EKU	The Extended Key Usage OID (1.3.6.1.5.5.7.3.1) that authorizes a certificate for TLS server authentication (HTTPS)	Every public TLS certificate issued for a website or API endpoint	All new public TLS certificates after June 15, 2026 must only assert this EKU
id-kp-clientAuth EKU	The Extended Key Usage OID (1.3.6.1.5.5.7.3.2) that authorizes a certificate for TLS client authentication	VPN, Wi-Fi, mTLS, SSO, DevOps workload identity	After June 15, 2026, must only be issued by private CAs not subject to Chrome’s trust store
Dual-EKU certificate	A TLS certificate containing both serverAuth and clientAuth EKUs in a single certificate	Legacy configurations using one certificate for both server and client auth	No longer issuable from public CAs for Chrome-trusted hierarchies after June 15, 2026
Private CA	A Certificate Authority operated internally by an organization or via a managed service, not subject to browser trust store requirements	Any client authentication use case after June 15, 2026	Deploy via on-premises ADCS, cloud PKI, or PKI-as-a-Service; distribute root to internal trust stores
mTLS (Mutual TLS)	A TLS handshake where both server and client present certificates for mutual authentication, commonly used in microservices and zero-trust architectures	API security, service mesh, zero-trust enforcement	After migration, mTLS client certificates must come from a private CA; server certificates remain on public CAs
Extended Key Usage (EKU)	An X.509 certificate extension that defines the specific purposes for which the certificate’s public key may be used	All TLS certificates; must be audited for clientAuth before June 15, 2026	Use CLM platform to scan all certificates and flag any with clientAuth EKU
Chrome Root Store	Google Chrome’s list of trusted root Certificate Authorities, managed independently from the OS trust store	Any certificate trusted by Chrome for HTTPS connections	Chrome Root Program Policy v1.6/v1.8 governs what these CAs may issue; private CAs are not in this store

Why This Matters for Your Organization

TLS client authentication is a critical mechanism used to verify the identity of clients, whether users, devices, or applications, when they connect to a server. It is 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 and zero-trust environments.
• Single Sign-On (SSO): Embedding certificates in endpoint devices for password-less login.
• DevOps environments: Identifying workloads, containers, and service accounts.

Many organizations have been using public CAs for these purposes, often unknowingly, because it is convenient and cost-effective. With Chrome’s new policy, any renewal or new issuance of these certificates from a public CA after June 15, 2026 will immediately be rejected by Chrome.

Who Should Care About This Change

This policy affects multiple teams. Here is who needs to act and what they need to do.

Role	Why It Matters	Action Item
PKI Admins	Must deploy a private CA and migrate certificate issuance for all client authentication workflows	Audit all certificates for the clientAuth EKU; deploy private CA (on-prem, cloud, or PKIaaS); update issuance policies
Security Architects	Must define the new trust model for client authentication and ensure the private CA hierarchy is secure	Design private CA hierarchy; define certificate policy for client auth; ensure HSM-backed key storage
Platform / DevOps Teams	Must update CI/CD pipelines, service meshes, and Kubernetes workloads to use private CA-issued certificates	Update ACME clients and enrollment workflows; distribute private CA root to internal trust stores; test authentication flows
Compliance Teams	Must evidence that all affected certificates have been inventoried and migrated before the deadline	Build audit trail from CLM inventory; include Chrome v1.6 migration in quarterly certificate compliance review
CISOs	Own the deadline risk; a missed migration causes authentication failures across the enterprise	Treat this as a formal project with a hard June 15, 2026 deadline; fund CLM tooling and private CA deployment

Why Is This Happening?

This 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, Chrome aims to improve certificate management, strengthen trust in public PKI, and reduce the risk of misuse or misconfiguration.

Public CAs were never designed for internal authentication workflows. They are subject to external audits, compliance mandates, and browser policies, making them ill-suited for the flexibility and control required in client authentication scenarios. The CA/Browser Forum’s October 2024 meeting foreshadowed this change when Google presented the Chrome Root Program’s intention to eliminate clientAuth use cases from server SSL/TLS certificates. The policy was formally published in v1.6 and is now current in v1.8.

The Solution: Transition to a Private CA

If your organization uses public certificates for client authentication, the path forward is clear: migrate to a private certificate authority (CA). Private CAs are not included in Chrome’s Root Store and are therefore not subject to Chrome’s browser trust store requirements.

Benefits of private CAs include:

• Customizable certificate profiles with any EKU combination including clientAuth.
• Full control over issuance, policy, and revocation without external CA constraints.
• No dependency on browser trust stores for internal authentication use cases.
• Support for modern enrollment protocols like ACME, EST, and SCEP.
• Ability to issue short-lived client certificates, reducing the attack window from a compromised credential.

This shift empowers organizations to design authentication workflows tailored to their needs, without being constrained by public CA limitations. For organizations that do not want to operate their own CA infrastructure, PKI-as-a-Service delivers a fully managed, single-tenant private CA with built-in automation, FIPS-compliant HSM key protection, and support for ACME, SCEP, and EST enrollment.

Don’t Overlook Certificate Lifecycle Management

Migrating to a private CA is just the first step. To future-proof your infrastructure, you need robust Certificate Lifecycle Management (CLM). The migration itself exposes a common gap: most organizations do not have a complete, accurate inventory of which certificates include the clientAuth EKU, where they are deployed, or when they expire.

A CLM platform helps you:

• Discover and inventory all certificates, including those with the clientAuth EKU, across all environments.
• Automate issuance, renewal, and revocation from your new private CA.
• Enforce policies on key length, EKUs, validity periods, and approved CA sources.
• Avoid outages caused by expired or misconfigured certificates during and after migration.
• Generate audit reports proving compliance with Chrome’s policy and other frameworks.

As certificate lifespans shrink — the CA/Browser Forum Ballot SC-081v3 (April 2025) takes maximum public TLS validity to 47 days by March 2029 — manual tracking becomes completely unsustainable. CertSecure Manager provides automated certificate lifecycle management with discovery, policy enforcement, and seamless integration across your IT ecosystem, including private and public CAs.

Migration Checklist: What to Do Before June 15, 2026

Work through this checklist in order. Each step depends on the previous one being complete.

• Audit your certificate usage: Use a CLM platform or certificate discovery tool to scan all environments (on-premises, cloud, Kubernetes, DevOps pipelines) and identify every certificate that contains the id-kp-clientAuth EKU. Note the issuing CA, expiry date, and the service that depends on each certificate. CBOM Secure can automate this discovery across hybrid and multi-cloud environments.
• Assess your risk exposure: Determine which certificates will be impacted first (those with the earliest renewal or expiry dates post-June 15, 2026) and which services depend on them. Prioritize authentication-critical services such as VPN gateways, Wi-Fi controllers, and SSO providers.
• Deploy a private CA: Choose a solution that fits your environment: on-premises ADCS, a cloud-hosted private CA (AWS Private CA, Azure AD CA), or a fully managed PKI-as-a-Service platform. Ensure the CA supports automation and integrates with your existing enrollment tools. Distribute the private CA root certificate to all internal client trust stores before migrating.
• Implement CLM: Deploy CertSecure Manager to manage certificate lifecycles, enforce EKU policies, and maintain full visibility across both your old public CA certificates and your new private CA certificates throughout the transition.
• Migrate and test authentication workflows: Reissue client authentication certificates from your new private CA. Test each authentication workflow (VPN, Wi-Fi, mTLS, SSO) to confirm it works correctly with the new private CA-issued certificates before revoking the old public CA certificates.
• Educate your teams: Ensure IT, DevOps, and security teams understand the change and are aligned on the migration strategy. Update runbooks, onboarding guides, and certificate request procedures to reflect the new private CA workflow.

How Encryption Consulting Can Help

CertSecure Manager is a vendor-neutral certificate lifecycle management platform that centralizes discovery, automation, enrollment, policy enforcement, and integrations across public and private CAs. It prevents outages with automated renewals, enhances compliance, streamlines IT operations, and gives organizations full visibility and control over their entire certificate estate during and after the Chrome v1.6 migration.

PKI-as-a-Service helps organizations simplify private CA deployment with end-to-end certificate issuance, automated lifecycle management, policy enforcement, and seamless compliance with industry security standards. For organizations that need to deploy a private CA quickly before the June 15, 2026 deadline, PKIaaS eliminates the infrastructure setup time and provides a production-ready CA from day one.

For broader cryptographic visibility across all environments, including certificates, keys, and algorithms, CBOM Secure builds and maintains a full Cryptographic Bill of Materials. This is particularly useful for the initial discovery phase of the migration, where organizations need to identify every certificate with the clientAuth EKU across hybrid, multi-cloud, and on-premises deployments.

Conclusion

Chrome’s Root Program Policy v1.6 is not just a technical change. It marks a fundamental shift in how digital identity and trust are managed across the internet. The June 15, 2026 deadline is fixed and enforcement is strict: Chrome will phase out any PKI hierarchy found in violation, rejecting certificates issued more than 90 days after a violation is detected.

If your organization is still using public certificates for client authentication, now is the time to act. The path forward is clear: audit your certificate estate, deploy a private CA, migrate authentication workflows, and implement certificate lifecycle management to automate the process and prevent future gaps. Combined with the CA/Browser Forum’s shrinking certificate lifetimes (47 days by 2029), the case for automated CLM has never been stronger.

Frequently Asked Questions

What is the main takeaway from this post on Chrome Root Program Policy v1.6?

From June 15, 2026, Chrome will reject any new publicly trusted TLS certificate that includes the id-kp-clientAuth EKU. Organizations using public CAs for VPN, Wi-Fi, mTLS, or SSO authentication must migrate those workflows to a private CA before this date. Existing certificates remain valid until their natural expiry, but no new dual-EKU certificates will be trusted.

Why does Chrome Root Program Policy v1.6 matter for enterprise PKI teams?

Enterprise PKI teams must audit every certificate in their environment for the clientAuth EKU, identify which services depend on it, and plan a migration to a private CA before June 15, 2026. Failure to act means new certificates issued after the deadline will be rejected by Chrome, breaking VPN, Wi-Fi, mTLS API, and SSO authentication flows silently across the enterprise.

What risks increase if this migration is handled manually?

Manual approaches risk missed certificate renewals, incomplete inventory of affected certificates, and uncoordinated migrations that leave some services using non-compliant certificates after the deadline. According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of enterprises experienced certificate-related downtime in the past year. Without automated discovery and lifecycle management, organizations face authentication failures and service outages.

Which teams should own the Chrome v1.6 migration?

PKI admins own the private CA deployment and certificate issuance workflows. Security architects define the new authentication trust model and certificate policy. Platform and DevOps teams update CI/CD pipelines, service meshes, and Kubernetes workloads to use private CA-issued certificates. Compliance teams verify that all affected certificates have been inventoried and migrated. CISOs own the deadline risk and must ensure the migration is funded and tracked as a formal project.

How does Chrome Root Program Policy v1.6 connect to certificate lifecycle management?

The migration requires discovering all certificates with the clientAuth EKU, tracking their expiry timelines, migrating issuance to a private CA, and ensuring future renewals comply with the new policy. This is exactly what CertSecure Manager is built for: automated discovery, policy enforcement, and renewal across all environments. Without CLM, teams cannot reliably audit their exposure or execute the migration at scale.

How should organizations measure success after migrating?

Success metrics include: zero publicly trusted TLS certificates with the clientAuth EKU issued after June 15, 2026; 100% of client authentication workflows served by private CA-issued certificates; no authentication failures from the migration; complete certificate inventory with owner, expiry, and CA source tracked in a CLM platform; and audit evidence confirming all affected certificates have been replaced.

What should be audited or monitored regularly after migration?

Monitor continuously: certificate issuance to ensure no clientAuth EKU appears in public TLS certificates; expiry timelines for all migrated certificates; and new service deployments that may inadvertently request certificates from a public CA. Audit quarterly: complete certificate inventory for EKU compliance, CA source accuracy, and ownership assignment. Use CertSecure Manager to enforce policy and generate audit reports automatically.

How does Chrome Root Program Policy v1.6 affect cloud, hybrid, or multi-CA PKI environments?

In hybrid and multi-CA environments, certificates from public and private CAs may coexist, making it easy to miss affected certificates during an audit. Cloud workloads using public ACME providers like Let’s Encrypt for authentication workflows are also affected. A unified CLM platform providing visibility across all CA sources is essential to identify every certificate with the clientAuth EKU, regardless of issuer or deployment environment.

What common mistakes should teams avoid when migrating?

The most common mistakes are: assuming the migration only affects a small number of certificates without running a full discovery; deploying a private CA but not updating application trust stores to trust it; failing to revoke old public certificates after migration; not automating renewal for new private CA certificates; and not testing authentication flows after migration before the June 15, 2026 deadline.

What should be refreshed quarterly to stay compliant?

Refresh quarterly: complete certificate inventory for any certificates with the clientAuth EKU that may have been missed; private CA policy and certificate profiles; trust store configuration on all clients and services; and CLM policy rules to block issuance of non-compliant certificates. Also check the Chrome Root Program Policy page for updates, as the policy has already progressed from v1.6 to the current v1.8.