If your organisation runs a website, an API or anything with a padlock in the address bar, the renewal cadence you are used to is about to change materially.
In April 2025 the CA/Browser Forum — the body that sets the rules for publicly trusted certificates — passed Ballot SC-081v3. It cuts the maximum lifetime of a public TLS certificate in three stages:
- 200 days from 15 March 2026
- 100 days from 15 March 2027
- 47 days from 15 March 2029
The first stage has already happened. By 2029, a certificate that used to be renewed once a year will need renewing roughly eight times.
Why this is more disruptive than it sounds
For a small estate with good automation, this is a non-event. For everyone else, three things bite.
The first is volume. A hundred public certificates becomes eight hundred renewal events a year. Whatever process you have now gets run eight times as often, and every manual step in it gets run eight times as often too.
The second is the recovery window. Under a 398-day certificate, a renewal that failed silently could sit unnoticed for weeks and still be fixed before anything broke. At 47 days there is no slack. The process has to work every time, not once a year.
The third is domain validation. The same ballot reduces how long a certificate authority may reuse domain validation evidence, dropping to ten days by 2029. Re-validating domain ownership becomes a continuous activity rather than something that happens at renewal.
Where organisations actually get caught
The pattern is consistent, and it is rarely the certificates anyone knows about.
Most organisations cannot say with confidence how many certificates they have. They get issued by different teams, bought on different cards, embedded in appliances by suppliers, and created for short-term projects that quietly became production. The renewal reminder goes to a mailbox nobody monitors, or to someone who left eighteen months ago.
Then there are the systems automation cannot reach: appliances with no modern enrolment support, certificates deployed to CDN providers or third-party load balancers outside the main process, and legacy middleware nobody wants to touch. These are the ones that will fail first, because they are the ones where a shorter cycle multiplies an already manual process.
What to do about it
None of this requires immediate spend. In rough order:
- Find out what you actually have. Every publicly trusted certificate, the system it protects, who owns it, and how it currently gets renewed. Most organisations find more than their records show, and that gap is the whole problem.
- Check ACME support across your estate. Which load balancers, web servers, CDNs and API gateways support automated issuance natively, which need an agent, and which support nothing. The last category is where your risk sits.
- Test renewal end to end, not just issuance. A renewal is only complete when the application is serving the new certificate, which usually means a restart or config reload. Automation that stops at issuance leaves a human in the loop at the step most likely to break.
- Document your exceptions. Some systems will not support automation in the near term. Track them as managed risk rather than letting them drift towards a cliff edge.
The wider point
The direction of travel is not going to reverse. The CA/Browser Forum's own reasoning is partly that revocation has never worked reliably enough at internet scale, so shorter lifetimes provide protection that does not depend on revocation infrastructure functioning.
That same logic will apply to the next change, and the one after. Building the capability to handle certificate change as routine — rather than as an incident — is worth more than solving the 47-day problem specifically. We have written in more detail about what certificate lifecycle management involves and how to evaluate the platforms that deliver it, including the licensing models that behave very differently once renewal frequency multiplies.
Unsung is a UK consultancy specialising exclusively in public key infrastructure. We are vendor-neutral and work across central government, defence, financial services, healthcare and transport. More at unsungltd.com
