Abstract
Certificate lifetimes are getting shorter. As of March 2026, every public CA cuts you off at 200 days. That’s already live. By March 2029, that drops to 47 days. If you manage certificates manually today, your renewal workload is twelve times more 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 set 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.
This sucks. Why this is happening?!?
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 bygone SSL, or the stale certificate problem. Researchers 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
Renewal work scales up with lifetime. Here is the math at each step of the schedule, renewing at the recommended two-thirds-of-lifetime mark.
| 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 | ~12 | ~120 | ~600 |
A team running 50 certificates manually today does about 50 renewals a year. The same team, the same certificate count, in three years, does 600. That isn’t a process change. It’s a different job.
Renewing at the moment of expiration would make those numbers smaller, and nobody does it. A certificate that renews the day it dies has no margin for a failed attempt, so every sensible client renews early.
This won’t stop at 47 days. The post-quantum redesign Let’s Encrypt is planning, Merkle Tree Certificates, strips out most of the cost of issuing a certificate, which removes the main reason not to go shorter still. I expect certificate renewal to be weekly by 2050.
What to do about it
You have three options. One is to just keep doing what you’re doing, and hire some fulltime “certificate admins” to run the process. 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 that: 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 you can’t solve with a Certbot script.
The last option is to use a certificate lifecycle management platform that handles the whole pipeline. That’s what we built CertKit to do.
The decision 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, and you should know what you are signing up for.
200-day certificates are reality now. 100-day certificates arrive in less than a year. If your renewal process today is a calendar reminder, spreadsheet, and a half-documented 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.