Authenticating with public certificates? Stop. What you must change by 2026
By May 2026, public certificate authorities (CAs) will stop supporting TLS client authentication due to Chrome’s new root program rules. Organizations relying on public SSL/TLS certificates for user, device, or application authentication will need to switch to private CAs. This shift impacts VPNs, mTLS, Wi-Fi onboarding, and more. Modern private CA solutions, combined with Certificate Lifecycle Management (CLM), offer a secure, scalable path forward.
In May 2026, a foundational shift will take place in public key infrastructure (PKI), one that most organizations aren’t tracking, but many will feel. Due to updated Chrome Root Program requirements and recent announcements from certificate authorities (CAs), public CAs will no longer issue certificates that support TLS client authentication.
For organizations relying on these certificates to authenticate users, devices, or applications, this change introduces a hard deadline. Existing authentication workflows, especially those quietly relying on free or automated public CAs, will begin to fail unless organizations migrate to private CAs.
This shift isn’t a corner-case policy update. It’s a structural realignment that redefines how authentication must be handled across corporate infrastructure. And it arrives far sooner than most realize.
The policy change behind it all
The origin of this change lies in Chrome Root Program Policy 1.6, which mandates that certificate hierarchies included in Chrome’s trust store must be dedicated solely to TLS server authentication by June 2026. In short, public CAs will no longer be permitted to issue certificates that contain both the id-kp-serverAuth and id-kp-clientAuth Extended Key Usages (EKUs). These EKUs define what a certificate is allowed to be used for, and in this case, either server or client authentication.
The enforcement is already underway.
Sectigo announced that starting September 15, 2025, they will no longer include the Client Authentication EKU by default in newly issued SSL/TLS certificates. And by May 15, 2026, Sectigo will permanently remove the Client Authentication EKU from all newly issued SSL/TLS certificates. After this date, no exceptions will be granted.
This policy shift follows a broader trend of browsers having zero tolerance for delayed revocation. Rather than continuing to tolerate mixed-use public certificates, Chrome has opted for clarity: public PKI is for server authentication only. If you need client auth, use a private CA.
What is TLS client authentication and why you might be using it
TLS client authentication enables systems to verify the identity of clients, users, devices, or applications, when they attempt to connect to a server. It’s distinct from the more familiar TLS server authentication (used in HTTPS), which verifies websites.
Some common use cases include:
- VPN access for issuing certificates to employee laptops to verify their identity when connecting remotely.
- Wi-Fi onboarding to authenticate employee devices and secure networks without sharing static passwords.
- Salesforce login or other SSO workflows that rely on client certificates embedded in endpoint devices.
- Mutual TLS (mTLS) for APIs, especially in CICD pipelines or between microservices in zero-trust architectures.
- Device or workload identity in DevOps environments, including container-based services.
The key issue is this: many organizations are unknowingly using public CAs for client authentication in these workflows, often because it is easy, cheap, or bundled with automation tools like ACME.
Google Chrome has made removal of client authentication a pre‑condition for roots to remain in the Chrome Root Store. Because most other browsers follow the same root programs, truly globally trusted client‑auth certs will dry up.
Once the major publicly‑trusted CAs finish removing the Client Authentication EKUs from their TLS lines in 2025/2026, organizations that still rely on a TLS Client Authentication certificate to identify clients will find it hard (and soon impossible) to find replacements. Every large public CA has now published a sunset schedule.
Modern private CA: Not the heavy lift it once was
Client authentication is fundamentally an internal security function. It requires flexibility, fine-grained control, and assurance that certificates won’t be revoked by external policy changes. Public CAs were never designed for this purpose.
Until recently, many organizations used them anyway, often without realizing the implications. Public certificates were easy to obtain, automation-friendly, and didn’t require running internal PKI infrastructure. But they came with limitations:
- Fixed certificate profiles that can’t be modified to suit internal use cases.
- Public audits and compliance mandates from the CA/Browser Forum.
- No control over issuance windows, revocation criteria, or lifecycle policy.
- Exposure to browser and platform policy changes, like the one happening now.
By contrast, private certificate authorities give organizations full control over issuance, profile design, revocation, renewal, and automation. More importantly, they aren’t subject to external root program constraints. And today, modern private CA solutions are far easier to deploy than they were in the past.
Historically, private CAs had a reputation for being expensive, hard to manage, and slow to deploy. Organizations had to build PKI infrastructure from scratch, often relying on outdated tooling and manual processes.
That’s no longer true.
Modern private CAs, especially cloud-native ones like Sectigo, can be provisioned in minutes, scale automatically, and support protocols like ACME, EST, and SCEP for seamless certificate enrollment. They offer:
- Customizable certificate profiles for a range of internal use cases.
- Per-use-case private CAs, if separation of concerns is desired.
- Full API support for integration into DevOps, MDM, and security platforms.
- Lifecycle automation and policy enforcement through Certificate Lifecycle Management (CLM) platforms.
This evolution is so significant that it helped trigger the Chrome policy shift itself. As Jason Soroko, Senior Fellow at Sectigo, noted:
“Google feels empowered to do this because they know we finally have lightweight, turnkey private CA options. If this were 15 years ago, they couldn’t have pulled the trigger.”
In other words, private CA infrastructure has finally caught up with the problem it was always meant to solve.
How CLM completes the picture
Switching to a private CA isn’t just about replacing certificates, it’s about taking control of how those certificates are managed.
With 47-day SSL/TLS certificate lifespans now a reality, it’s no longer viable to track certificates with spreadsheets or hope that renewal scripts keep running. Visibility, automation, and policy enforcement must be built in from the start.
That’s where Certificate Lifecycle Management (CLM) comes in. A robust CLM platform helps you:
- Discover every certificate across your environment, public and private.
- Classify and tag certs by use case, system, and expiration.
- Automate issuance, renewal, and revocation at scale.
- Enforce policies on key length, EKU, profile templates, and more.
- Avoid outages due to expired or misconfigured certificates.
- View all of your certificates from one single-pane-of-glass, unified view, whether private or public.
No matter how good your CA is, without CLM, you’ll struggle to maintain agile as the digital landscape continues to rapidly evolve.
“All roads lead to CLM,” as Jason put it. “Every certificate should’ve been managed from the beginning.”
What you should do next
1. Map your internal PKI
Start by identifying where TLS client authentication is used across your organization:
- Which devices, applications, or services are authenticating with certificates?
- Which certificate authorities issued them?
- Are any of these certificates being issued via public ACME workflows (e.g., Let’s Encrypt)?
If you're unsure, Sectigo Certificate Manager can help discover and inventory internal certificates across cloud, on-prem, and hybrid environments.
2. Assess risk and timeline
As mentioned, all public CAs will be required to fully phase out support for TLS Client Authentication by May 2026. Any certificates supporting client auth issued from these sources will need to be replaced with certificates issued from a private CA.
3. Deploy a modern private CA
Sectigo’s cloud-based private CA solution allows you to issue and manage certificates for:
- VPN and Wi-Fi authentication
- Device and workload identity
- mTLS and API authentication
- Developer environments and CI/CD pipelines
It’s built for fast deployment and scales across environments. With support for ACME, EST, and SCEP, and out-of-the-box integrations into Microsoft ADCS and cloud identity platforms, you can bring private PKI online without infrastructure friction.
4. Automate with Certificate Lifecycle Management
Once your private CA is operational, the next step is to ensure complete visibility and automation. Sectigo Certificate Manager gives you:
- Full inventory of all certificates (public and private)
- Role-based issuance policies
- Auto-renewal and rotation
- Expiration alerting and audit logging
Private PKI is no longer optional
The phase-out of TLS Client Authentication from public CAs isn’t just a policy update, it’s a structural change in how authentication should be handled. It removes a crutch that many organizations have unknowingly leaned on for years.
The good news is: private CA is no longer the barrier it used to be. And with certificate management tooling catching up, there’s never been a better time to reclaim control.
If you're still passing around Wi-Fi passwords or using client certs from public CAs to authenticate laptops, it’s time to act. The infrastructure you need is available and the deadline is set.
Sectigo offers the solution your organization needs to remain compliant and agile. With a turnkey, best-in-class private CA that is CA-agnostic and a secure, simple, and scalable platform, you can merge your public and private certificates into one.
