If you manage TLS certificates, the ground has already shifted under you - and most teams haven't felt it yet.
In April 2025, the CA/Browser Forum (the body that sets the rules every public certificate authority and browser follows) approved a change that cuts the maximum life of a publicly trusted TLS certificate from 398 days to just 47. It doesn't happen all at once. It happens in three steps between now and 2029 - and the first one is already in effect.
Here's what's changing, when each phase lands, and why a rule that sounds like housekeeping is about to reshape how much work your team spends keeping services online.
What's actually changing
Until last year, a public TLS certificate could be valid for up to 398 days - comfortably over a year. You issued it, and renewal was a once-a-year event you could almost forget about. Under CA/Browser Forum Ballot SC-081v3, that window shrinks in three phases:
By the final phase, a certificate that used to last more than a year will last about six and a half weeks.
There's a second change that often gets missed, and it matters just as much. The period you're allowed to reuse domain validation - the proof that you control the domain - shrinks on the same timeline, and in the final phase it drops to just 10 days. In practice, that means you won't just be reissuing certificates more often; you'll be re-proving domain ownership at nearly every renewal.
Why the industry is doing this
A certificate is a statement of trust: it says "this really is who it claims to be." The longer a certificate stays valid, the longer that statement holds even if something has gone wrong behind it - a key has been compromised, a domain has changed hands, information has gone stale. Shorter lifespans shrink that window of risk. If a certificate is only valid for 47 days, a compromised one is a much smaller problem than one that stays trusted for over a year.
So the change genuinely improves security across the internet. The catch is that it moves the cost from risk to operations - and that cost lands squarely on the teams who manage certificates.
Why it matters for your team
The security benefit is industry-wide, but the workload is yours.
Every reduction in validity multiplies how often you have to renew. A certificate valid for 200 days needs renewing roughly twice a year. At 47 days, it needs renewing nearly eight times a year - for every certificate you hold. Multiply that across a real environment, and a manageable monthly task becomes a near-daily one.
For a smaller estate, that's an irritation. For a mid-to-large organisation running hundreds, thousands or even tens of thousands of certificates across internal systems, public-facing services, and increasingly across automated pipelines, it's a structural change in how much effort "keeping the lights on" actually takes.
And the failure mode is unforgiving: an expired certificate doesn't degrade gracefully, it takes the service down.
What to do about it now
The organisations that will handle this well aren't the ones who start renewing faster, they're the ones who stop renewing manually.
The three phases are deliberately spaced to give teams time to move certificate issuance and renewal onto automated processes before the volume becomes unmanageable. The first step to take isn't technical - it's visibility: knowing how many certificates you actually hold, where they live, and how often each will need renewing under the new rules. Most teams discover the number is higher than they thought, often by 2-3 times.
The bottom line
The 47-day certificate isn't a distant 2029 problem. The schedule is already running, the workload curve is already bending upward, and the gap between manual processes and what's required widens at every phase. The sooner you know where your environment sits on that curve, the more time you have to get ahead of it.
See exactly what the new schedule means for your team's workload. [Calculate your renewal load →]
