Abstract
You probably heard that certificate lifetimes are getting shorter. What I don’t think has landed yet for most teams is what the math actually looks like (not in 2029, but now).
As of March 2026, every public CA cuts you off at 200 days. That’s already live. By March 2029, the ceiling drops to 47 days. If you manage certificates manually today, your renewal workload roughly octuples between now and the end of the decade.
Here’s the canonical schedule, what’s driving it, and what it does to the work in front of you.
The schedule
The CA/Browser Forum locked the timeline in with Ballot SC-081 in early 2025. Every public CA is required to enforce it.
Through March 15, 2026: 398-day maximum (expired)- March 15, 2026: 200-day maximum (current)
- March 15, 2027: 100-day maximum
- March 15, 2029: 47-day maximum
The deadlines apply to the issue date of the certificate, not the order date. A cert issued on March 14, 2026 still got 398 days. One issued on March 16 got 200.
Why this is happening?!? Two reasons.
First, certificate revocation is broken. When a certificate is compromised, you cannot reliably yank it from the web. Browsers don’t check revocation lists in any meaningful way. The only mechanism that actually works is expiration. Shorter lifetimes mean shorter exposure when something goes wrong.
Second, certificates outlive their context. Domains change hands and vendors get fired, but the certificates issued before those changes keep working. Researchers call this the stale certificate problem. Zane Ma’s research found that roughly 7% of all certificates are stale, and that cutting lifetimes to 45 days reduces stale-certificate attack surface by 95%.
The full political story of how the browsers forced this through over fifteen years of CA opposition is in the 47-day ultimatum. The short version: the browsers got tired of waiting, and they stopped asking.
What this does to your renewal cadence
Renewals scale linearly with lifetime. Here is the math at each step of the schedule, assuming you renew at the moment of expiration.
| Validity period | Effective | Renewals/year | 10 certs | 50 certs |
|---|---|---|---|---|
| 398 days | through March 2026 | ~1 | ~10 | ~50 |
| 200 days | March 2026 | ~2 | ~20 | ~100 |
| 100 days | March 2027 | ~4 | ~40 | ~200 |
| 47 days | March 2029 | ~8 | ~80 | ~400 |
A team running 50 certificates manually today does about 50 renewals a year. The same team, the same certificate count, in three years, does 400. That isn’t a process tweak. It’s a different job.
This math also assumes you renew at the moment of expiration, which nobody does. Renew at the recommended two-thirds-of-lifetime mark and the numbers get worse.
What to do about it
You have three options, and one of them is keep it the way it is and hire 3 more people to manage full-time certificate renewal. You’re probably not going to do that.
The next option is to build automation yourself. ACME clients like Certbot handle the issuance side. The hard part is everything that comes after issuance: getting the renewed cert to every server and appliance that needs it, monitoring that the new cert was actually picked up, audit trails, handling unscheduled renewals when a CA does an emergency revocation. Certificate distribution is the last mile that nobody solves with a Certbot script.
The last option is to use a certificate lifecycle management platform that handles the whole pipeline. That’s what I built CertKit to do, not because Certbot is bad at issuance, but because issuance is the easy part.
The decision between the options is a build versus buy question, and like all build versus buy questions it comes down to whether certificate management is something you want to maintain forever. Todd’s tenth rule applies here. The schedule does not stop at 47 days. ACME specs evolve. CAs have incidents that force emergency revocations. Whatever you build today is something you signed up to maintain.
200-day certificates are reality now. 100-day certificates arrive in less than a year. If your renewal process today is a calendar reminder and a half-remembered runbook, you have a narrow window to fix it before the cadence makes manual impossible.
CertKit handles the entire certificate lifecycle, so dropping certificate lifetimes are not your problem.
Comments