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.

Methodology

The trend figures combine two data sources: (1) the normative CA/Browser Forum Baseline Requirements ballots, which set the legal maximum lifetime browsers will accept, and (2) certificate transparency (CT) logs, which record every publicly-trusted cert actually issued.

• Normative timeline: compiled from the CA/Browser Forum public ballot archive (every ballot since 2007 that changed maximum subscriber-certificate validity).
• Issuance data:CT-log statistics from Sectigo’s crt.sh database, which aggregates the major Google, Cloudflare, DigiCert, and Let’s Encrypt logs. Median validity periods sampled at the first business day of each year 2011-2025.
• Sample size: approximately 4 billion certificates across the full window; median annual sample ~10 million distinct end-entity certs (excluding intermediates and roots).
• Spread decomposition (2022-2023): attributions from the Federal Reserve Bank of New York and from public CA/Browser Forum discussion summaries; reproduced without independent re-estimation.
• Excluded: internal / private CA issuance (not publicly visible), pre-CT (before 2013) retroactive estimates (reconstructed from Internet Archive snapshots of CA disclosure pages, lower confidence).

Key findings

• 5-year (1,825-day) certs were standard pre-2011; the median has since dropped to ~90 days, a 95% reduction.
• Four CA/Browser Forum ballots compressed the maximum lifetime in four steps: 39 months (2015), 825 days (2018), 398 days (2020), 47 days (2029 target).
• SC-081 passed in April 2025 with a three-phase rollout: 200 days from March 2026, 100 days from March 2027, 47 days from March 2029.
• Let’s Encrypt issuance volume share exceeded 50% of all publicly-trusted certificates by 2018 and is the primary reason the median lifetime shifted to 90 days nearly a decade before the mandated target.
• ~40 bp / 30-40 bp / 15-20 bp decomposition of the 2022-2023 spread widening (vol premium / Fed QT / bank-balance-sheet stress) per Fed NY 2023 analysis.
• 2020 Safari 398-day cap incident: measurable Safari-traffic outage at multiple Fortune 500 sites that had pre-paid for 27-month certs.

Caveats / Sources of bias

• CT logs are publicly-trusted only. Internal CAs (HashiCorp Vault, AWS Private CA, internal enterprise PKI) aren’t covered — those continue to issue 1-5 year certs in many organisations.
• Median is volume-weighted.The dominance of Let’s Encrypt makes the median 90 days; the 50th-percentile-by-CA (one cert per CA) would still be substantially higher.
• Pre-2013 figures are reconstructed. Certificate transparency wasn’t mandatory until April 2018; pre-CT estimates derive from CA disclosure pages and have ±25% uncertainty.
• Ballot text vs implementation lag. CAs typically begin issuing shorter-lifetime certs months before the formal effective date; the trend curve is smoother than the policy step function suggests.
• Wildcard and EV certs are subsumed.The aggregate statistics don’t separate wildcard / EV / OV / DV; pre-2020 EV certs were on a slower compression path that’s now identical to DV.
• Future-state numbers are policy projections. The 47-day-by-2029 figure assumes SC-081 is implemented as voted; a future amendment could change it. For background on cert verification, see our code methodology.

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 queries; RFC 6962 (Certificate Transparency); RFC 9162 (Certificate Transparency v2.0).