Notifications
Clear all
Topic starter
12/07/2026 12:18 pm
TL;DR: Chrome Root Program Policy v1.6 will distrust public TLS certificates carrying clientAuth EKU from 15 June 2026, forcing organisations that use public CAs for client authentication, mTLS, VPN, Wi-Fi and workload identity to move to dedicated hierarchies, according to eMudhra. The policy turns certificate lifecycle and trust-boundary management into an immediate machine identity governance issue rather than a routine PKI preference.
NHIMG editorial — based on content published by eMudhra: Chrome Root Program Policy v1.6: What It Means for Your Certificates
By the numbers:
- CA/Browser Forum has already voted to reduce maximum TLS certificate validity to 47 days.
- Certificates already issued before the June 2026 cutoff remain valid until their natural expiry.
Questions worth separating out
Q: How should security teams handle client-auth certificates in public CA environments?
A: They should inventory every certificate that uses clientAuth EKU, determine which identities and workloads depend on it, and move those dependencies to a dedicated enterprise CA or another controlled trust hierarchy.
Q: Why do certificate signing requests matter for machine identity governance?
A: CSRs matter because they are the moment identity intent, cryptographic material, and approval policy come together.
Q: What breaks when certificate lifecycle management is still manual?
A: Manual certificate management breaks at the point where expiry, ownership, and renewal do not line up.
Practitioner guidance
- Audit all client-auth certificate usage Identify every certificate that includes clientAuth EKU and map each one to the service, device, workload, or user workflow that depends on it.
- Separate server and client certificate hierarchies Move client authentication off public trust anchors and into a dedicated enterprise CA hierarchy with clear issuance policy and ownership.
- Automate certificate discovery and renewal Use certificate lifecycle management to discover, renew, revoke, and report on certificates before shortening validity windows create outages.
What's in the full article
eMudhra's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step audit actions for identifying certificates with clientAuth EKU across devices, VPNs, and mTLS services
- Migration guidance for moving from public CA trust to a dedicated CA hierarchy with controlled issuance policy
- Implementation details for certificate lifecycle management, including renewal, revocation, and discovery workflows
- Practical planning considerations for aligning IT, DevOps, and security operations around the June 2026 cutoff
👉 Read eMudhra’s analysis of Chrome Root Program Policy v1.6 and certificate migration →
Chrome’s client-auth certificate cutoff: what should PKI teams change now?
Explore further
12/07/2026 12:31 pm
Chrome’s change exposes a certificate trust-boundary problem, not just a browser policy update. Organisations that used public CAs for client authentication were implicitly relying on a trust model designed for server validation. Once Chrome removes clientAuth EKU from public trust, that assumption collapses and the certificate estate must be reclassified by authentication purpose, not by issuer convenience. The implication is that certificate governance now belongs inside identity architecture, not just infrastructure operations.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when client-auth certificates stop working after a browser policy change?
A: Accountability sits with the team that owns certificate governance, not just the CA administrator or infrastructure operator. Browser policy changes expose unclear ownership across identity, security, and platform teams, so the organisation needs a named certificate owner and a migration plan tied to business services.
👉 Read our full editorial: Chrome Root Program v1.6 forces dedicated client-auth certificate hierarchies
