The End of Client Authentication EKU in Public TLS Certificates

What This Industry Shift Means for Security, mTLS, and Certificate Strategy

Public TLS certificates are undergoing an important structural change. By 2026, publicly trusted SSL/TLS certificates will no longer support client authentication (clientAuth EKU). While this change may sound technical, its real-world impact depends entirely on how certificates are used within your environment.

For most websites, nothing changes. For organizations using mutual TLS, device authentication, or certificate-based identity, however, this shift requires planning.

This article explains the change clearly, why it is happening, and what technical teams should do before enforcement begins.

Understanding the Change in Simple Terms

Let’s break the basics.

What is EKU?

Every SSL/TLS certificate includes a field called Extended Key Usage (EKU). This field defines what the certificate is allowed to do.

Historically, some public TLS certificates included two permissions:

• Server Authentication (serverAuth) — used to secure HTTPS websites
• Client Authentication (clientAuth) — used to verify a user, device, or service identity

This allowed a single certificate to serve dual roles.

What is Changing?

The industry is now removing clientAuth from public TLS certificates, making them single-purpose – strictly for server authentication.

After enforcement:

• Public TLS certificates → serverAuth only
• Client authentication → must use separate certificates (typically private PKI)

Why Client Authentication is Being Removed?

Think of it like this; If one ID card could act as:

• A building access badge
• A driver’s license
• A bank authentication card

That would increase misuse risk.

Browsers and certificate authorities want clear separation of roles:

• Website certificates → Prove a server is real
• Client certificates → Prove a user/device is real

Separating them improves security and reduces ambiguity.

1. Clear Separation of Identity Roles

   Public TLS certificates were designed primarily to authenticate servers. Using the same certificate for both server and client identity blurred trust boundaries. Separating roles improves clarity and reduces misuse.

2. Reduced Security Risk

   Dual-purpose certificates increase exposure through:

   • Key reuse across different authentication roles
   • Misconfiguration risk
   • Expanded attack surface

   Single-purpose certificates enforce tighter control.

3. Alignment with Browser Root Policies

   Modern browser root programs increasingly require TLS certificates to contain only serverAuth. Removing clientAuth ensures compliance with these policies and improves ecosystem consistency.

4. PKI Best Practice Evolution

   Modern PKI design promotes:

   • Role separation
   • Clear issuance profiles
   • Distinct trust chains
   • Principle of least privilege

   This aligns public TLS with zero-trust design philosophy.

Timeline of Enforcement

While exact dates vary slightly by certificate authority, the broader industry direction is consistent:

• 2025 – ClientAuth gradually removed from new public TLS issuance profiles
• Early 2026 – Public TLS certificates no longer issued with clientAuth
• Mid-2026 – Browsers stop accepting dual-purpose TLS certificates

Existing certificates will continue functioning until they expire naturally.

Who Is Affected – and Who Is Not

Not Affected

Most organizations will not experience any disruption, including those who:

• Use SSL/TLS only for website HTTPS
• Operate standard eCommerce or business websites
• Use public SSL certificates for normal server encryption

For these environments, TLS behavior remains unchanged.

Affected Environments

Organizations using certificates for identity authentication must prepare, including:

• Mutual TLS (mTLS) deployments
• API-to-API authentication
• Device or machine identity
• Service-to-service communication
• Certain VPN and enterprise network authentication models

These use cases require separate client authentication certificates, typically issued from a private CA.

What Should Affected Teams Do

1. Separate Server and Client Authentication

   Public TLS certificates should be used strictly for server identity. Client authentication must move to a dedicated certificate profile.

2. Use Private PKI for Client Certificates

   Private or internal certificate authorities allow full control over:

   • Client identity issuance
   • Trust anchors
   • Revocation and lifecycle
   • Device and service authentication

   This approach aligns with modern Zero Trust architectures.

3. Review mTLS Implementations

   Ensure your mutual TLS setup uses:

   • Public certificate → serverAuth only
   • Private certificate → clientAuth only

   Update validation logic where dual-purpose certificates were previously used.

What This Change Does Not Affect

• Website HTTPS encryption
• Standard SSL certificate buyers
• Email TLS encryption
• General hosting or CDN usage
• Public-facing website trust

This is strictly an identity separation change, not a TLS security downgrade.

Strategic Perspective: Where the Industry is Heading

The removal of clientAuth from public TLS certificates is part of a broader evolution in digital trust:

• Clearer separation between encryption and identity
• Stronger certificate governance
• Reduced multi-purpose credential risk
• Alignment with Zero Trust principles
• Increasing reliance on private PKI for identity authentication

Public TLS is becoming narrowly focused on server trust, while identity authentication moves toward controlled enterprise PKI environments.

Final Thoughts

The shift away from client authentication in public TLS certificates is no longer a future change; it is now part of the active certificate landscape in 2026. Public SSL/TLS certificates are being firmly scoped to server authentication, while identity-based authentication is moving toward private PKI and controlled certificate environments.

As the industry continues tightening certificate governance, organizations that proactively modernize their PKI, review mTLS deployments, and adopt structured certificate lifecycle practices will remain ahead – both in security posture and operational stability.

Frequently Asked Questions (FAQ)

Related Articles:

• Client Certificates vs Server Certificates – What are differences?
• What is Certificate Lifecycle Management & Why Do Enterprises Need It?