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

The CA/Browser Forum (CA/B Forum) is moving to prohibit the inclusion of the clientAuth Extended Key Usage (EKU) in certificates issued by public CAs. This change separates the WebPKI’s role (public server authentication) from the role of machine identity and access control (private client authentication). This affects all enterprises using public certificates for non-browser client authentication, such as VPN access, API gateways, or internal service mesh communication.

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.

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 expertise covers the full spectrum of private machine identity management and governance.

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

Reviewing and updating your Certificate Policy (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 (SCEP, EST, CMP).

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