How should security teams handle public TLS certificates used for mTLS and API authentication before Chrome’s June 2026 EKU change?

Why This Matters for Security Teams

Chrome’s June 2026 EKU change matters because it removes a common but brittle shortcut: using public-trust TLS certificates for non-browser machine authentication. That pattern has been convenient for mTLS, service-to-service API calls, and legacy integrations, but it blurs trust domains and makes certificate policy harder to enforce. NHI Management Group’s Critical Gaps in Machine Identity Management report found that only 38% of organisations have automated certificate lifecycle management in place, which means many teams will feel expiry and renewal failure before they feel the policy change.

The practical risk is not just a browser-facing outage. When the same public leaf certificate is reused for server authentication, client auth, and application trust decisions, a narrow EKU profile can break automated workflows, third-party integrations, and internal API meshes at the same time. Security teams should treat this as a forcing function to separate browser trust from workload trust, and to map every certificate to a specific authentication purpose. The guidance aligns with NIST control expectations for identity lifecycle and system authentication in NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many security teams discover certificate misuse only after an integration fails during rotation, rather than through intentional architecture review.

How It Works in Practice

The first step is inventory. Identify every public-trust certificate that is used for anything other than browser-facing HTTPS, including mTLS between services, API gateway authentication, device access, and partner integrations. The inventory should record the certificate issuer, subject, EKU, service owner, renewal method, and whether the certificate is actually acting as a server cert, a client cert, or both. If ownership is unclear, that is already a governance issue, not just a technical one.

From there, replace public-trust client and machine authentication with private PKI, sector PKI, or a workload identity model. For many environments, the better long-term pattern is workload identity backed by short-lived cryptographic credentials, rather than long-lived public leaf certificates. NHIMG’s Guide to SPIFFE and SPIRE is a useful reference for teams moving toward identity-bound workloads instead of certificate reuse. In parallel, adopt certificate lifecycle management so renewal is automated, revocation is tested, and expired material is not tracked in spreadsheets.

Operationally, teams should:

• Separate public TLS used for server authentication from all client or machine authentication uses.
• Move mTLS to private trust chains where the policy for EKU, issuance, and revocation can be enforced internally.
• Use short-lived certificates and automated renewal for workloads that change frequently.
• Test every dependency that consumes certificates, including service meshes, API gateways, and partner apps, before the browser policy change lands.

For identity governance, this is also a control-mapping exercise. NIST’s identity and authentication controls in NIST SP 800-53 Rev 5 Security and Privacy Controls support the shift from ad hoc certificate use to managed, purpose-specific trust. These controls tend to break down when certificate ownership is distributed across many engineering teams and renewal is still handled manually in multi-cloud and partner-facing environments because no single team can see every dependency in time.

Common Variations and Edge Cases

Tighter certificate policy often increases migration effort, requiring organisations to balance stronger trust separation against integration risk and change-window pressure. That tradeoff is especially sharp in legacy platforms, embedded devices, and vendor-managed services where public certificates were originally chosen because they were easy to deploy, not because they were semantically correct for client authentication.

There is no universal standard for this yet, but current guidance suggests a few practical exceptions. Public TLS can still be appropriate for browser-facing server authentication, but it should not be the default for mTLS or API auth. Some sectors may prefer sector PKI or regulated trust hierarchies over a fully private PKI, especially where external interoperability matters. Others will need a staged migration with dual trust paths: keep current certificates valid while new workload identities are introduced and tested.

This is where change management becomes security work. If a certificate is embedded in firmware, hard-coded into a third-party connector, or shared across multiple services, the fix is rarely just reissuing the leaf. It usually requires redesigning the authentication boundary. NHI Management Group’s Ultimate Guide to NHIs — What are Non-Human Identities helps frame why the identity, not the certificate alone, is the real unit of control. In mixed estates, the hardest failures usually appear where legacy systems, partner trust, and manual renewal processes overlap.

Related resources from NHI Mgmt Group

• How should security teams automate TLS certificate renewal before short-lived public certificates cause outages?
• How should security teams implement secretless authentication for AI API workloads in hybrid environments?
• How should security teams handle client-auth certificates in public CA environments?
• How should security teams handle API discovery when services change daily?