The 47-Day Certificate Is Coming — Is Your Team Ready?
If you manage infrastructure, you’ve probably renewed a TLS certificate without thinking twice about it.
Set a reminder, wait for the email, click renew, move on. Once a year, maybe twice. It’s the kind of task that lives at the bottom of the to-do list because it’s boring, low-risk, and rarely goes wrong.
That’s about to change, and it’s changing faster than most teams realise.
We’re already living the first cut
Back in April 2025, the CA/Browser Forum — the industry body that sets the rules every public certificate authority has to follow — approved a phased reduction in how long a public TLS certificate is allowed to live for. It wasn’t a single change. It was a cascade, and it’s already underway.
Here’s the schedule:
Until March 15, 2026, the cap was 398 days — roughly what we’ve all grown used to. From March 15, 2026, that dropped to 200 days. That happened six months ago. If you haven’t noticed a change in how often your team is renewing certificates, it’s worth checking why — because the cap is now half what it used to be, whether or not your process has caught up.
The next drop lands March 15, 2027 — six months from now — when the maximum falls to 100 days. Then, from March 15, 2029, it falls again to just 47 days.
By the end of this cascade, a certificate that used to live for over a year will need renewing roughly every six and a half weeks.
Why is this happening?
It’s not bureaucratic tidiness. Shorter-lived certificates shrink the blast radius when something goes wrong — a compromised certificate authority, a mis-issued certificate, a private key that leaks. The shorter the lifetime, the less damage a bad certificate can do before it expires on its own. Browsers and CAs have been pushing this direction for years, and the rest of the industry is now formally catching up.
It’s a good move for the internet’s security. It’s a genuinely uncomfortable one for any team still managing certificates by hand.
What “doing nothing” actually looks like
The maths is the part that sneaks up on people. If your organisation manages, say, 150 public certificates and you’re used to renewing them roughly once a year, you’re already looking at closer to 270 renewal events a year post-March 2026. Once the 100-day cap lands in 2027, that climbs to around 550. By 2029, at 47 days, you’re past 1,100 renewal events a year for the same 150 certificates — more than three a day, every day, forever.
That’s not a slightly bigger version of the job you have today. It’s a different job.
And the risk isn’t hypothetical. An expired public certificate doesn’t fail quietly — it breaks the site, breaks the API integration, throws a browser warning at every visitor, and very often ends up as a headline rather than a footnote. As renewal frequency climbs, the odds of a human missing one climb with it. Not because anyone’s careless, but because the margin for error shrinks every time the clock gets shorter.
There’s a second problem hiding underneath the first: most organisations don’t have a complete picture of their own certificate estate. Certificates get issued by different teams, different tools, sometimes different CAs entirely, and they end up living on load balancers, internal services, IoT devices, and long-forgotten subdomains that nobody remembers. That’s manageable when renewals happen once a year. It stops being manageable when renewals happen every six weeks across an inventory nobody’s fully mapped.
And it’s not just the technical teams who should care. PCI DSS and NIST guidance are increasingly treating strong visibility and monitoring of certificate estates as a baseline expectation rather than best practice. That means this is becoming an audit conversation as much as an engineering one.
So what should teams actually do?
Start by asking the boring but essential question: do we actually know where all our certificates are, who owns each one, and when each one expires? If the honest answer is “mostly” or “I think so,” that’s the first thing worth fixing — before anything else. You can’t manage, automate, or even properly risk-assess what you can’t see, and for most organisations, getting a true, continuously updated inventory (including certificates issued outside official channels, on infrastructure nobody remembers, or by teams operating independently) turns out to be harder than expected.
From there, it’s worth treating the March 2027 deadline the way you’d treat any other hard compliance date — with a project, an owner, and a timeline, rather than something that gets absorbed quietly into business as usual. Six months feels like plenty of time right up until it isn’t.
Discovery, not data entry. And deliberately not a CLM
Worth being clear on what that first step is, and isn’t. A full certificate lifecycle management (CLM) platform — the kind that handles issuance, automated reissuance, and deployment across every system — is a serious undertaking, and for a lot of organisations it’s the eventual destination. But it’s also a genuinely complex project: integrating with every CA, every server, every load balancer, and every internal process that touches a certificate. Visibility is a different, much smaller step — knowing what you have, where it lives, who owns it, and when it expires — and it’s one you can take now, independently of whether or when you commit to a broader CLM rollout. Get that foundation right first, and whatever you decide to do next becomes a far easier decision.
The conversation worth having now
If you’re reading this and you’re not entirely sure how your organisation’s certificate estate would hold up under a 100-day renewal cycle, you’re not alone — most teams are in the same position, because until recently there was no pressure to know. That’s changing fast.
We’d genuinely like to help you find out where you stand — not with a sales pitch, but with a straightforward look at your actual certificate footprint: what you have, what’s about to become a problem, and where the real gaps in visibility are. If that sounds useful talk to us about a free certificate health check.