After a unanimous CA/Browser Forum vote, the maximum lifespan for publicly trusted SSL/TLS certificates will shrink from today’s 398-day limit to 200 days on March 15, 2026. From there, the industry will keep tightening the window until certificates last just 47 days by 2029.

If your organization manages SSL certificates for websites, APIs, or any public-facing services, this is not a suggestion. It is a binding industry standard that will affect the entire Web PKI ecosystem. The change comes from Ballot SC-081v3, approved on April 11, 2025, with 29 votes in favor.

“The industry’s unified support for reducing certificate lifespans to 47 days reflects a shared commitment to enhancing digital security and trust for all.”
Tim Callan, Chief Compliance Officer, Sectigo and Vice-Chair, CA/Browser Forum

The Reduction Timeline

The transition is happening in stages. This gives organizations time to adapt their certificate management processes before the final 47-day limit arrives.

Each phase reduces both the maximum certificate lifespan and the domain control validation (DCV) reuse window.

A detail many teams overlook is the DCV reuse window in 2029. By that point, domain validation can only be reused for 10 days. That is significantly shorter than the certificate lifespan itself.

In practice, this means automated domain validation will become a requirement. Manual validation processes simply will not scale.

Why the Entire Industry Agreed

Browser vendors including Apple, Google, Mozilla, and Microsoft all voted in favor. Among certificate authorities, 25 voted yes and five abstained. None opposed.

Several factors drove this unanimous support.

1. Reducing the Damage Window

If a private key is stolen or a certificate is issued incorrectly, a long validity period gives attackers more time to exploit it.

With a 398-day certificate, that window can stretch well past a year. Meanwhile, a 47-day certificate cuts that exposure down to weeks.

Revocation systems such as CRL and OCSP exist, but they are not consistently reliable in real-world browser behavior. Many browsers skip checks for performance reasons, and OCSP responders do not always maintain perfect availability.

Shorter certificate lifetimes provide a simpler and more dependable safety net.

2. Preparing for Post-Quantum Cryptography

The internet will eventually transition to post-quantum cryptography (PQC). When that happens, certificates across the web must be rotated quickly.

Long certificate lifespans slow that transition. With a 398-day limit, rotating the entire ecosystem could take well over a year. At 47 days, that same transition could happen in under two months.

As NIST finalizes its post-quantum standards, this type of agility is increasingly viewed as a security priority rather than a convenience.

3. Keeping Identity Information Accurate

Certificates contain ownership information for domains and organizations. Over time, those details can become outdated.

Shorter lifespans force more frequent validation. That reduces the risk of a certificate continuing to assert ownership of a domain or organization that has changed hands.

What Ballot SC-081v3 Covers

Ballot SC-081v3 applies only to publicly trusted TLS certificates. These are the certificates used for websites and other internet-facing services.

Several other certificate types are not affected by this rule, including:

• Private PKI certificates used inside corporate networks
• S/MIME email certificates
• Code signing certificates
• IoT device certificates

Those categories follow different baseline requirements.

What This Means for Operations

Managing a certificate manually typically takes around four hours when you include validation, installation, testing, and documentation. An organization managing 1,000 certificates today spends roughly 4,000 hours per year on renewals under the 398-day model.

With 47-day certificates, the same environment would generate about 48,000 hours of annual renewal work. That is a twelvefold increase without adding a single new certificate. There is also the risk of outages.

Research cited by CyberArk found that 72% of organizations experienced at least one certificate-related outage in the past year. The average cost of downtime was estimated at $9,000 per minute. As renewal frequency increases, so does the potential for missed expirations.

At eight renewals a year, a missed expiration gets a lot easier to explain and a lot harder to excuse. KnownHost’s AutoSSL, included with every cPanel and Plesk plan, takes care of it automatically. Managed VPS and Dedicated Server customers can also work directly with KnownHost’s 24/7 support team to verify their automation is properly configured before the March 15 deadline.

What You Should Do Now

Below is a brief summary of what you should do now, but you can find a more detailed guide here.

1. Audit Your Certificate Inventory

Start by identifying every publicly trusted certificate your organization uses.

That includes:

• Websites
• APIs
• Load balancers
• Reverse proxies
• Internet-facing applications

Certificates issued before March 15, 2026 will remain valid until their original expiration date. There is no requirement to replace them early. The key is understanding what will come up for renewal after the deadline.

2. Understand How Multi-Year Plans Work Now

Many organizations purchase two- or three-year certificate plans. Those plans are still valid from a billing standpoint. However, the certificate itself must be reissued and reinstalled every 200 days starting in 2026.

In other words, multi-year certificates are no longer a single installation that lasts for years. They now function more like a prepaid renewal subscription.

3. Implement Automation Before 2027

The 2027 transition to 100-day certificates will make manual renewal processes extremely difficult for most organizations. The industry standard for automation is the ACME protocol (RFC 8555).

Many certificate authorities already support it, including free providers such as:

• Let’s Encrypt
• ZeroSSL

Enterprise environments often rely on certificate lifecycle management platforms such as:

• DigiCert
• Sectigo
• Venafi

These tools add policy controls, monitoring, and support for OV and EV certificates.

4. Verify Your Server Automation Tools

ACME clients exist for nearly every server platform.

Common options include:

• Certbot for Apache and Nginx
• win-acme for IIS on Windows Server
• acme.sh, a lightweight shell-based client with broad compatibility
• Caddy, which includes built-in automatic ACME support

For Kubernetes environments, cert-manager handles certificate issuance and renewal directly within the cluster.

A Second Deadline: Chrome’s Server-Auth-Only Policy

Under Chrome Root Program Policy v1.6, Google will stop trusting public certificates that include the Client Authentication Extended Key Usage (EKU) starting June 15, 2026. Any new public certificate issued on or after that date must be dedicated solely to server authentication. 

Certificates issued before the deadline remain valid until expiry. If your organization uses public certificates for VPN client authentication or mutual TLS, those deployments need to move to a private CA before enforcement begins.

The same applies to application-to-application environments that rely on public certificates for mutual TLS.

Internal certificates remain unaffected because they operate outside the public trust ecosystem.

Where this Leaves You

Certificate management used to be a once-a-year task. By 2029, it will happen every 47 days. 

The difference now is that the renewal pace is about to outrun any manual process designed to keep up with it.

The shorter lifespan itself is not necessarily a bad thing. It means fewer compromised certificates floating around on the internet for months at a time. The industry is genuinely more secure for it.

For customers hosted with KnownHost, AutoSSL has been doing this work quietly in the background already. If you’re not sure it’s active on your account, it takes about two minutes to check in cPanel, and it’s worth doing before March 15 arrives.