Why SSL certificates are getting shorter — and what 47-day certificates mean for you
The maximum lifetime of a public SSL/TLS certificate is being cut in stages: from 398 days today to 200 in March 2026, 100 in March 2027, and 47 by March 2029. The rule comes from the CA/Browser Forum — the body where browser makers and certificate authorities agree on what every public certificate must do — in a measure called Ballot SC-081v3, approved in April 2025 with no votes against. It changes only publicly-trusted certificates, and its practical effect is blunt: renewing certificates by hand stops being workable, and automation stops being optional.
Most writing on this is either a vendor warning you to buy something or a checklist of dates. This is the explanation underneath — what is actually changing, why each part of it makes sense, and the piece almost nobody covers: what it means for a site that already renews automatically.
What's changing, and when
Two clocks are being shortened on the same schedule. One is how long a certificate stays valid. The other is how long a certificate authority may reuse an earlier check that you control your domain before it has to verify again.
| From | Max certificate lifetime | Max domain-validation reuse |
|---|---|---|
| Today | 398 days | 398 days |
| 15 March 2026 | 200 days (199 in practice) | 200 days |
| 15 March 2027 | 100 days | 100 days |
| 15 March 2029 | 47 days | 10 days |
By the final step a certificate lives 47 days and the proof you own the domain is good for only 10. We will come back to why those two numbers split apart. First, the bigger question.
Why certificate lifetimes are shrinking at all
Three reasons, and they reinforce each other.
Revocation doesn't reliably work
When a private key is stolen or a certificate is issued in error, the certificate is supposed to be revoked — cancelled before it expires. Authorities publish revocation lists (CRLs) and run a lookup service (OCSP) so a browser can ask, "is this certificate still good?" The trouble is what happens when that question can't be answered. To avoid breaking or slowing every page load when a revocation server is slow or unreachable, browsers generally soft-fail: if the check doesn't come back, they assume the certificate is fine and carry on. A revoked certificate therefore often keeps working in the wild. If you can't depend on cancelling a bad certificate, the dependable lever left is time. A certificate that only lives 47 days can only be abused for 47 days — no revocation machinery required. Short validity is, in effect, revocation that always works.
The facts inside a certificate go stale
A certificate is a signed claim: this key belongs to this domain, controlled by this party, at the moment of issue. The world then moves on. Domains change hands. Keys leak. Companies merge or fold. The longer a certificate lives, the greater the chance its claims no longer match reality. Issuing more often forces those facts to be re-checked, so what a certificate asserts stays close to what is actually true.
It forces automation — deliberately
For years the Forum has ratcheted lifetimes down a notch at a time, and the message each time is the same: managing certificates by hand does not scale. Renewing a few certificates a year is a calendar reminder; renewing every server's certificate every few weeks is a system. Shorter lifetimes make automated issuance — usually the ACME protocol, the approach Let's Encrypt popularised — the only sane option. And automation is itself safer: keys rotate more often, people touch private keys less, and the renewal path is exercised constantly instead of once a year.
There is a longer game too. The industry is preparing to move to post-quantum cryptography — new algorithms meant to withstand future quantum computers. That migration is far easier on an internet that already rotates certificates as routine than on one where a certificate might sit untouched for over a year. Shorter lifetimes build the reflex for fast, fleet-wide algorithm changes. This is not the ballot's stated reason, but it is a widely-held one for why the trend only points one way.
Why step down gradually instead of jumping to 47
The Forum could have cut straight from 398 days to 47. It didn't, and the reason is survival. A large share of organisations still renew certificates manually. Drop the limit to 47 days overnight and many of them would simply fall behind — certificates expiring faster than people could replace them, sites going dark in waves. The staircase — 398, then 200, then 100, then 47, each step about a year apart — is runway. Each step is uncomfortable enough to push the holdouts toward automation, but not so sharp that the ecosystem snaps. It gives tooling vendors, hosts, and internal teams time to adopt ACME and find the bugs while the cadence is still survivable by hand.
Why the numbers are so awkward — and why 47
Notice the thresholds aren't round. 200, 100, and 47 were not picked for tidiness; they were picked to assume automation. The usual explanation is that 47 days breaks down as a 30-day renewal cycle plus a 17-day buffer: an ACME client is typically set to renew about 30 days before a certificate expires, which leaves 17 days of slack for automated retries if a renewal attempt fails. Read that back — the number only makes sense if a machine is doing the renewing. A human with a calendar has no natural 47-day rhythm to latch onto; there is no "renew every quarter" or "first of the month" that lines up. The structure of 47 is the message: it is built around how software renews, not how people remember.
Why "200 days" really means 199
Here is a detail that signals you actually understand the rules. When the cap becomes 200 days, careful authorities issue certificates for 199. Validity is not counted in calendar days; it is counted in seconds, from the "not before" timestamp to the "not after" timestamp, inclusive of both ends. A certificate stamped for a full 200 days using the same time of day at each end lands a second or two beyond the limit — and under the Baseline Requirements, exceeding the maximum validity even slightly is a misissuance. A misissued certificate has to be revoked, normally within five days. No competent authority wants to revoke its own freshly-issued certificates over a rounding edge, so it shaves a day. DigiCert, for instance, moved to 199-day certificates ahead of the deadline, in February 2026, stating plainly that it issues "one day shorter than the maximum… to avoid exceeding the maximum permitted validity." Expect the same one-day haircut at every step (100 will be issued as 99, and so on).
Why domain validation is shrinking too
Running quietly beside the lifetime cuts is that second clock: how long an authority may reuse an earlier proof that you control a domain. Today a domain-control validation can be reused for up to 398 days. That falls to 200, then 100, then just 10 days by 2029. The logic mirrors the certificates themselves. A validation done a year ago might not be true today — a domain can expire and be re-registered by someone else, DNS can be misconfigured or hijacked, control can quietly change hands. Re-checking control close to the moment of issuance shrinks the window in which a certificate could be handed to someone who used to control a domain but no longer does. By 2029, with 47-day certificates and 10-day reuse, nearly every renewal re-proves control from scratch — which is also why automation has to reach down into your DNS, not just your web server.
Does this actually affect you?
Two questions settle it.
Are your certificates public? This rule governs only publicly-trusted certificates — the ones issued by authorities in the browser root programs, which a browser accepts without a warning. If you run an internal certificate authority for services inside your own network, with a private root your own machines are configured to trust, none of this binds you. You set those lifetimes. The 47-day clock is about the public web.
Do you already renew automatically? If you are on Let's Encrypt, a managed host, or a platform that terminates TLS for you — most CDNs, many app platforms — you are largely in the right place. Automation is exactly what the Forum is steering everyone toward. But "I have automation" and "I am safe" are not the same sentence, and the gap between them is the part worth sitting with.
The real risk is silent failure
Shorter certificates don't invent a new problem so much as swap one problem for a quieter one. The old failure was human and loud: someone forgot to renew, the certificate expired, the browser threw a full-page warning, and you heard about it fast — usually from a customer, within the hour. The new failure is automated and silent. Once renewal runs on its own, you stop watching it, and automation breaks in ways that don't announce themselves:
- the ACME client renews the certificate, but the web server is never reloaded, so it keeps serving the old one until it expires;
- a DNS-based validation quietly stops working after a DNS change, and renewals simply stop;
- a cron job dies, a token expires, or a staging config overwrites production;
- the certificate renews for the wrong hostname, or for only some of the names on it.
None of these page you. They sit silent until the certificate actually expires — and then everything breaks at once, often in the middle of the night, with nobody expecting it.
Now multiply by frequency. A certificate you renewed once a year gave that machinery one chance a year to fail quietly. A 47-day certificate gives it roughly eight. More renewals isn't only more convenience — it is more rolls of the dice on a process built specifically to run without you looking. Frequency multiplies the surface area for silent failure.
The defence isn't to renew more carefully. It is to stop trusting that the machinery worked and check the result instead: look at the certificate your server is actually serving, right now, from the outside, the way a browser sees it — and confirm it is valid and not about to expire. Not the renewal logs. The live certificate. It's a thirty-second check, and it catches every failure above, because they all end in the same place: a live certificate that isn't what you assumed it was.
Check your own certificate
Enter a domain and we'll fetch its live certificate — issuer, validity, and days remaining — alongside its DNS and registration, and give you one plain verdict. No signup.
Certificates getting shorter is good for the web: less time for a stolen key to do harm, fresher proof of who owns what, and an internet that can change its cryptography quickly when it must. The trade is that the thing keeping your site reachable now runs on autopilot. So the habit worth keeping isn't renewing certificates — software does that now. It's checking, every so often, that the autopilot is still flying.