Ready to see the difference for yourself?
Apply for a free trial, and we'll walk you through Certiligent with your own certificate setup.
Many organisations still manage TLS certificate renewals through a combination of spreadsheets, calendar reminders, and institutional knowledge held by one or two individuals. For annual renewal cycles, that approach was fragile but survivable. At 47-day cycles, it is not.
In April 2025, the CA/Browser Forum passed Ballot SC-081v3 with 25 votes in favour and none against (5 abstentions). Every major browser vendor (Apple, Google, Mozilla, and Microsoft) voted in favour. The vote mandates a phased reduction of the maximum validity period for publicly trusted TLS certificates, culminating in a 47-day maximum by March 2029. The first milestone, a reduction to 200 days, took effect on 15 March 2026.
This isn't a rumour or a proposal still under discussion. It's done. The timeline is fixed. The question is whether your organisation is building toward it or still treating it as a future problem.
The reduction is driven by two structural problems with the current model.
Certificate revocation mechanisms are not sufficient as a standalone safety net.
Due to limitations such as OCSP soft-fail behaviour, browsers may accept certificates even when revocation status cannot be reliably verified.
As a result, long-lived certificates (e.g. 200 days) create a large window of exposure if a private key is compromised.
By reducing certificate validity to 47 days, this exposure window is significantly minimized, even without relying on revocation mechanisms.
The longer-term driver is the need to build the operational capability to rotate cryptographic material quickly. As quantum computing advances, current asymmetric algorithms (RSA, ECDSA) will eventually need to be replaced.
Organisations that have automated certificate lifecycle management will be able to transition to post-quantum cryptography (PQC) algorithms without a disruptive manual effort.
While the primary goal of the 47-day requirement is to reduce risk and improve security, it also supports this transition by driving the adoption of automation and increasing crypto agility - capabilities that will be essential when algorithm changes become mandatory.
The CA/B Forum deliberately defined a phased transition to give organisations time to adapt. These milestones apply to all publicly trusted CAs and are already in force.
Maximum 200 days (current)
A 50% reduction in certificate lifespan. Teams that were managing renewals annually now face approximately double the renewal volume. Manual processes start showing serious strain here.
Maximum 100 days
Renewal frequency increases to roughly four times the pre-2026 baseline.
Final: 47-day maximum
The final state. A maximum certificate validity of 47 days means approximately 7-8 renewals per certificate per year, compared to the roughly one renewal per year that applied before 2026.
At this stage, automation is no longer an option, it becomes a prerequisite.
Abstract timelines are easy to dismiss. The numbers are harder to ignore.
~ 100 renewals/yearfor 100 TLS certificates under the pre-2026 baseline
~8x more renewals per TLS certificate compared to pre-2026 baseline
~2 h average engineer time per manual renewal
Run that last one through:
For a team managing 100 TLS certificates, that translates into around 800 renewals per year. At ~2 hours per renewal, that is roughly 1600 engineering hours annually spent just on certificate renewal. That's not a workload. That's the equivalent of a full-time role dedicated to nothing else.
The math is simple: at 47-day cycles, manual certificate management doesn't scale. It simply stops working.
Organisations that adapt smoothly will be those that invested in automation early. The 200-day phase is already here, but the move to 100 days in March 2027 is where the pressure really starts to show, particularly for teams still relying on manual processes.
You can't automate what you can't see. Start by discovering every certificate across every environment. This includes public endpoints, internal services, load balancers, application servers, and network devices, including the ones nobody's touched in years. Certiligent’s discovery agent scans your infrastructure automatically and builds a centralised inventory with expiry timelines and ownership metadata, surfacing certificates that would otherwise stay hidden until they expire.
Automated renewal produces little benefit if certificate deployment remains manual. Deployment standardisation means ensuring that renewed certificates can be pushed to their targets through a consistent, automatable mechanism.
A dedicated platform handles the full renewal workflow: monitoring expiry dates, triggering renewal requests, managing CA interaction and deploying renewed certificates without manual intervention for routine operations. Certiligent covers this end-to-end: from certificate discovery and issuance through to renewal, revocation, and audit logging, across heterogeneous environments and multiple CAs, via a centralised administration portal. The 47-day cycle runs in the background without anyone needing to manage it.
Even with automation, you want full visibility. Centralised dashboards, proactive alerts for anything that needs human attention, and audit logs for compliance. These are the guardrails that let you trust the system is working.
If certificate management lives in one person's head, start codifying it now. Document processes, train the team, and make sure renewal knowledge is shared, not held. When that person goes on holiday in 2027, you don't want to find out the hard way.
Apply for a free trial, and we'll walk you through Certiligent with your own certificate setup.
The assumption that certificate automation is only relevant for organisations managing hundreds of certificates does not hold under 47-day cycles.
A SaaS platform managing TLS certificates for customer-facing subdomains, a financial services company operating a moderate number of APIs and web services under DORA, a DevOps team managing certificates across multiple Kubernetes clusters and environments, all of these feel the 47-day change. The absolute certificate count may be lower than a large enterprise, but the proportional impact on a team with no dedicated security operations capacity is often higher.
Teams that rely on manual processes and reactive monitoring will feel the impact of the 2027 milestone first. Starting the transition now, while still operating under the 200-day validity period, provides enough runway to implement and properly test automation before increased renewal frequency starts to make delays costly.
The phased timeline exists for a reason: to give organisations time to adapt. The risk is that "phased" gets interpreted as "we can wait." The first mandatory milestone, the 200-day cap, has already been in effect since March 2026. That means that this thing is already in motion.
Building an automated foundation takes time. It means time to standardise deployments, integrate the right tools and make sure everything works reliably before you depend on it.
Teams that start now will have this foundation in place well ahead of the next milestones. Teams that wait until 2027 will be building under pressure, with shorter validity periods making every delay more visible and harder to absorb.
From an operational perspective, 47-day certificates are not more complex than annual ones, the same process just runs more frequently.
The real challenge is building the foundation that can support that frequency. That is the work to focus on now.
Certiligent supports the full certificate lifecycle: discovery, issuance, renewal, revocation, audit logging across heterogeneous environments and multiple CAs, via a centralised administration portal and ACME v2-compatible server. For organisations preparing for the 2027 and 2029 milestones, contact the Certiligent team to discuss your current certificate estate and automation readiness.
