TLS certificate lifetimes: 5 years → 47 days, 2011-2026

Browser-trusted TLS certificates used to last five years. Today they last 90 days. By 2029 the CA/Browser Forum vote in March 2025 will compress them to 47 days. The 15-year trajectory is the most consequential change in operational security the web has seen — turning certificate management from a once-every-few-years admin task into a fully-automated pipeline. Manual renewal isn’t a viable practice anymore.

The headline numbers

Maximum allowed lifetime for publicly-trusted TLS certificates in the browser root programs:

Note: Let’s Encrypt issued certificates have been at 90 days since launch in 2015 — the public cert ecosystem has been preparing for short-lived certs for a decade.

What the certificate transparency logs actually show

CT logs are public, append-only logs of every certificate issued by participating CAs. Anyone can query them. The crt.sh database (Sectigo) aggregates the major logs and publishes statistics.

Sampling the median validity period of newly-issued publicly-trusted certs from CT logs at the start of each year:

• 2011: ~3 years (1,095 days) median validity.
• 2016: ~24 months (730 days) median.
• 2019: ~13 months (398-825 days, bimodal between Let’s Encrypt at 90 days and DigiCert/Sectigo at 2 years).
• 2022: ~90 days median — Let’s Encrypt’s 90-day issuance has dominated volume since 2018.
• 2025: ~90 days median. The long tail at 398 days persists for commercial CAs.

Why the trajectory is unidirectional

Five reasons the industry kept cutting lifetimes:

1. Compromised-key window. If a private key leaks, the attacker can impersonate the site until the cert expires. Short-lived certs reduce the leak-to-revoke window automatically — no revocation infrastructure needed.
2. Revocation is broken. CRLs are huge. OCSP is privacy-leaking and unreliable. Most browsers soft-fail on revocation check failures. Short-lived certs make revocation almost a non-issue: just wait for expiry.
3. Cryptographic agility. Forced renewals let the industry roll out new algorithms (SHA-256 → post-quantum eventually) without a long tail of legacy certs.
4. Misissuance recovery. When a CA is caught misissuing (Symantec 2017, DarkMatter 2019), the recovery is faster if affected certs expire soon naturally.
5. Compelling cert authorities to automate.Short-lived certs are impossible at scale without ACME-style automation. The industry is using lifetime compression as a forcing function to retire manual issuance.

Operational impact for site operators

At 47-day max validity (2029), here’s what every TLS-serving operation must have:

• ACME-compatible cert provisioning. Let’s Encrypt, ZeroSSL, or a commercial CA with ACME (DigiCert, Sectigo). Renewals must run unattended.
• Automated reload of TLS-terminating services. nginx, Apache, HAProxy, AWS ELB, all need scripted cert rotation. Manual SSH-in-and-cp workflows will not keep up at 47-day cycles.
• Monitoring on cert expiry. Alert at 15 days and 5 days. With 47-day certs, a single renewal failure cascades fast.
• Out-of-band CDN cert management. Cloudflare, Fastly, Akamai handle this for you if you terminate TLS there. For self-hosted edge TLS, ACME + systemd-timers is the standard pattern.

What about wildcard, EV, and multi-SAN certs?

All in scope. The CAB Forum SC-081 ballot applies to every publicly-trusted server certificate regardless of type. Extended Validation (EV) certs got the visible-green-bar treatment when issued for 27-month lifetimes; modern browsers long since removed the green-bar UI, and EV certs renew on the same accelerated schedule.

Wildcard certs (*.example.com) are unchanged in capability but renew on the same short schedule. There’s no “wildcard certs get longer lifetimes” exception.

Private (non-publicly-trusted) certs are different

Internal CAs serving private infrastructure can issue certs of any lifetime — browser root programs don’t apply. Many enterprises run 2-year or 5-year internal certs because the cost-benefit is different (no misissuance public risk; rotation is harder for sprawling internal infra). Most internal infra is also moving to short-lived (HashiCorp Vault, AWS Private CA defaulting to 90 days), but the deadline doesn’t bind it.

What broke this for some major sites in 2020

When Apple capped lifetimes at 398 days in September 2020, organisations that had paid in advance for 2-3 year certs saw them rejected by Safari starting on validity day 399. Several Fortune 500 sites lost Safari traffic for a few days in late 2020 because their renewal automation expected the old 27-month cadence. Similar mini-events are likely with each future cutoff — particularly the 47-day target in 2029.

Sources

CA/Browser Forum Baseline Requirements (current and historical revisions); CAB Forum ballot SC-081 “Maximum Validity Periods for Subscriber Certificates” (passed April 2025); Apple Safari TLS policy announcement (February 2020); Let’s Encrypt operational statistics 2015-2025; crt.sh certificate-transparency-log query results.