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.
At a glance
What this is: Chrome will stop trusting public TLS certificates with clientAuth EKU in June 2026, forcing organisations that rely on public CAs for client authentication to separate server and client certificate hierarchies.
Why it matters: PKI, IAM, and NHI teams need to inventory certificate use now because client authentication for devices, workloads, VPN, Wi-Fi, and mTLS will need dedicated governance before the cutoff.
By the numbers:
- From 15 June 2025, new subordinate CA certificates must include only serverAuth EKU.
- From 15 June 2026, Chrome distrusts any public TLS certificate containing the clientAuth EKU.
- CA/Browser Forum has already voted to reduce maximum TLS certificate validity to 47 days.
Context
Chrome Root Program Policy v1.6 changes public certificate trust by separating server authentication from client authentication in Chrome-trusted hierarchies. The practical problem is not just certificate policy, but the operational model many organisations built around a single public CA chain for multiple identity uses.
For PKI and NHI programmes, that means certificate inventory, issuance policy, and revocation logic now sit at the centre of identity governance. Any estate that uses certificates for device authentication, workload access, or VPN onboarding has to treat the Chrome cutoff as a lifecycle event, not a browser quirk.
The issue is typical, not edge case, because the article describes common enterprise use of public CAs for mTLS, Wi-Fi, SSO, and machine identity. Those patterns worked while multi-purpose public hierarchies were tolerated; they become brittle when trust boundaries tighten.
Key questions
Q: What breaks when public TLS certificates stop supporting client authentication?
A: Applications that depended on dual-purpose public certificates will lose a simple path for mTLS and client authentication. The main failure is not encryption, but trust semantics: one certificate can no longer safely represent both server identity and client identity in browser-trusted environments. Teams need a new certificate profile or a private PKI path.
Q: Why does Chrome’s client-auth policy change matter for PKI and IAM teams?
A: It forces certificate governance to distinguish between server identity and client identity, which means issuer choice, profile design, and lifecycle ownership now affect access continuity. PKI teams own the hierarchy, while IAM teams depend on it for device and workload authentication, so both have to treat it as an access-control issue.
Q: How should organisations migrate away from public CAs for client-auth certificates?
A: They should move client authentication to a dedicated private CA hierarchy, map every affected certificate to its dependent service, and reissue before expiry rather than waiting for the Chrome cutoff. Automation matters because manual tracking does not scale when multiple certificate types, owners, and renewal dates are involved.
Q: How should teams prioritise certificate lifecycle management over manual administration?
A: Teams should prioritise lifecycle management when certificate populations are too large for spreadsheets and ad hoc reminders. Central discovery, ownership and renewal workflows reduce the chance that critical certificates expire unnoticed across business units and hybrid environments.
Technical breakdown
Extended key usage is now a trust boundary
Extended Key Usage, or EKU, tells relying parties what a certificate may be used for. In the Chrome Root Program model, the same public hierarchy can no longer issue certificates that are valid for both serverAuth and clientAuth. That matters because client authentication is identity-bearing, while server authentication is service-facing, and mixing them in one public chain creates policy ambiguity at the trust-store level. The change is not about encryption strength. It is about constraining what a publicly trusted hierarchy is allowed to assert about identity roles.
Practical implication: Separate certificate profiles now so client-auth use cases do not depend on public TLS hierarchies.
Public CA convenience no longer scales for client identity
Public CAs historically gave enterprises a shortcut: one certificate chain could support browsers, device onboarding, and mutual TLS. Chrome Root Program Policy v1.6 removes that shortcut for client-auth certificates, which means trust policy becomes a lifecycle design issue. If a certificate is used to authenticate a workload, endpoint, or user device, its issuing hierarchy now needs a narrower purpose and a clearer renewal path. This is where machine identity governance becomes operational rather than theoretical. The certificate estate has to be mapped by purpose, not just by issuer.
Practical implication: Inventory every certificate by use case and rebuild issuance paths around client-auth specific hierarchies.
Certificate lifecycle management becomes the control plane
As validity windows shrink and trust rules tighten, manual certificate handling becomes unmanageable. Certificate Lifecycle Management, or CLM, is the coordination layer for discovery, renewal, revocation, and policy enforcement across the estate. For organisations affected by this policy, CLM is no longer a hygiene tool for infrequent renewals. It is the mechanism that keeps client-auth certificates from expiring, being misissued, or surviving beyond the trust boundary they were designed for. That is especially important where certificates support mTLS, device trust, and workload authentication.
Practical implication: Automate discovery, renewal, and revocation across both public and private certificate estates.
NHI Mgmt Group analysis
Dedicated hierarchy design is becoming a machine identity governance requirement: Chrome’s policy makes it clear that certificate purpose can no longer be treated as an administrative preference. Public trust stores are enforcing a narrower separation between server identity and client identity, which pushes certificate governance into a more explicit machine identity model. The practitioner implication is straightforward: the certificate hierarchy itself now has to reflect the identity function being performed.
Multi-purpose public certificates have created trust-boundary debt: The article shows how organisations relied on one public CA chain for several identity uses because it was convenient and cost-effective. That design carries hidden governance debt when the trust boundary changes, because the same issuance path cannot safely satisfy both browser-facing and client-auth obligations. The field lesson is that shared hierarchies are brittle when policy moves faster than lifecycle migration.
Certificate lifecycle management is the difference between migration and outage: Once Chrome’s enforcement date lands, the real issue is not whether a policy exists but whether the estate can be discovered, classified, and reissued in time. Shorter certificate validity only increases the pressure on renewal, revocation, and policy enforcement. Practitioners should treat lifecycle control as part of identity architecture, not a back-office certificate task.
Machine identity programmes need purpose-specific visibility: Many enterprises do not know where clientAuth certificates are embedded because those certificates were issued as infrastructure artifacts rather than governed identities. That lack of visibility is exactly what browser policy changes expose. The implication is that inventory quality, ownership, and certificate purpose tagging matter as much as cryptographic settings.
Chrome is accelerating a broader trust-boundary shift: This policy does not stand alone. It reinforces the direction of modern PKI toward tighter issuance rules, shorter lifetimes, and more explicit purpose separation. For identity teams, that means public trust is becoming less tolerant of operational shortcuts, and dedicated hierarchies are becoming the default governance pattern for client authentication.
What this signals
Dedicated certificate hierarchies are becoming the governance norm: Chrome’s policy shift shows that public trust stores are narrowing what a certificate may be allowed to do. That makes purpose-specific issuance more important than shared certificate convenience, especially where mTLS or device authentication depends on clientAuth EKU.
Certificate programmes that still rely on manual renewal tracking are carrying avoidable operational risk. As certificate lifetimes shorten and browser trust rules tighten, discovery and lifecycle automation become the only practical way to keep client-auth access paths working.
This policy also changes how identity teams should think about ownership. Client-auth certificates are not just technical artefacts; they are access credentials, and they need the same inventory, exception handling, and offboarding discipline as any other machine identity.
For practitioners
- Inventory all client-auth certificates Identify every certificate that contains clientAuth EKU and map each one to the service, device, workload, or user flow that depends on it.
- Split server and client hierarchies Design a dedicated TLS hierarchy for server authentication and move client authentication to a separate private CA path with purpose-specific profiles.
- Prioritise business-critical replacements Rank certificates by expiry date and operational dependency so the highest-risk client-auth paths are reissued first.
- Automate renewal and revocation Use certificate lifecycle management to track discovery, renewal, revocation, and policy enforcement across the full estate.
- Align PKI, DevOps, and security operations Assign owners for certificate profiles, migration timelines, and exception handling so the June 2026 cutoff is managed as a programme.
Key takeaways
- Chrome’s client-auth cutoff turns a browser policy into a machine identity governance problem for any organisation that still uses public CAs for authentication.
- The operational risk sits in certificate hierarchy design, because shared public chains can no longer cover both server and client authentication.
- The right response is to inventory clientAuth usage, move it to dedicated hierarchies, and automate certificate lifecycle management before enforcement starts.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | The article centres on certificate lifecycles and the need to reissue client-auth credentials before browser trust changes. |
| NHI-05 — Overprivileged NHI | Multi-purpose public certificates blur identity purpose and exceed the intended scope of client authentication. | |
| Recommendation — Audit certificate lifetimes and reissue client-auth credentials before trust-policy cutoffs. Separate client-auth certificates from server-auth hierarchies to reduce overbroad certificate scope. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate issuance, renewal, and revocation are authenticator lifecycle controls in this change. |
| Recommendation — Apply IA-5 to govern certificate issuance, renewal, and revocation across the estate. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Client-auth certificates grant access and therefore require explicit entitlement governance. |
| Recommendation — Map certificate-based access to PR.AA-05 and review entitlement scope by certificate purpose. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Client-auth certificates function as credentials and are part of the access path under policy pressure. |
| Recommendation — Track client-auth certificate exposure as credential access risk in your detection and response planning. | ||
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: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
- 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.
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI programme, it is worth exploring.
Published by the NHIMG editorial team on July 12, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org