clientAuth EKU Removal

Action is required to maintain service continuity. The upcoming removal of the clientAuth EKU from publicly trusted certificates will break any services relying on them for client or machine authentication, for example in a typical mTLS (mutual TLS) setup. A managed transition to a Private PKI is the most strategic and compliant path forward.

What’s Changing

The End of Public Client Authentication

This change is coming from the Google Chrome Root Program (not the CA/Browser Forum), and in practice it applies to all public CAs that want to remain trusted in Chrome. The CA/Browser Forum may later follow with an alignment ballot, but the operational impact for relying parties is the same.

This direction has been discussed and anticipated for years: browsers have steadily narrowed the WebPKI’s scope to public server authentication, not general-purpose client identity.

Effective June 15, 2026:

All corresponding unexpired and unrevoked subscriber certificates issued on or after June 15, 2026 MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.

Some CAs have already stopped issuing publicly trusted TLS server certificates that include clientAuth.

This change separates the WebPKI’s role (public server authentication) from the role of client identity and access control (private client authentication). It affects any environment using publicly trusted certificates for client authentication, both browser and non-browser, such as VPN access, API gateways, device authentication, or internal service mesh communication.

This does not mean you can’t use client authentication or mTLS; it means client certificates should come from a Private PKI (or equivalent) while server certificates remain publicly trusted for serverAuth.

Scope note: This change is about publicly trusted TLS certificates (the WebPKI). It does not inherently prevent other certificate use cases (for example S/MIME or internal signing/sealing certificates) from including clientAuth, but it’s still recommended to consider a purpose-built clientAuth issuing CA for client identity.

More broadly, expect that root programs may continue to tighten and refine what is acceptable in publicly trusted certificates, and similar constraints could expand to additional public certificate profiles over time.

Direct Impact of clientAuth EKU Removal

Migration Challenges and Critical Risks

Moving away from public CAs for client identities introduces new strategic, technical, and sometimes compliance challenges that demand timely action and planning. We help you navigate these hurdles.

Identifying every system, application, and device that currently relies on the clientAuth EKU in public TLS certificates is complex and crucial to avoid surprise outages.

Transitioning requires an alternative public certificate purpose or designing, implementing, and securing a new Private PKI hierarchy (Root CA, Intermediate CAs) from the ground up or adopting PKIaaS.

Legacy devices and applications may require certificates based on a specific certificate profile and hierarchy.

Client certificates are often requested and managed by customers or partners, so you may need to coordinate their migration to a new issuance platform or have them obtain client certificates directly from you.

How Digitorus Enables a Secure Migration

We provide a full-service strategy to manage this complex transition, ensuring a seamless move to a compliant, resilient machine identity foundation.

Phased Migration Journey

Our structured approach addresses all technical and compliance requirements before deployment.

• Phase 1
  • Discover
    • Inventory all affected certificates and map dependencies.
• Phase 2
  • Strategy
    • Determine target architecture: Public, Private PKI, PKIaaS, or alternative method.
• Phase 3
  • Implement
    • Build or adopt the new CA environment and pilot enrollment and authentication.
• Phase 4
  • Migrate
    • Orchestrate the systematic replacement of old public TLS clientAuth certificates.

Supporting Capabilities for Private PKI

Our work is practical and outcome-focused: we work with you to choose the right approach for your environment and make it operable, without forcing a one-size-fits-all “build a PKI” program. That means aligning on the key decisions together (platform, issuance model, trust distribution, key protection) and producing the governance you actually need (controls, risk assessments, and CP/CPS updates where appropriate).

For clientAuth and mTLS, we focus on what breaks in production: consistent certificate profiles (EKUs, subject/SAN strategy), reliable enrollment at scale, partner/customer onboarding, and lifecycle hygiene (renewal, rotation, revocation).

Full-lifecycle support for designing and hardening your new CA hierarchy, including HSM strategy and key management.

Reviewing and updating your Certificate Policy and Practice Statement (CP/CPS) to meet new governance requirements for self-managed identities.

Implementing robust CLM platforms to automate issuance, renewal, and revocation of all private certificates (ACME, CMP, EST, SCEP).

Which New CA is Right for Your ClientAuth?

Public CAs are phasing out multipurpose certs, but the alternative can be complex. Do you need a Shared Public CA or a flexible Private PKI? Get unbiased expert guidance targeted to your usecase before you choose.

Start Your Independent PKI Strategy Session