Chrome Root Program v1.6 forces dedicated client-auth certificate hierarchies

At a glance

What this is: Chrome Root Program Policy v1.6 removes public CA support for client-auth TLS certificates, pushing organisations toward dedicated certificate hierarchies and automated lifecycle management.

Why it matters: For IAM and NHI teams, this changes certificate governance from a background PKI issue into a migration, inventory, and lifecycle control problem across devices, APIs, and workloads.

By the numbers:

• 47 days.
• Certificates already issued before the June 2026 cutoff remain valid until their natural expiry.

👉 Read eMudhra’s analysis of Chrome Root Program Policy v1.6 and certificate migration

Context

Chrome Root Program Policy v1.6 narrows public certificate trust by removing client authentication from public CA-issued TLS certificates. That matters because many organisations have treated clientAuth EKU as a convenience layer for devices, users, and workloads without separating issuance models by purpose.

The identity governance problem is not just certificate expiry. It is the hidden dependency on public trust hierarchies for non-human and device authentication, where one certificate pattern may be embedded across VPN access, Wi-Fi onboarding, mTLS, and workload identity.

For certificate-heavy environments, this is a lifecycle event as much as a PKI policy change. The organisations most exposed are those that cannot quickly inventory where clientAuth EKU is used, who owns those certificates, and which services will fail when Chrome stops trusting them.

Key questions

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. The key is to treat certificate purpose as an identity governance decision, not a convenience choice driven by legacy PKI habits.

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. For service certificates and workload identities, that is the point where governance can either create traceable lifecycle records or introduce unmanaged trust. If the request is not governed, the certificate is only partially accountable.

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. Services fail when a certificate expires, teams lose visibility when ownership is fragmented, and outage response becomes reactive instead of governed. The result is avoidable downtime, repeated exceptions, and an estate that grows faster than the people managing it.

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.

Technical breakdown

Why clientAuth EKU in public certificates is being removed

Extended Key Usage tells a relying party what a certificate may be used for. Historically, some public certificate hierarchies allowed both serverAuth and clientAuth in the same issuance chain, which made it possible to reuse the same public trust anchor for multiple authentication roles. Chrome Root Program Policy v1.6 rejects that model by requiring public hierarchies in its root store to be dedicated to server authentication. The technical effect is simple: client authentication must move out of the public trust plane and into controlled enterprise hierarchies or other fit-for-purpose identity systems.

Practical implication: Separate certificate profiles now, before browser trust changes force an emergency migration.

What changes for mTLS, VPN, and workload identity

TLS client authentication is the certificate-based mechanism that proves the client, not the server, during connection setup. That pattern appears in mTLS between services, in VPN access for managed devices, and in workload identity flows where certificates stand in for a service account or token. Once public CAs can no longer issue clientAuth certificates that Chrome will trust, any architecture relying on that model needs a new issuance source and a clear lifecycle path. The risk is not only browser rejection. It is operational drift where legacy certificates continue working in some channels while failing in others.

Practical implication: Map every client-auth dependency to its issuing hierarchy and replace public trust with dedicated enterprise PKI.

Why certificate lifecycle management becomes the control point

Certificate Lifecycle Management, or CLM, is the operational layer that discovers certificates, renews them, revokes them, and enforces issuance policy across the estate. It becomes essential when certificate validity periods shorten and trust rules become more specific, because manual spreadsheets cannot keep up with expiry windows, EKU restrictions, and replacement timing. The issue is especially acute for NHI and workload identity, where certificate sprawl often exceeds human-owned certificates and ownership is unclear. In practice, CLM is the difference between a controlled migration and a broken authentication estate.

Practical implication: Use CLM to discover all client-auth certificates, enforce renewal policy, and eliminate manual tracking.

NHI Mgmt Group analysis

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.

Client-auth certificates are becoming a machine identity governance issue. VPN devices, Wi-Fi endpoints, service-to-service connections, and embedded workloads all use certificates as identity proof, yet many teams still manage them as infrastructure artefacts. OWASP-NHI and NIST CSF both point to the need for ownership, lifecycle, and access controls that follow the identity, not the platform. Practitioners should treat clientAuth EKU as a governance boundary, not a technical detail.

Dedicated trust hierarchies are now the sane default for non-human authentication. The old convenience of dual-purpose public certificates hid ownership, renewal, and revocation complexity until it became operational risk. Chrome’s policy validates a stricter model where server authentication, client authentication, and workload identity are deliberately separated. For identity teams, that means certificate purpose must be explicit enough to survive policy enforcement outside the enterprise perimeter.

Certificate lifecycle discipline is now part of Zero Trust execution. Zero Trust architecture assumes every identity interaction is continuously evaluated, but that only works when the organisation knows which certificates exist, who owns them, and when they expire. The attack surface here is not an attacker in the classical sense. It is unmanaged trust drift. The practical conclusion is that certificate discovery and offboarding must be brought into standard identity governance, alongside NHI rotation and access review.

Certificate lifecycle drift is the named concept this policy change makes visible. A certificate can remain technically valid while becoming operationally non-compliant with browser trust rules or business authentication needs. That gap is what makes migration fragile: the certificate still exists, but its intended use no longer does. Practitioners need to think in terms of lifecycle drift across issuance, usage, and trust policy, because the identity problem is now temporal as well as technical.

From our research:

• 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.
• For the operational next step, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs explains how to govern issuance, rotation, and offboarding across non-human identities.

What this signals

Certificate lifecycle drift is now a programme-level risk, because browser trust policy can invalidate an identity pattern even when the underlying certificate is still technically unexpired. Teams that still manage certificates as infrastructure inventory, rather than identity assets, will absorb the change as outage risk instead of planned migration.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, certificate governance should be treated as part of the same hidden-asset problem set. The practical response is to unify discovery, ownership, and renewal reporting across certificates, keys, and tokens.

This policy shift also reinforces the Zero Trust assumption that identity context must be explicit and continuously managed. If your programme cannot answer where client-auth certificates exist, which ones are public-CA issued, and who owns replacement, then the migration is already late.

For practitioners

• 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.
• Align PKI ownership with identity governance Assign explicit ownership for certificates used in VPN, Wi-Fi, mTLS, and workload identity so revocation and replacement are not delayed by unclear accountability.

Key takeaways

• Chrome’s v1.6 policy change removes public trust for client-auth certificates and forces enterprises toward dedicated certificate hierarchies.
• The operational risk is not only browser distrust but also weak inventory, unclear ownership, and manual lifecycle management across machine identities.
• Teams should treat certificate purpose, lifecycle, and trust boundary as identity governance controls, not as isolated PKI settings.

Key terms

• Client Certificate Authentication: A method of proving a device or user possesses a trusted private key and certificate during connection setup. In identity programmes, it functions as an authentication credential, but its security depends on how tightly issuance, storage, renewal, and revocation are governed across the endpoint lifecycle.
• Extended Key Usage: Extended Key Usage is the certificate extension that limits what a certificate can be trusted to do. In practice, it separates server authentication, client authentication, code signing, and other trust roles so one certificate cannot safely be reused everywhere without policy consequences.
• Certificate Lifecycle Management: Certificate Lifecycle Management is the operational discipline of discovering, issuing, renewing, revoking, and retiring certificates across an environment. It becomes essential when certificate trust rules change or validity windows shrink, because manual tracking cannot sustain reliable identity governance at scale.
• Dedicated Certificate Hierarchy: A dedicated certificate hierarchy is a CA structure created for one authentication purpose, such as server authentication or client authentication. It reduces trust ambiguity by separating issuance rules, ownership, and revocation paths, which is increasingly necessary for machine identity governance.

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

👉 eMudhra’s full article covers the trust-policy change, migration path, and lifecycle controls in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity programme, it is worth exploring.