The 47-day certificate
The maximum lifetime of a publicly trusted TLS certificate is being cut from 398 days to 47. This is not a proposal still under discussion — the CA/Browser Forum approved ballot SC-081v3 on 11 April 2025, and the first reduction is already in force.
| From | Maximum lifetime | Renewals per certificate per year |
|---|---|---|
| Before 15 March 2026 | 398 days | About once |
| 15 March 2026 — in force today | 200 days | About twice |
| 15 March 2027 | 100 days | About four times |
| 15 March 2029 | 47 days | About eight times |
The first step is already behind us. Most coverage of this change is written about 2029, which makes it sound distant. The 200-day limit took effect in March 2026 — every certificate issued since then already renews twice as often as the one it replaced.
Why the industry is doing this
- Revocation does not work reliably. When a private key leaks, revoking the certificate is supposed to stop it being trusted. In practice clients often continue anyway when a revocation check cannot be reached, so a leaked key can stay usable. A short lifetime limits the damage without depending on revocation working.
- A shorter certificate is a shorter exposure window. The industry is trading a slow, unreliable safety mechanism for a simple one — certificates expire on their own, everywhere, with nobody acting.
- Automation is only trustworthy if it runs often. A renewal that happens once a year is a procedure nobody has practised. One that runs monthly is exercised constantly, so it fails loudly and early rather than at the worst possible moment.
Proving you control the domain gets shorter too
The same ballot also shortens how long a CA may reuse an earlier domain control validation. That proof could historically be reused for up to 398 days; by March 2029 it falls to 10 days. This matters more than the certificate lifetime itself, because it means you cannot simply reissue against a stored approval — you must be able to answer a fresh domain control challenge nearly every time, which is only realistic if it is automated.
What breaks first
- The spreadsheet. A list maintained by hand is accurate for about a week after someone updates it. At eight renewals a year across dozens of certificates it is wrong almost all of the time.
- The calendar reminder. Reminders were designed around one renewal a year, not a task that recurs monthly — and they leave with the person who created them.
- The one person who knows. Annual renewals concentrate the knowledge in whoever did it last time. That is a single point of failure, and it takes holidays.
- Appliances without ACME. Load balancers, firewalls and VPN gateways that need a certificate uploaded by hand will consume the most time, and they are usually the most visible when they fail.
What to do now
- Get a complete inventory first. You cannot automate certificates you do not know about, and the ones that cause outages are usually the ones nobody remembered. Network Discovery and CT monitoring find certificates issued for your domains without going through you.
- Automate issuing and deployment together. Automatic issuance on its own still leaves someone copying a file onto a server — see Agents & deployment.
- Keep monitoring after you automate. Automation fails quietly; monitoring is what tells you before the browser does.
NOLAPSE is built for this shape of problem: find what you have, issue and renew it automatically, deploy it to the machine that serves it, and tell you when something stops working. If you are starting from a spreadsheet, Quick start takes one domain end to end.