47-Day Certificates: The CA/Browser Roadmap to 2029
The CA/Browser Forum is cutting maximum TLS lifetimes to 47 days in stages. What the 200-, 100- and 47-day steps mean for discovery, renewal automation and operations teams.
The debate is settled, and part of the outcome is already operational reality: since 15 March 2026, publicly trusted TLS certificates may be valid for at most 200 days, down from 398. That is the first step in a roadmap the CA/Browser Forum adopted in April 2025 with Ballot SC-081v3: unanimously, with 29 votes in favour and none against. At the end of that roadmap sits a maximum lifetime of 47 days.
If you still order certificates by hand and track them in a calendar, treat the next three years as a rebuild project, not a series of individual appointments.
The roadmap in numbers
Maximum validity drops in clearly dated steps:
- until 14 March 2026: 398 days (the previous standard)
- from 15 March 2026: 200 days (in effect today)
- from 15 March 2027: 100 days
- from 15 March 2029: 47 days
In parallel, and this is the operationally harder part, the reuse window for Domain Control Validation (DCV) shrinks. Once you have proven control over a domain, that proof may be “reused” for a much shorter period before it must be re-established:
- from 15 March 2026: 200 days
- from 15 March 2027: 100 days
- from 15 March 2029: 10 days
For OV and EV certificates, the reuse period for vetted organisation data (Subject Identity Information) additionally falls from 825 to 398 days on 15 March 2026.
So the 47 days are only the headline. The 10-day DCV reuse from 2029 is the real metronome: from then on, you effectively have to re-prove control of your domain every ten days.
Why the reduction is happening
The reasoning is straightforward. A certificate is a trust statement with an expiry date. The longer it is valid, the longer a mis-issuance, a compromised key or an outdated cryptographic parameter keeps having effect. The classic countermeasure, revocation via CRL and OCSP, works unreliably in practice: revocation lists are not evaluated promptly everywhere, and OCSP is increasingly being deprecated. Short lifetimes replace revocation with expiry. A problem heals itself because the affected certificate will soon be invalid anyway.
The second driver is crypto-agility. If you renew certificates regularly, you can change algorithms, key lengths and profiles in ongoing operation, a precondition for the upcoming migration to post-quantum methods. Long lifetimes, by contrast, cement the status quo.
What this means for operations
The central consequence is mundane and unavoidable: manual renewal no longer scales. A 47-day certificate, with a sensible buffer, gets replaced roughly every 30 days. Across a mid-sized estate, that is no longer a calendar entry but a process that has to run without human intervention.
Three capabilities decide whether this rebuild succeeds:
Automation. ACME (RFC 8555) is the established standard for automatic issuance and renewal, not only for Let’s Encrypt, but increasingly for commercial and internal CAs too. Where ACME does not reach, you need API-driven renewal workflows with approval, so that compliance controls remain intact.
Discovery. You can only automate what you know about. The typical outage in 2029 will not be the well-maintained certificate on the main system, but the forgotten one on a load-balancer endpoint, an appliance or in a cloud account nobody is watching any more. Active network scans and passive cloud discovery are what keep short lifetimes from turning into short-notice outages.
Ownership. Every certificate needs a clearly assigned owner, a known CA and a defined renewal procedure. An inventory that carries those three facts per certificate is the real insurance against the 47-day reality.
This pattern (discovery first, then CA-agnostic automation with approval) is exactly what underpins our NextPKI module. The regulatory direction is independent of any tool: whoever makes the estate visible and automates renewal is prepared, regardless of which instrument they use.
What makes sense now
Three years sounds like plenty of time, but the 200-day step is already running. Concretely, it is worth doing now: a complete inventory of all TLS certificates across network, cloud and endpoints; identifying every place that still renews by hand today; a pilot of ACME-based auto-renewal on non-critical services; and clarifying which internal systems can technically sustain ten-day domain re-validation at all by 2029.
The 47 days are not arriving by surprise, and not all at once. They arrive in steps, and the first one is already here.