SSL Certificates With Client Authentication EKU Available Through Trustico® Until October 2026

Client Authentication is being removed from the Extended Key Usage (EKU) extension of publicly trusted SSL Certificates. This affects any organization that relies on a Server SSL Certificate to authenticate users, devices, or systems rather than only to secure a website.

Trustico® previously secured an arrangement with Sectigo® to keep providing SSL Certificates that include Client Authentication after most of the industry had already removed it. That availability has now been extended again, to 31 October 2026.

The further extension was negotiated for a specific reason. A number of organizations still depend on Client Authentication and did not act on the original regulatory requirements with the urgency those requirements called for. Rather than leave those organizations stranded, Trustico® worked with Sectigo® to obtain additional time for migration.

This extension does not remove the deadline. It moves it. The wider industry regulations set a firm cutoff in February 2027, after which Client Authentication cannot be included in publicly trusted SSL Certificates by any Certificate Authority (CA). Reaching that point in an orderly way requires preparation now from both customers and the Certificate Authorities (CAs) that issue SSL Certificates. The 31 October 2026 date is the negotiated cutoff that Trustico® is contractually bound by, and a third extension is unlikely.

Understanding what is changing, why two separate dates apply, and how to migrate helps organizations plan a transition that protects operational security rather than reacting after access has already broken. The remainder of this guide covers the deprecation itself, the systems most affected, and the steps to take before the cutoff.

Understanding the Client Authentication Deprecation

The CA/Browser Forum baseline requirements mandate the removal of Client Authentication from the Extended Key Usage (EKU) extension in publicly trusted SSL Certificates. This change separates server authentication from client authentication so that each SSL Certificate type is validated and issued for a single, well defined purpose. Most Certificate Authorities (CAs) have already implemented the restriction.

Client Authentication in a Server SSL Certificate historically allowed a single SSL Certificate to authenticate both servers and clients. That convenience led many organizations to build authentication systems around Server SSL Certificates used for client identification. Current security practice instead recommends dedicated Client SSL Certificates, validated specifically for authentication.

The deprecation hits hardest where SSL Certificates are used for mutual Transport Layer Security (mTLS) authentication, in which both client and server verify each other. A system that checks for Client Authentication in the Extended Key Usage (EKU) extension will reject an SSL Certificate that lacks it, which breaks the authentication flow. Learn About Mutual Certificate Authentication 🔗

Impact on Current Authentication Systems

The change reaches several distinct systems, and the disruption is not theoretical. Where Client Authentication is removed and a replacement has not been put in place, the affected connection simply stops being accepted.

Organizations using SSL Certificates with Client Authentication for Virtual Private Network (VPN) access face an immediate problem, because an SSL Certificate without that Extended Key Usage (EKU) value will not authenticate a user to the VPN gateway. Many enterprise VPN solutions check for Client Authentication capability before allowing a connection. Without a compatible SSL Certificate, remote workers lose access to corporate resources.

Secure e-mail systems that derive signing and encryption SSL Certificates from Server SSL Certificates also face compatibility problems. Dedicated e-mail SSL Certificates using Secure/Multipurpose Internet Mail Extensions (S/MIME) are not affected, but organizations that repurposed Server SSL Certificates for e-mail must move to proper e-mail SSL Certificates, which means updating e-mail clients, redistributing SSL Certificates to users, and updating directory services. Learn About S/MIME E-Mail Certificates 🔗

Application-to-application authentication using mutual Transport Layer Security (mTLS) is another critical area. Many Application Programming Interface (API) integrations, microservice architectures, and service-to-service connections rely on Client Authentication in a Server SSL Certificate. These systems need reconfiguration to use dedicated Client SSL Certificates or an alternative authentication method, which can require meaningful development effort. Learn About Securing API Endpoints 🔗

October 2026 and the February 2027 Regulatory Cutoff

Two dates now apply, and the difference between them matters for planning. The first is the date Trustico® can continue providing SSL Certificates with Client Authentication. The second is the date the wider industry stops permitting it entirely.

The February 2027 cutoff is set by industry regulation. After that point, no Certificate Authority (CA) may include Client Authentication in the Extended Key Usage (EKU) extension of a publicly trusted SSL Certificate. There is no negotiated path around it, because it is the rule the entire public trust system operates under.

The 31 October 2026 cutoff is the date Trustico® has been able to negotiate with Sectigo® for continued availability. It sits earlier than the February 2027 regulatory wall for a practical reason. A Certificate Authority (CA) cannot keep issuing SSL Certificates with a feature right up to the moment the rule changes, because every SSL Certificate it issues continues to exist and be relied upon for its full validity period afterward. The Certificate Authorities (CAs) need their own lead time to wind issuance down cleanly before February 2027, and the 31 October 2026 date reflects that.

The earlier extension to mid-2026 has already passed once. This renewed arrangement was possible only because a population of customers still genuinely depended on the feature. It should not be read as a pattern that will keep repeating. The realistic planning assumption is that 31 October 2026 is the last opportunity to obtain Client Authentication, and that no further extension will be available.

For that reason, the months before the cutoff should be used for migration rather than for postponing it. The sections below set out how.

The Trustico® Extended Availability Arrangement

All Sectigo® branded SSL Certificates issued through Trustico® automatically include Client Authentication in the Extended Key Usage (EKU) extension until 31 October 2026. The capability is included by default, with no special request, additional configuration, or separate ordering path required.

This means an organization can continue obtaining SSL Certificates that are compatible with its existing authentication infrastructure while it works on a permanent replacement. The automatic inclusion also removes any ambiguity about which SSL Certificates carry the capability, because every eligible Sectigo® branded SSL Certificate from Trustico® carries it until the cutoff. Learn About Sectigo® as a Certificate Authority 🔗

The value of the extension is the time it provides. Organizations can test a migration properly, update applications, and prepare staff without the immediate pressure of SSL Certificates becoming unavailable. A planned transition carries far less risk of authentication failures and service interruptions than one carried out under deadline pressure after access has already started to break.

Migration Strategies for the Extension Period

The extension is most useful when it is spent building dedicated Client SSL Certificate infrastructure rather than delaying the work. A sensible migration starts with an audit of every system that currently relies on a Server SSL Certificate with Client Authentication. The audit identifies critical dependencies and lets an organization prioritize by business impact and technical complexity.

Moving to dedicated Client SSL Certificates also means establishing proper SSL Certificate lifecycle management. Server SSL Certificates are usually managed by a technical team, but Client SSL Certificates often need distributing to individual users or devices. That distribution challenge points toward automated enrolment, a management platform, and clear procedures for reissue and revocation.

Testing in a non-production environment is what makes the eventual production change safe. New Client SSL Certificates should be confirmed to work with existing authentication systems before any Server SSL Certificate with Client Authentication is decommissioned. Running both in parallel during the transition keeps the risk of disruption low.

Technical Considerations for Client Authentication

The Extended Key Usage (EKU) extension in an X.509 SSL Certificate specifies the purposes the SSL Certificate may be used for. Client Authentication is identified by the Object Identifier (OID) 1.3.6.1.5.5.7.3.2, and a system that requires client authentication checks for exactly that value. When the value is absent, the SSL Certificate is rejected for that purpose. Learn About Certificate Extensions 🔗

Application configuration often needs adjusting either to accept SSL Certificates without Client Authentication in the Extended Key Usage (EKU) extension or to use a separate Client SSL Certificate. Some applications allow the administrator to configure which Extended Key Usage (EKU) values are required, which provides useful flexibility during a phased migration.

Custom applications can require code changes where SSL Certificate validation logic depends on the presence of Client Authentication. A review of authentication code by the development team identifies those dependencies, surfaces the changes needed, and gives a realistic estimate of the work involved before the cutoff.

Best Practices for Affected Organizations

Migration planning should begin now rather than as the cutoff approaches. Early planning leaves room to handle the complications that always appear in real environments, and it keeps the transition off the critical path of other work. The extension provides breathing room, but only an organization that uses that room productively will benefit from it.

Dedicated Client SSL Certificate infrastructure is a security improvement rather than a compromise. A Client SSL Certificate issued for authentication can carry appropriate validation, key usage restrictions, and validity periods for that role. Separating the server and client roles cleanly tends to simplify management as well as strengthen it.

Documenting current authentication flows and SSL Certificate dependencies is worth the effort on its own. A clear record of how each system uses its SSL Certificates makes the right replacement obvious, speeds up troubleshooting during the migration, and serves as knowledge transfer for the people who maintain the systems afterward.

Alternative Authentication Approaches

Moving to dedicated Client SSL Certificates is the most direct path, but it is not the only option, and some use cases suit a different approach. Token-based systems such as OAuth 2.0 and Security Assertion Markup Language (SAML) provide authentication without relying on a Client SSL Certificate, and they bring their own flexibility and scaling advantages.

For Application Programming Interface (API) authentication, an API key, a JSON Web Token (JWT), or an OAuth 2.0 flow can be simpler than mutual Transport Layer Security (mTLS). These methods remove SSL Certificate management overhead, though they require application changes and may not provide the same transport-layer assurance that SSL Certificate-based authentication does.

A hybrid model is also viable, in which SSL Certificates secure the transport while authentication happens through separate credentials or tokens. Transport Layer Security (TLS) provides the encryption, and a separate mechanism establishes identity. The separation simplifies SSL Certificate management, but it has to be implemented carefully to preserve the security guarantees the original design relied on.

Preparing for the Final Deprecation

The migration is easier to manage against a small number of clear checkpoints than as a single deadline. Useful checkpoints include completing the system audit, standing up Client SSL Certificate infrastructure, migrating a pilot group of systems, and completing the production migration, each scheduled with margin ahead of 31 October 2026.

Some systems will be harder to move than others. Legacy applications may need significant rework, or replacement, before they can support a new authentication method. Identifying those systems early is what creates enough time to build a workaround or plan a replacement, rather than discovering the problem when the SSL Certificate can no longer be obtained.

The reduction of Client Authentication availability is part of a broader tightening of the rules that govern publicly trusted SSL Certificates, alongside the ongoing reductions in maximum validity periods. Organizations that build automated SSL Certificate management while addressing this change will be better positioned for the wider direction the industry is moving in. Learn About Changing Validity Periods 🔗

Trustico® Support During the Transition Period

The extended availability is the practical part of the support, but it is not the whole of it. The renewed arrangement with Sectigo® gives organizations a defined window in which compatible SSL Certificates remain available, which is what makes a planned migration possible at all.

Organizations that still depend on Client Authentication should use the window deliberately. Obtain the SSL Certificates needed to keep current systems running, and in parallel implement the dedicated Client SSL Certificate infrastructure or alternative authentication that will carry the systems past the February 2027 regulatory cutoff. Learn About the Extended Key Usage (EKU) Deprecation 🔗