TL;DR: Browsers led by Google are ending support for dual-EKU public TLS certificates, which will remove ClientAuth from browser-trusted roots and force organisations to redesign mTLS and other client-authentication patterns, according to DigiCert. The shift exposes how much enterprise trust infrastructure depended on certificates doing two jobs at once.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: Browser support for dual-EKU public TLS certificates is being removed, which breaks the long-standing practice of using one certificate for both server and client authentication.
Why it matters: IAM and platform teams that rely on client certificates for mTLS must separate certificate purpose, re-evaluate trust boundaries, and decide when internal PKI is the right control plane.
Context
Public TLS certificates have long been asked to do two jobs at once: authenticate servers and also act as client certificates for mTLS and other access patterns. The problem is not certificate technology itself, but the governance assumption that one browser-trusted certificate profile can safely serve multiple identity purposes.
That assumption is now colliding with browser root programme changes led by Google and followed by public certificate authorities. For identity teams, the issue reaches beyond web hosting and into machine identity, client authentication, and the lifecycle decisions that determine whether trust belongs in the public Web PKI or a private PKI.
The practical question is no longer whether certificates can support client auth in theory. It is which certificate authority model, trust boundary, and issuance policy can support client authentication without depending on dual-use certificates that browser trust stores are removing.
Key questions
Q: What breaks when dual-EKU TLS certificates are no longer trusted for client authentication?
A: Client-authentication patterns that depended on a single public certificate for both server and client roles will stop working cleanly in browser-trusted environments. The main failure is not cryptography but purpose mismatch, because the certificate no longer fits the trust policy that applications and root stores expect.
Q: When should organisations use private PKI instead of public certificates for client auth?
A: Private PKI is usually the better fit when client authentication is limited to internal systems, administrative access, or services that do not need browser trust. It gives the organisation control over issuance, naming, and lifetime, and it avoids exposing internal infrastructure through public trust mechanisms such as certificate transparency.
Q: How should teams design mTLS when client certificates must work across the internet?
A: Treat internet-facing mTLS as a dedicated trust architecture, not an extension of internal certificate practice. Teams should map each external dependency to a certificate purpose, then choose a public client-auth path that is explicitly allowed by the trust model.
Q: Why do browser root programme changes matter for enterprise certificate governance?
A: Because browser trust programmes define what public certificates are allowed to represent. When those rules change, organisations must adjust inventory, issuance policy, and application dependencies instead of assuming certificate reuse will continue to work.
Technical breakdown
Why dual-EKU certificates are being phased out
Extended Key Usage, or EKU, is the X.509 extension that tells relying parties what a certificate is allowed to do. Dual-EKU public TLS certificates carried both serverAuth and clientAuth, which let one certificate satisfy browser trust requirements and client-authentication use cases at the same time. Browser root programmes are now refusing that combined model because it blurs certificate purpose and makes public trust anchors do more than one governed job. In practice, that means existing issuance patterns that assumed a single public certificate could serve both ends of a connection are being retired.
Practical implication: Separate server and client certificate purposes in your architecture before browser trust-store changes remove the combined profile.
Why mTLS is the hardest edge case
Mutual TLS depends on both sides presenting certificates, but the client side does not always fit neatly into the public Web PKI model. Internal applications can move to private PKI, but internet-facing partner connections, B2B integrations, and other external client-authentication flows need a trust model that remains browser-compatible or deliberately outside the Web PKI. That is why the article distinguishes internal PKI from dedicated public PKI for client auth. The design issue is not mTLS itself, but where the trust anchor lives and what identity purpose it is allowed to represent.
Practical implication: Map each mTLS use case to its trust boundary and move internet-facing client auth away from browser-trusted dual-use certificates.
When internal PKI is the cleaner control
Internal PKI is often the better fit when client certificates authenticate assets that never leave the private network. In that model, the organisation controls issuance policy, certificate fields, lifespan, and revocation rules, instead of inheriting browser root constraints and Certificate Transparency exposure. The trade-off is operational: private CA management takes expertise and lifecycle discipline. But where the application boundary is internal, using public certificates for client auth adds risk without adding meaningful interoperability. The control decision therefore follows network scope and governance ownership, not certificate familiarity.
Practical implication: Use private PKI for internal client-authentication use cases where browser trust is unnecessary and certificate governance must stay local.
Threat narrative
Attacker objective: The practical objective is not attacker-driven compromise but control-plane disruption avoidance, namely preserving client authentication after the browser trust model changes.
- Entry occurs when organisations continue issuing dual-EKU public TLS certificates for client authentication after browser trust programmes begin removing that profile.
- Escalation happens when certificate issuance, trust-store assumptions, and application dependencies remain coupled to one certificate doing two different identity jobs.
- Impact is loss of client-auth compatibility for mTLS and other external application flows that depended on browser-trusted dual-use certificates.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Dual-EKU deprecation is an identity-purpose problem, not just a certificate-format change. The browser ecosystem is forcing organisations to stop treating one public certificate as a universal trust object. That matters because trust policy, not cryptography alone, defines what a certificate is allowed to authenticate. Practitioners should read this as a lifecycle and governance reset for client-authentication design.
Dual-use certificates created hidden governance debt in the Web PKI. They let teams defer the harder question of whether a workload needed a server identity, a client identity, or both. Once browser roots remove support for combined EKUs, that debt becomes visible as application breakage and redesign work. The right lens is certificate purpose separation, not just migration urgency.
ClientAuth outside internal networks now belongs in a dedicated trust architecture. Internet-facing mTLS is not an internal PKI problem with a simple browser workaround. It is a trust-boundary problem that demands purpose-built issuance and clear ownership of certificate policy. That shifts the centre of gravity from ad hoc certificate reuse to explicit machine identity governance.
Internal PKI becomes the default for many client-authentication workloads that never needed public trust in the first place. If an application never leaves the private environment, public browser roots add exposure without solving a real interoperability need. The governance decision should be based on where the relying party lives and who owns revocation, audit, and issuance policy. Practitioners should reclassify these certificates as workload identity assets, not web assets.
Purpose-built public PKI is now a niche control, not a general-purpose substitute. The article shows that some high-trust external use cases still need public client certificates, but those are bounded exceptions rather than the norm. That means identity teams need a portfolio view of certificate issuance paths, with public client auth reserved for cases that truly cross organisational trust boundaries. The practitioner takeaway is to design from use case to trust model, not from certificate convenience to architecture.
What this signals
Certificate purpose separation is becoming the governing principle for client authentication. Teams that used public TLS certificates as flexible identity artifacts now need to decide whether a certificate is a server credential, a client credential, or a private trust asset. That decision should sit in the identity architecture, not in ad hoc application exceptions.
Browser trust constraints are pushing workload identity decisions upstream. Once client auth can no longer ride on dual-EKU public certificates, the choice between public and private PKI has to be made at design time. That gives IAM and platform teams a stronger reason to catalogue mTLS use cases by trust boundary and certificate purpose before migration work starts.
For practitioners
- Separate server and client certificate inventories Classify every certificate by purpose, issuer, and relying-party scope so dual-EKU assumptions can be removed before browser trust changes take effect.
- Move internal client auth to private PKI Use an internal PKI for applications that never need browser-trusted roots, and set explicit issuance, revocation, and lifespan rules for those workloads.
- Re-map internet-facing mTLS dependencies Identify partners, external services, and applications that require client authentication across the internet and decide whether they need a dedicated public PKI path.
- Review Certificate Transparency exposure Check whether public certificates are exposing internal hostnames or service names that should not be visible outside the private environment.
Key takeaways
- Dual-EKU public TLS certificates are being phased out, which forces organisations to stop using one certificate for both server and client authentication.
- The main operational impact is on mTLS and other client-authentication flows that relied on browser-trusted roots.
- Teams should separate certificate purpose, move internal use cases to private PKI, and reserve public client auth for truly external trust boundaries.
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 CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Certificate purpose changes force retirement of old dual-use issuance patterns. |
| NHI-07 — Long-Lived Secrets | Client certificates often persist far longer than the trust assumptions behind them. | |
| Recommendation — Retire dual-use certificate profiles and remove obsolete issuance paths before browser trust changes break them. Shorten certificate lifetimes where policy allows and track renewal against actual client-auth need. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 governs authenticator lifecycle, including certificate issuance and rotation. |
| Recommendation — Apply IA-5 to distinguish server and client authenticators and govern their lifecycle separately. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article is fundamentally about identity purpose, trust boundaries, and certificate-based access. |
| Recommendation — Align certificate issuance and trust boundaries with IAM policy for internal and external client authentication. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Client certificates are access credentials whose misuse or reuse affects authentication paths. |
| Recommendation — Track certificate-based client auth as a credential class and review where access depends on it. | ||
Key terms
- Dual-EKU Certificate: A certificate that carries both server authentication and client authentication in its Extended Key Usage extension. In this article’s context, the problem is not the cryptography but the governance assumption that one public certificate can safely represent two different identity purposes.
- Client Authentication Method: A client authentication method is the mechanism an OIDC client uses to prove its identity to the token endpoint. Common methods include shared-secret approaches and private key JWT. The provider must recognise the registered method, otherwise the code exchange fails even when the rest of the flow is configured correctly.
- Mutual Tls: Mutual TLS is a transport security method where both client and server present certificates and authenticate each other. In implant frameworks, it helps prevent impersonation, supports encrypted sessions, and ties each deployment to its own trust material rather than shared credentials.
- Internal PKI: Internal PKI is the private certificate infrastructure an organisation uses for internal services, workloads, and trusted communications. It often carries more hidden dependency than public TLS because ownership, renewal paths, and exception handling may be less visible and less automated.
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 IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org