In April 2025, the CA/Browser Forum — the industry body where certificate authorities and browser vendors negotiate the rules of the public TLS ecosystem — passed ballot SC-081, a proposal originally put forward by Apple. It commits the entire public PKI to a phased reduction of maximum certificate lifetimes, ending at 47 days in March 2029. The vote followed years of the same trajectory: every few years, the maximum lifetime gets cut roughly in half, over the objections of enterprises that issue certificates by hand.
To understand why browsers keep pushing this — and why CAs eventually keep agreeing — you need to understand what certificate lifetime actually buys, and what it's compensating for.
From Five Years to 47 Days
The history is a steady ratchet. Each step was contested at the time and looks inevitable in hindsight:
| Effective | Max Lifetime | Driver |
|---|---|---|
| Before 2015 | Up to 60 months | Original Baseline Requirements |
| April 2015 | 39 months | CA/B Forum Baseline Requirements update |
| March 2018 | 825 days (~27 months) | CA/B Forum ballot 193 |
| September 2020 | 398 days | Apple unilaterally enforced it in Safari after a CA/B ballot failed; other browsers followed |
| March 15, 2026 | 200 days | Ballot SC-081 (proposed by Apple, passed April 2025) |
| March 15, 2027 | 100 days | |
| March 15, 2029 | 47 days |
The 2020 step is the most instructive. The CA/Browser Forum had voted against one-year certificates in 2019 — the CA side blocked it. Apple then simply announced that Safari would distrust any certificate issued after September 1, 2020 with a lifetime over 398 days. Since a certificate that doesn't work in Safari is useless, the ballot result became irrelevant. The browsers hold the root stores, and the root stores are the actual power in this system.
The Real Reason: Revocation Is Broken
The standard justification for short lifetimes is "limiting the blast radius of key compromise," and that's true as far as it goes. But the deeper reason is that the PKI's designed-in remedy for compromise — revocation — has never worked reliably.
In theory, when a private key leaks or a certificate is misissued, the CA revokes it and browsers stop trusting it. In practice, CRLs grew too large to download, OCSP checks were slow and leaked browsing activity to CAs, and — critically — browsers treat OCSP failures as soft failures. If the revocation check doesn't complete, the browser proceeds anyway, because the alternative is breaking the web every time an OCSP responder hiccups. An attacker who can intercept your connection can usually also block the revocation check. Heartbleed in 2014 made this concrete: hundreds of thousands of certificates needed revocation at once, and the infrastructure simply couldn't deliver that information to clients reliably.
Short lifetimes replace revocation as the primary containment mechanism. If a certificate only lives 47 days, a stolen key has a hard upper bound on its useful life — no revocation infrastructure required. Expiry is the one PKI mechanism that fails closed.
Lifetime caps also bound a second risk: stale validation. When a CA issues a certificate, it validates that the requester controls the domain. But domains change hands. Under SC-081, the reuse window for domain control validation shrinks on the same schedule as lifetimes — down to roughly 10 days by 2029 — so a certificate can't outlive proof that its holder still controls the name. The validation a certificate rests on stays at most days old, not a year old.
What This Means in Practice
A 47-day maximum means certificates renew roughly monthly, accounting for renewal overlap. No human renews certificates monthly across a real fleet. The practical meaning of SC-081 is therefore simple: manual certificate management is being deprecated.
The intended replacement is automation via the ACME protocol — the machinery behind Let's Encrypt, which has issued 90-day certificates since 2015 and now also offers short-lived certificates valid for about a week. The tooling is mature: certbot, acme.sh, Caddy's built-in issuance, cert-manager on Kubernetes. If your stack already renews automatically, the schedule change is a non-event. You will genuinely not notice.
If your stack involves a spreadsheet of expiry dates and a person with a calendar reminder, the next three years are your forced migration window. The places that hurt are predictable:
- Appliances and middleboxes — load balancers, VPN concentrators, and management interfaces that accept certificates only through a web upload form
- Certificates pinned in clients — mobile apps or IoT firmware that pin a leaf certificate will break monthly; pin keys or CAs, not leaves, or rethink the pinning entirely
- Internal change-control processes — organizations that require a ticket and an approval to touch production can't put a human approval in a monthly renewal path
- Anything air-gapped — hosts that can't reach a CA need an internal ACME service or a private PKI, which is exempt from these rules entirely
The Honest Criticisms
It's worth stating the counterarguments plainly, because they're not stupid. Forced automation concentrates dependency: most of the world's automated issuance flows through a handful of CAs, with Let's Encrypt carrying an enormous share. Renewal becomes a continuous availability dependency — if your CA has a multi-day outage in a 47-day world, that's a real fraction of your certificate's life. And the change transfers work from browser vendors (who would otherwise have to fix revocation) onto every server operator on the internet. Apple's proposal costs Apple approximately nothing.
The ratchet works because each side is right about something: browsers are right that revocation can't be fixed without breaking the web, and operators are right that the cost lands on them. The browsers hold the root stores, so the browsers win.
There's also a transparency upside that gets less attention: every renewal lands in Certificate Transparency logs, so shorter lifetimes mean the public record of who controls which name is refreshed monthly rather than annually. Stale CT data becomes much less stale.
What You Should Do
The checklist is short. Inventory every TLS certificate you operate — including the ones on the printer admin page nobody remembers. For each one, answer a single question: does it renew without a human? Everything where the answer is no needs either ACME automation, an internal PKI (not subject to public rules), or a plan to be decommissioned before March 2027, when the 100-day limit makes quarterly manual renewal genuinely painful. Add monitoring for expiry regardless — automation that silently broke is the leading cause of certificate outages, and at 47-day lifetimes a broken renewal job surfaces in weeks, not months.
Haven's own infrastructure runs on automated short-lived issuance — it's the only sane way to operate TLS at this point. The 47-day certificate isn't a hardship to prepare for; it's the system finally matching how reliable infrastructure already works.