������

Browser vendors are drawing a clear line in the sand: As of June 15, 2026, public TLS server certificates must no longer include the Client Authentication EKU. While the change might seem technical, it will carry significant consequences—especially for sectors like financial services that rely heavily on certificate-based authentication.

As certificate requirements narrow, it’s essential that organizations rethink how they separate public and private trust—a shift that aligns with growing industry efforts to modernize PKI for financial services, including participation in the recently launched X9 PKI Industry Forum.

The EKU cleanup: What’s changing and why it matters

Extended Key Usage (EKU) is a field in X.509 certificates that specifies how the certificate should be used. Historically, some public TLS server certificates—those securing your HTTPS websites—carried both Server Authentication and Client Authentication EKUs. The latter (OID 1.3.6.1.5.5.7.3.2) is intended for client certificates used in mutual TLS (mTLS), not for servers.

That overlap wasn’t strictly forbidden under older CA/Browser Forum Baseline Requirements, but it was considered poor hygiene. Including ClientAuth in server certificates created ambiguity and potential security risks, like misuse of server certificates in client authentication scenarios—a violation of the principle of least privilege.

Now, major browsers are stepping in: Google Chrome announced enforcement policies that will reject any server certificate with the ClientAuth EKU, and Mozilla is likely to follow suit. This is part of a broader move to eliminate multipurpose roots—certificate chains that support multiple roles, like both server and client authentication—which Google sees as a security risk.��

Public certificate authorities (CAs) that continue to include it after the change goes into effect risk their certificates being distrusted by browsers—a potentially catastrophic event for organizations relying on them.

What this means for TLS certificates going forward

It’s possible that the ClientAuth EKU was never necessary for your use case, and all you need to do is reissue your certificate without it. Once enforcement begins in 2026, its presence in server certificates will be a red flag, likely pointing to:

• A legacy or expired certificate,
• A misconfigured internal PKI, or
• A non-compliant CA issuing certificates that may soon be rejected by browsers.

So if you’re seeing new certificates—even from major platforms—with the ClientAuth EKU, it’s worth asking: Is this an oversight, or is it a legacy practice that needs urgent attention?

Financial services: Why PKI modernization matters

Here's where things get interesting. The financial industry has long operated on parallel PKI infrastructures: public CAs for browser trust, and internal (or private) PKIs for tightly scoped internal use cases like mTLS, smart cards, and device identity.

But that fragmentation creates complexity, and in some cases, risk—like reusing certificates across incompatible roles. Where publicly trusted certificates were used to implement these internal use cases, they’ll need to be replaced with certificates from another source.��

The X9 PKI Industry Forum—recently launched by the Accredited Standards Committee X9—is creating a vendor-neutral forum that helps financial institutions, CAs, and service providers collaborate on practical PKI guidance and interoperability.

Rather than promoting a single standard, the forum supports open dialogue and technical alignment around scalable, interoperable PKI architectures for the financial industry.��

The EKU enforcement is a catalyst

The browser enforcement of EKUs is, in effect, a forcing function. It’s prompting financial institutions to reevaluate how they handle authentication, certificate lifecycle management, and separation of duties between public and private trust infrastructures.

In practice, this means:

• Moving away from “Swiss Army knife” certificates that serve multiple roles.
• Establishing or enhancing private CAs that can issue ClientAuth-enabled certificates—for internal mTLS, S/MIME, and identity use cases—without impacting public trust.

The net result? Stronger, more maintainable PKI architectures that align with evolving industry expectations and modern browser policies.

A path forward for financial PKI

The removal of ClientAuth from public TLS certificates isn’t just a compliance update—it’s a turning point. It signals that digital trust is becoming more precise, more purpose-built, and more tightly governed. For financial institutions, that means reexamining how PKI is deployed across the organization.

This is an opportunity to:

• Build a stronger foundation of digital trust with interoperable, policy-aligned certificates.

• Modernize private PKI to support agile use cases like mTLS, code signing, and identity at scale.

• Separate public and private trust zones to reduce risk and improve manageability.

Collaborative efforts like the X9 PKI Industry Forum are helping financial organizations navigate this shift with shared guidance, technical alignment, and future-ready frameworks.

Whether you’re a financial institution considering adoption of the X9 PKI standard or an enterprise assessing your mTLS setup, this shift is a reminder: Certificate hygiene is no longer optional. It’s foundational to secure, reliable digital trust. Organizations that act now—by auditing their certificate usage, modernizing private PKI, and adopting purpose-built trust models—will be in a stronger position to define and control how digital trust operates across their financial ecosystem.

The latest developments in digital trust

Want to learn more about topics like PKI, certificate management, and digital trust? Subscribe to the ������ blog to ensure you never miss a story.