TLS Certificates Are Shrinking to 47 Days: The Timeline and What to Automate Now

On 15 March 2026 the maximum lifetime of a publicly trusted TLS certificate dropped from 398 days to 200 days. It was the first of three steps set by CA/Browser Forum ballot SC-081, which passed in April 2025 with no votes against. The Forum is the body of certificate authorities and browser makers that writes the rules every public CA must follow, so the change applies to every certificate your browser trusts.

Two details matter:

• The limits apply at issuance. A one-year certificate bought on 14 March 2026 stays valid for its full term. Nothing already issued is shortened.
• Domain validation shrinks too. Today a CA can reuse proof that you control a domain for months. By 2029 that proof is only good for 10 days, so almost every renewal will need a fresh validation — a DNS record or HTTP challenge answered automatically.

The rules cover publicly trusted certificates only. An internal CA issuing certificates for your own devices can set any lifetime it likes.

Revocation doesn't work well. When a certificate's private key leaks, the CA can revoke it — but browsers have never reliably checked revocation. OCSP checks were slow, leaked browsing history to the CA, and were usually "soft-fail" (if the check didn't answer, the browser carried on). Let's Encrypt removed OCSP URLs from its certificates in May 2025 in favour of CRLs. A short lifetime is a guaranteed backstop: a compromised certificate simply stops working within weeks.

Stale information. A certificate asserts that a domain belonged to someone when it was issued. Domains change hands; a 398-day certificate could stay valid for over a year after its holder lost the domain.

Crypto agility. If an algorithm needs replacing — as is starting to happen with post-quantum cryptography — short lifetimes mean the whole web rotates to new certificates within weeks instead of years. See post-quantum TLS in 2026.

Forcing automation. This is the unstated goal. Expired certificates are one of the most common causes of outages at large companies, and they almost always trace back to a manual renewal someone forgot. At 47 days, manual renewal is impractical, so organisations have to automate.

Let's Encrypt already issues 90-day certificates, well inside the current 200-day limit, but it has published its own schedule to keep ahead of the Forum:

• 10 February 2027: default certificates drop to 64 days.
• 16 February 2028: default certificates drop to 45 days.
• Authorization reuse will drop to 10 days and later to 7 hours.

Related changes already in place:

• 4 June 2025: expiry reminder emails stopped. If you relied on Let's Encrypt to warn you, nobody is warning you now.
• 11 February 2026: the TLS Client Authentication usage was removed from default certificates, completed on 8 July 2026. Certificates can no longer be used as client certificates for mutual TLS.
• Short-lived certificates lasting under a week, and certificates for IP addresses, are available as opt-in profiles.

With 64-day certificates, a renewal job that runs once a month at a fixed "30 days left" threshold is cutting it close. Clients should renew at roughly one-third of the remaining lifetime, or better, ask the CA when to renew.

1. Use ACME everywhere. ACME is the protocol Let's Encrypt created and most CAs now support, including commercial ones like DigiCert and Sectigo. Certbot, acme.sh, Caddy, Traefik, cert-manager on Kubernetes, and the built-in certificate management on most hosting platforms all speak it. If a certificate is still installed by hand from a file someone emailed, that's the one that will expire.

2. Turn on ACME Renewal Information (ARI). ARI lets the CA tell your client when to renew — earlier than planned if the CA needs to revoke certificates in bulk after an incident. Let's Encrypt has supported it since 2023, and clients including Certbot, Caddy and lego support it.

3. Prefer DNS-01 for anything not on a public web server. The DNS challenge proves control by publishing a TXT record, so it works for wildcards, internal hosts and load balancers that can't answer HTTP challenges. Use a DNS provider with an API and a token scoped to the _acme-challenge records only.

4. Reload what uses the certificate. A renewed certificate on disk doesn't help if nginx, a Java keystore or a load balancer keeps serving the old one from memory. Every renewal hook should reload the service.

5. Find the certificates you've forgotten. Mail servers (SMTP, IMAP), VPN gateways, admin panels, IoT devices and appliances with a web UI are the usual stragglers. Certificate Transparency logs list every public certificate issued for your domains — search crt.sh for %.example.com to build an inventory. See how Certificate Transparency works.

6. Monitor from outside. Don't rely on the renewal job reporting its own failure. An external check that alerts when any certificate has fewer than 14 days left catches renewal that silently stopped. The SSL Certificate Checker shows the expiry date and chain for any host on demand.

Multi-year "certificate subscriptions" still exist, but under SC-081 they're delivered as a series of shorter certificates over the subscription term. In practice:

• A "one-year" certificate purchased today is delivered as at least two certificates, because no single certificate can last longer than 200 days.
• From March 2027 a year needs at least four certificates; from March 2029, at least eight.
• Most commercial CAs now offer ACME endpoints for paid certificates, including OV and EV. Use them, so reissuing becomes your client's job rather than a calendar reminder.

Organisation-validated (OV) and extended-validation (EV) details — the company name and address checks — can still be reused for longer than domain validation, so the paperwork side doesn't repeat every 47 days. The domain control check does.