Dual-EKU TLS deprecation is forcing clientauth certificate redesign

At a glance

What this is: Public TLS certificates that combine server and client authentication are being phased out, changing how organisations implement mTLS and other client-authentication use cases.

Why it matters: IAM and security teams must separate certificate purposes, reassess public versus private PKI, and avoid treating certificate type as a generic trust primitive across workloads and users.

👉 Read DigiCert's analysis of the end of dual-EKU TLS for clientAuth and mTLS

Context

Public TLS certificates were widely used as a convenience layer for both server and client authentication, but that model is now breaking as browser trust stores move away from dual-EKU issuance. For identity teams, the issue is not just certificate hygiene, but whether client authentication still belongs in the public Web PKI at all.

The governance question is familiar across NHI and access programmes: one credential artefact was being asked to cover multiple trust functions. That works until ecosystem policy changes, at which point mTLS, partner connections, and internal applications need a clearer separation between public trust, private trust, and certificate lifecycle control.

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: 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 do security teams know whether mTLS needs a redesign?

A: If mTLS depends on certificates that were issued for both server and client use, the design needs review. A redesign is also needed when the same certificate pattern is used across internal and external trust domains, because the policy change will not affect all environments equally. Purpose should determine the PKI model.

Q: What is the difference between public PKI and private PKI for workload identity?

A: Public PKI is designed for broadly trusted identities that need external validation, while private PKI is controlled by the organisation and better suited to internal workload and client identities. The difference is governance, not just technology. Public trust reduces distribution effort, but private trust gives tighter control over lifecycle and exposure.

Technical breakdown

Why dual-EKU certificates are being retired

Extended Key Usage determines what a certificate is allowed to authenticate. Dual-EKU public TLS certificates historically carried both serverAuth and clientAuth, which made them flexible but also blurred trust boundaries. Browser root programmes are now removing support for that pattern, so certificates trusted for web server use will no longer be accepted for the client-authentication role in the same way. The operational issue is not simply issuance policy. It is that browser trust infrastructure is tightening around single-purpose trust, which breaks older assumptions about one certificate profile serving multiple identity functions.

Practical implication: inventory every application that depends on dual-EKU public certificates and map each one to a single-purpose replacement path.

mTLS and client authentication across the internet

Mutual TLS depends on both ends of a connection presenting certificates that are valid for their intended role. When clientAuth disappears from browser-trusted public certificates, internet-facing mTLS flows can no longer rely on the same public Web PKI patterns that many internal teams used for convenience. Internal PKI can still work for closed environments, but it does not solve external partner or cross-internet trust requirements. That means client identity, certificate issuance policy, and trust distribution must be designed together instead of being treated as a generic TLS configuration choice.

Practical implication: separate internal-only client authentication from externally exposed mTLS and assign each to the correct PKI model.

Public PKI versus private PKI for certificate governance

Public PKI is governed by browser root programmes and public assurance requirements, while private PKI gives the organisation direct control over issuance rules, validity periods, and subject data. That matters because client-authentication certificates often expose more operational and identity detail than server-only certificates, especially when certificate transparency and internal hostname disclosure are in play. The architectural trade-off is simple: public trust reduces friction for external use cases, while private trust increases control for internal ones. Teams need to classify certificate purpose before choosing the trust domain.

Practical implication: establish certificate purpose-based policy so internal services do not default to public certificates when private PKI is the safer fit.

NHI Mgmt Group analysis

Dual-EKU retirement is a certificate-purpose governance failure, not just a browser policy change. The old model assumed one public certificate could legitimately carry both server and client trust semantics. That assumption was convenient for operations, but it was always fragile because it blurred identity purpose inside the certificate itself. The implication is that certificate programmes now need to be designed around purpose separation, not reuse.

Client authentication is being pulled out of the Web PKI because trust domains were too loosely defined. Browser-root governance is enforcing a stricter boundary between public server identity and client identity. For identity architects, that means certificate policy, trust distribution, and application design can no longer be treated as separate decisions. Teams that relied on public TLS for clientAuth must re-evaluate whether they were using the right trust plane in the first place.

Purpose-built PKI is becoming a governance pattern for NHI, not an implementation detail. When certificates are used for workload, partner, or service authentication, the real question is which trust domain owns the identity lifecycle. That is a lifecycle and privilege problem as much as a transport problem. The practitioner conclusion is to align certificate issuance with the identity type and the reach of the application, instead of optimising for certificate convenience.

Certificate transparency changes the risk calculus for internal exposure. Public certificates can reveal internal hostnames and service structure, which can increase reconnaissance value for attackers. That is not a reason to avoid public PKI everywhere, but it is a reason to stop assuming public trust is neutral when the service is only internal. The right control choice depends on whether the identity is meant to be externally discoverable.

Post-quantum planning should be layered into certificate redesign now. The article signals that X9 PKI will support PQC, which reinforces a broader lesson for identity programmes: certificate migration is not a one-time swap, it is part of an ongoing trust infrastructure roadmap. Teams that use this moment only to replace expired patterns will miss the chance to rationalise certificate purpose, trust boundaries, and future crypto transition at the same time.

From our research:

• 66% say their current tooling is not adequate to manage the scale of machine identities they now have, according to The Critical Gaps in Machine Identity Management report.
• 59% of companies face greater difficulties auditing machine identities, primarily due to lack of clear ownership and limited visibility.
• For a broader view of where certificate and workload identity governance is heading, see Ultimate Guide to NHIs , 2025 Outlook and Predictions.

What this signals

Purpose separation is becoming the default trust model for machine identities. Once certificates can no longer double as both server and client credentials in browser-trusted environments, teams have to decide which identity function each certificate serves and which PKI owns it. That pressure will push more organisations toward explicit lifecycle control for certificates, especially where mTLS extends beyond a single internal network.

With 66% of identity professionals saying current tooling is not adequate for machine-identity scale, per The Critical Gaps in Machine Identity Management report, the operational message is clear: certificate policy changes will surface governance debt that was already there.

Certificate-purpose governance: if the same certificate template is used for multiple trust roles, the organisation is carrying hidden policy risk. Teams should treat certificate redesign as an inventory and ownership exercise, not just a cryptographic migration, and align it with the identity lifecycle already described in Ultimate Guide to NHIs , What are Non-Human Identities.

For practitioners

• Inventory dual-EKU dependencies Identify every application, service, and partner flow that still relies on a public certificate carrying both serverAuth and clientAuth. Classify each dependency by whether it is internal-only, internet-facing, or partner-mediated, then assign a replacement path before browser trust changes remove the old option.
• Separate client authentication from server TLS policy Create distinct certificate profiles for server authentication and client authentication, and stop treating one certificate template as a universal trust object. Where mTLS crosses organisational boundaries, require explicit trust-domain ownership and documented certificate purpose.
• Choose private PKI for internal-only identities Move internal services and administrative interfaces that never cross the internet to private PKI where you control subject naming, issuance rules, and lifetime. Use public certificates only when the application truly needs browser-trusted or external trust distribution.
• Review certificate transparency exposure Check whether internal hostnames or service names are being surfaced through public certificate issuance. If they are, assess whether the visibility is acceptable or whether the service should be reissued under a private CA to reduce reconnaissance risk.
• Build PQC into the replacement roadmap When replacing dual-EKU certificates, avoid a one-for-one migration mindset. Use the redesign to document renewal timing, ownership, and future cryptographic agility so the next trust transition does not repeat the same operational scramble.

Key takeaways

• Dual-EKU retirement exposes a long-standing trust design problem: certificates were being used for multiple identity purposes at once.
• The impact will be felt most by mTLS and other client-authentication flows that assumed public certificates could cover both roles.
• Practitioners should separate certificate purpose, choose the correct PKI domain, and use the migration to tighten identity lifecycle control.

Key terms

• 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.
• Mutual TLS: Mutual TLS is a connection pattern where both sides present certificates and validate each other. It is commonly used for service-to-service and partner authentication, but it depends on the certificate being valid for the specific identity role and trust domain in which it operates.
• Private PKI: Private PKI is a certificate authority and trust hierarchy operated by the organisation rather than the public browser trust ecosystem. It gives direct control over issuance, naming, and lifetime, which makes it useful for internal services and identities that should not depend on public trust roots.
• Certificate Transparency: Certificate Transparency is a public logging system for issued certificates that increases visibility into certificate issuance. It also means internal names or service details can be exposed when public certificates are used for internal infrastructure, which changes the reconnaissance risk profile.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: What the End of Dual-EKU TLS Means for ClientAuth and mTLS. Read the original.