By 2029 every public TLS certificate renews 7.77 times a year, and a calendar can't keep up
From 15 March 2029, no publicly trusted TLS certificate can last longer than 47 days. That's 7.77 renewals per certificate per year, up from 0.92 under the old 398-day limit.
The schedule is voted, dated and already in force
In April 2025 the CA/Browser Forum adopted Ballot SC-081v3. It passed 29 in favour, none against, with five abstentions. Apple, Google, Microsoft and Mozilla all voted yes, and browsers enforce it by refusing to trust certificates that break it.
| Effective | Max certificate lifetime | Max domain-validation reuse | Renewals per certificate per year |
|---|---|---|---|
| Before 15 Mar 2026 | 398 days | 398 days | 0.92 |
| 15 Mar 2026 (in force now) | 200 days | 200 days | 1.83 |
| 15 Mar 2027 | 100 days | 100 days | 3.65 |
| 15 Mar 2029 | 47 days | 10 days | 7.77 |
The last column is 365 divided by the lifetime, so you can check every cell. Multiply it by the number of public certificates you hold and you have your yearly renewal count at each step. The real figure runs higher, because nobody sensible renews on the last valid day.
The 398-day row isn't part of the ballot. It's the old Baseline Requirements limit the schedule steps down from, and it's there because it's the row your current process was built for.
The 10-day validation column is the one most plans miss
Domain-validation reuse is how long a CA can rely on an earlier proof that you control the domain. Today that proof lasts as long as the certificate does. From March 2029 it lasts 10 days while the certificate lasts 47.
So almost every renewal will need a fresh proof of control. If that step waits on a person to click a validation email or paste a DNS record, it now happens 7.77 times a year for each certificate. Any validation step a human performs has to become one a machine performs.
The first squeeze is this quarter
Teams that renewed once a year are meeting their second renewal of the year for the first time. Certificate authorities put that wave at roughly October to December 2026, as the first 200-day certificates issued after 15 March come due. Treat the timing as approximate, since renewal dates are staggered across any estate.
The next step is already on the calendar. In our lab we issued a certificate at the maximum 200-day lifetime on 27 August 2026. It expires on 15 March 2027, the day the 100-day rule takes effect. Its replacement can last 100 days at most.
We issued all four lifetimes from the table on a private step-ca 0.30.2 CA, and the 47-day leaf fails openssl verify one second after it expires (lab record 2026-08-27-p1-47-day-issuance). The 2029 scenario can be run today.
Calendar-driven renewal breaks at 100 days
A year doesn't divide into 100-day blocks. We issued a 100-day certificate on 6 September 2026 and computed its renewals. They fall on Tuesday 15 December, Thursday 25 March, Saturday 3 July, Monday 11 October, Wednesday 19 January and Friday 28 April. Each lands about nine days later in the calendar than the last, on a different weekday and day of the month.
Now put a quarterly reminder against it (lab record 2026-09-06-p2-calendar-driven-renewal-breaks).
| Cycle | Reminder fires | Certificate due | Reminder is early by |
|---|---|---|---|
| 1 | 7 Dec | 15 Dec | 8 days |
| 2 | 8 Mar | 25 Mar | 17 days |
| 3 | 7 Jun | 3 Jul | 26 days |
| 4 | 6 Sep | 11 Oct | 35 days |
| 5 | 7 Dec | 19 Jan | 43 days |
| 6 | 7 Mar | 28 Apr | 52 days |
The drift only grows. Renew on the reminder and you throw away weeks of validity each cycle. Learn that the reminder is always early, and you start ignoring it, which works until the cycle it doesn't.
Stretch the reminder to every four months and it goes the other way. It fires about 22 days after the certificate has already expired.
None of this is a competence problem. A person with a calendar can handle 0.92 renewals a year indefinitely. At 3.65 the hand-computed dates become the failure. At 7.77, one renewal every 6.7 weeks per certificate, it's a job for a scheduler.
Automate what free tools can renew, before March 2027
Most public certificates can renew without a human, using tools that cost nothing: Let's Encrypt, certbot, cert-manager on Kubernetes, or AWS ACM. In our lab, certbot renew re-issued two certificates against a Pebble ACME server with new serial numbers and no manual step (lab record 2026-09-06-p5-manual-vs-automated). If an ACME client can reach a certificate, let it own the renewal. Nobody should be paying a consultant for that part.
What's left after that is the set no ACME client can reach, which is a different problem. We wrote it up in the certificate estate you cannot enumerate.
Count your public certificates first
Every publicly trusted certificate has to be logged in Certificate Transparency, so the public half of your count already exists. The free certificate estate check reads it for you.
Enter a domain you own and an email address at that domain. We read the public CT logs for that domain and nothing else, then email you the result. It shows unexpired certificates and the names they cover, issuers, median lifetime, the share from automated issuers, and what the 47-day schedule means for that pattern. A person reads each report before it's sent.
Get your free certificate estate check
Sources. CA/Browser Forum, Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (adopted April 2025), for the dates, lifetimes, reuse periods and vote. Renewals per year are 365 divided by each lifetime. Lab figures come from MLabs PKI lab records 2026-08-27-p1-47-day-issuance, 2026-09-06-p2-calendar-driven-renewal-breaks and 2026-09-06-p5-manual-vs-automated.
