The headline that went around in 2025 was “47-day certificates.” It got the panic it deserved, and most of the panic was aimed at the wrong year and the wrong number.
The 47-day limit doesn’t arrive until March 15, 2029. That’s the part everyone repeated. The part almost nobody mentioned: the first cut already happened. Since March 15, 2026, no publicly trusted CA can issue you a TLS certificate valid for more than 200 days. If you got a certificate this spring and it came back with a shorter lifetime than you remembered, that wasn’t your CA being stingy. That was the new rule, and it is already in force.
So here’s a question worth asking before 2029: did your renewal break in March? If the answer is no, it’s probably because you’d already automated. If the answer is “I don’t know,” that’s the actual story of this whole change.
What Actually Passed
The thing people call “the 47-day rule” is Ballot SC-081v3, proposed by Apple and passed by the CA/Browser Forum on April 11, 2025. The vote is more interesting than the number.
Browsers — the Certificate Consumers — voted 4 to 0 in favor: Apple, Google, Microsoft, Mozilla. Unanimous. The CAs — the Certificate Issuers, the companies whose entire business is selling longer-lived certificates — voted 25 yes, 0 no, with 5 abstentions (Entrust, IdenTrust, Japan Registry Services, SECOM Trust Systems, TWCA).
Read that again. The companies being asked to sell a worse product voted yes, or stepped aside. None of them voted no. That’s not consensus; that’s leverage. A CA’s root certificate is only worth something because it lives in the browser trust stores, and the browsers were the ones unanimously in favor. When your distribution channel votes on your product roadmap, you don’t get to veto it. This was browsers running PKI policy and CAs ratifying a decision that had already been made for them.
This didn’t come from nowhere. Google laid it out in its “Moving Forward, Together” roadmap, floating a 90-day maximum. Apple’s first draft ballot in October 2024 went further — 45 days by 2027. The final compromise stretched the timeline and rounded to 47, but the direction was never in doubt.
The Schedule Nobody Memorizes
Here’s the whole thing, validity on the left:
- Now → March 15, 2026: 398 days (the old limit)
- March 15, 2026: 200 days ← you are here
- March 15, 2027: 100 days
- March 15, 2029: 47 days
If you only track this one column, you’ll prepare for the wrong deadline. Because there’s a second column, and it’s the one that’s going to hurt.
The Number That Actually Bites: 10 Days
Every certificate starts with domain control validation — you prove to the CA you actually control the name, usually by answering an ACME challenge. Once you’ve proven it, the CA is allowed to reuse that proof for a while and issue further certificates without making you re-validate. That reuse window has its own schedule under SC-081v3, and it collapses harder than the validity does:
- March 15, 2026: 200 days
- March 15, 2027: 100 days
- March 15, 2029: 10 days
Ten days. By 2029, the proof that you own your domain goes stale in a week and a half. That, not the 47-day cert, is the line that ends manual certificate management for good.
Think about why. A 47-day certificate you can technically still renew by hand nine times a year if you hate yourself. But a 10-day validation window means the authorization step — the DNS record, the HTTP token, the thing a human used to do once and forget — has to happen on a near-weekly cadence too. You cannot run a weekly re-validation loop on a calendar reminder and a person who might be on vacation. The reuse clock is what forces the entire pipeline to be machinery, not just the renewal at the end of it.
The validity number got the headlines. The reuse number is the forcing function.
This Was Always Where It Was Going
If you want to see the endpoint of this trend, look at where the most automated CA already is. In January 2026, Let’s Encrypt made 6-day certificates generally available — 160 hours, a “shortlived” profile you select in your ACME client — along with certificates for bare IP addresses. Forty-seven days is not the destination. It’s a waypoint. The destination is certificates that live for days and are replaced by software you never think about, the same way your DHCP lease renews without you sending anyone an email.
And honestly? Shorter is better, for a reason the industry doesn’t love admitting: certificate revocation is broken. CRLs are too big and OCSP is too leaky and browsers soft-fail both, so a compromised certificate stays dangerous until it expires. If revocation doesn’t really work, the only reliable way to limit the damage from a stolen key is to make every certificate expire soon. Short lifetimes are the revocation mechanism. They’re the one that actually functions.
The Trade You’re Actually Making
I don’t want to sell this as free. It isn’t.
When your certificates lived a year, your CA could have a bad afternoon and you’d never notice. When they live 47 days — or 6 — your automation and your CA’s availability become load-bearing parts of your uptime. A broken ACME client, an expired API credential, a CA outage during a renewal window: any of those now expires real certificates on real traffic. We are trading the risk of stale, long-lived, hard-to-revoke certificates for the risk of brittle automation and a hard dependency on issuance infrastructure that has to work every single week.
That’s a good trade. It is still a trade, and pretending otherwise is how people get surprised at 2 a.m.
The certificate stopped being a document you file once a year and became a heartbeat. If anything in your stack still treats it like paperwork, you have until March 2029 to fix that — but the first cut already landed, and the clock only gets faster from here.