Earlier this year, a decision was “quietly” made that will create real operational headaches for most organisations — and a lot of people haven’t noticed yet.
On 11 April 2025, the CA/Browser Forum — the industry body that governs SSL/TLS certificates — voted to progressively shorten certificate validity periods. The end point: a maximum of 47 days by 2029. The first milestone already hit this month.
For a change, I’m not writing this to sell or promote anything. I’m writing this because I’ve been in the PKI and digital security space for a long time, and I’ve seen how these kinds of changes catch organisations off guard when they’re buried in forum announcements and technical documentation that most business leaders never read.
So here’s the plain-English version.
What changed, and when
Previously, organisations can obtain an SSL/TLS certificate valid for up to 398 days — a little over 13 months. That’s the window you have before you need to renew.
Under the new schedule approved by Apple’s proposal at the CA/Browser Forum, that window shrinks significantly:
| Maximum Certificate Lifespan | Effective Date |
| 200 days | 15 March 2026 |
| 100 days | 15 March 2027 |
| 47 days | 15 March 2029 |
The first cut — to 200 days — applies from 15 March 2026. That’s now.
If your organisation is renewing or issuing new certificates from this point forward, you’re already operating under the new rules.
Why did this happen?
The reasoning is sound, even if the timing creates inconvenience. Shorter certificate lifespans reduce the window of exposure if a certificate is ever compromised. If an attacker gets hold of a certificate, a 47-day lifespan limits how long they can exploit it.
There’s also a push to get organisations away from manual, ‘set it and forget it’ approaches to certificate management — which, frankly, most organisations still rely on.
The industry is essentially forcing automation. The question is whether your organisation is ready for it.
What this means at the leadership level
Most of us as leaders are not the ones managing certificates day to day. That sits with your IT or security team. But the decisions that come out of this change will land on your desk — because the response options each carry trade-offs that go beyond the technical.
The math is straightforward. If your organisation manages 50 certificates today and renews them once a year, that is roughly 50 renewal actions annually. At 47-day validity, the same estate requires close to 400 renewal actions a year. Some teams, when they hear this, immediately ask: can we just hire more people to handle the increased frequency?
It is a fair instinct, but it misses the real problem. The issue is not volume alone — it is complexity and visibility. Certificates are often reused across multiple systems. It is not best practice, but it happens, and it happens a lot. When that is the case, a single certificate expiring does not just affect one service. It can cascade across everything it was deployed to — and the team may not even know where all the instances are.
Most certificate-related outages I have seen are not due to malicious/lazy administrators. They happen because a certificate was tracked in a spreadsheet or an internal document, got buried in a long list, and either was missed entirely or was renewed in one place but not updated everywhere it was deployed. Adding headcount to a manual process does not eliminate that risk — it just means more people are working from the same incomplete picture.
The question to ask your team is not “do we have enough people?” It is “do we have full visibility of every certificate we own, and do we know everywhere each one is deployed?” If the honest answer is no, that is the gap to close first.
My own experience trying to automate this
I want to share something candidly, because I think it is more useful than giving advice I have not personally tested.
Netrust is not a large organisation. We are not a bank with a dedicated security operations team of fifty people. And even so, pushing for automation internally has not been straightforward. Automating anything requires people to change how they work — and change is uncomfortable, even when everyone agrees it is the right direction. There are internal inertias to work through, legacy processes to untangle, and moments where it feels easier to just keep doing things the old way.
I share this not to paint a bleak picture, but because I think leaders who are navigating this need to go in with realistic expectations. Automation is the right answer. Getting there requires someone at the top to hold the line on it — because the path of least resistance will always be to patch things manually and move on.
Interestingly, a recent review with my team surfaced something worth noting. It is actually the smaller, more nimble organisations that are showing the most eagerness to move on this. Perhaps because they have fewer legacy systems to untangle, or because the decision chain is shorter — but whatever the reason, they are not waiting. If anything, that should give the larger organisations pause.
If you are a CIO or CISO reading this, this is your initiative to champion — not to delegate and forget. The organisations that will handle the 2027 and 2029 milestones well are the ones where someone at the leadership level decided early that manual was not good enough.
What good looks like
The answer is not a product — it is a capability. The organisations that will navigate this well are the ones that have moved from reactive to systematic. Certificates should not be something your team scrambles to deal with. They should be something your infrastructure handles on its own, with your team only stepping in when something genuinely needs attention.
When I think about what that looks like in practice, I would ask four questions of any approach your team puts forward:
- Can we see every certificate we own, across every system, in one place — without someone having to compile a spreadsheet?
- Does renewal happen automatically, well before expiry — or does the process only start when someone notices a reminder?
- When a certificate is renewed, is it updated everywhere it is deployed — or just in the place someone remembered to check?
- If something looks anomalous or falls outside policy, does the team find out proactively — or after something breaks?
If the honest answer to any of those is “we are not sure” or “it depends on who is on duty” — that is where the conversation with your team needs to start. This is not just a technical decision. It is an operational resilience decision. The CIO or CISO who surfaces this to the board before something breaks is in a very different position from the one who has to explain an outage.
Signing off — for now
I have been speaking with peers across sectors — education, government, financial services — and the pattern is consistent. Most organisations know something is changing. Not many have sat down to work out what it actually means for their environment, their team, and their processes.
I am happy to share my own journey on this — the decisions we made, the pitfalls we hit, what I would do differently — over coffee or when we cross paths at industry gatherings. These are the conversations I find most useful, and I suspect others do too.
Till the next time we meet.
Eugene Lam is Deputy CEO of Netrust, Singapore’s only IMDA-accredited Certificate Authority and Asia’s first public CA. Netrust has been helping organisations manage PKI and digital certificates since 1997.
Reference: CA/Browser Forum Ballot SC-081v3 · cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/