To improve security and compliance, starting May 2026, Google Chrome Root Program policy will require publicly trusted Certificate Authorities (CAs) to no longer issue Transport Layer Security (TLS) certificates containing the Client Authentication Extended Key Usage (EKU). Root programs such as Google Chrome, Mozilla, Apple, and Microsoft will enforce this policy.

While this may sound like a small change, it could impact organizations that rely on client authentication certificates from public CAs or use mutual TLS (mTLS).

A Quick Refresher on TLS Handshake

When a client, such as a browser on a laptop or mobile device, connects to a server, the two establish a secure communication channel using a TLS handshake.

The client begins with a ClientHello, proposing supported protocol versions and cipher suites. The server responds with a ServerHello, selecting the protocol and cipher suite, and sends its digital certificate containing its public key and other details.

The client validates the certificate chain against trusted Certificate Authorities (CAs). Both sides exchange key material (in modern TLSv1.3, this is done using ephemeral Diffie-Hellman, while in TLSv1.0 through TLSv1.2, this is done by sharing the PreMasterSecret). Unlike the previous versions of TLS, the server’s certificate (and the public key) is used for authentication, not for encrypting the session key.

 Both parties derive the same symmetric session key to encrypt all further communication.

This is a simplified explanation, but it highlights the role of certificates: they authenticate identities, while the session encryption uses symmetric keys negotiated during the handshake.

First Things First: What is EKU?

Extended Key Usage (EKU) is a certificate extension that specifies the intended purpose of the public key.

• For typical HTTPS connections, certificates include the Server Authentication EKU, allowing the client to confirm the server’s identity. The scenario explained above in the quick refresher is an example of a typical HTTPS handshake.In mutual TLS (mTLS), the client also presents a certificate. These client certificates typically contain the Client Authentication EKU, signaling that the certificate (and the included public key) is valid for authenticating the client.
• Other EKUs exist for different use cases, such as code signing, secure email, or user login.

Why Remove ClientAuth EKU?

The Client Authentication EKU is valuable in private PKI or specialized ecosystems, but it creates risk in the context of publicly trusted TLS certificates.

Public TLS certificates are intended solely for server authentication on the open Internet. If they also contain the ClientAuth EKU, they could be misused for purposes that public CAs cannot validate or govern (e.g., authenticating users into enterprise systems).

To avoid misconfiguration, misuse, and policy violations, the CA/B Forum decided that from May 2026 onward, publicly trusted CAs will not issue TLS certificates containing the ClientAuth EKU.

This does not mean client authentication is going away — it means organizations must use private PKI, enterprise PKI services, or sector-specific solutions instead of public TLS certificates for mTLS.

How to Prepare for the Change?

The first step is to determine whether an organization currently uses publicly issued client certificates with the ClientAuth EKU. As always, inventory is critical. A Cryptographic Bill of Materials (CBoM) or similar inventory workflow can help identify usage across your environment.

There are several options if the systems require client authentication certificates:

• Private Public Key Infrastructure (PKI) – Run an organization’s own certificate authority for client authentication.
• PKI-as-a-Service – Use a managed CA solution to issue client certificates with the required EKUs.
• Sector-specific solutions – For example, financial institutions may use X9 certificates (to be issued in collaboration with DigiCert) designed specifically for industry needs.

While technically possible, self-signed certificates are not recommended for enterprise-scale authentication due to the complexity of trust distribution.

In a Nutshell

The CA Browser Forum’s decision to remove ClientAuth EKU in publicly trusted TLS certificates reinforces the correct scope of use: public TLS certificates for server authentication only. Root programs like Chrome, Mozilla, Apple, and Microsoft will enforce this starting in May 2026.

Organizations that depend on mTLS or client authentication must plan accordingly by adopting private PKI or managed certificate services. Preparing now with a proper cryptographic inventory ensures a smooth transition before the deadline.

In a nutshell, now is the time to evaluate dependencies, update cryptographic inventories, and plan migrations. By preparing early, organizations can avoid disruption and ensure compliance with evolving PKI standards.