SSL certificates are moving to 47-day lifetimes: what agencies must do
By the RenewRoster team · · 8 min read
For years, an SSL certificate was something you renewed once a year. That's already over. Certificates issued since 15 March 2026 can be valid for at most 200 days, and by 2029 the maximum will be just 47 days. If your agency installs or manages certificates for clients, the number of renewals you handle is about to multiply.
Here's exactly what changed, where the dates come from, and a practical plan for agencies.
What was decided, and by whom
The rules for publicly trusted TLS certificates are set by the CA/Browser Forum, a body made up of certificate authorities and browser makers. In April 2025 its Server Certificate Working Group passed Ballot SC-081v3, "Introduce Schedule of Reducing Validity and Data Reuse Periods". It amended the Baseline Requirements, which every public CA must follow, with a phased schedule.
The schedule
| Certificate issued | Maximum validity | Max reuse of domain validation |
|---|---|---|
| Before 15 March 2026 | 398 days | 398 days |
| 15 March 2026 to 14 March 2027 | 200 days | 200 days |
| 15 March 2027 to 14 March 2029 | 100 days | 100 days |
| From 15 March 2029 | 47 days | 10 days |
Two details matter for agencies:
- It applies by issue date. A certificate issued on 14 March 2026 could still last 398 days, so you'll see a mix of lifetimes for a while. From the first phase on, anything newly issued is capped.
- Domain validation is reused for less time too. Today a CA can rely on a domain-control check for a while before asking again. From 2029 that drops to 10 days, so in practice every renewal will need a fresh domain-control check. Validation of organisation details for OV and EV certificates can be reused for up to 398 days.
We're now in the 200-day phase. A certificate you bought and installed by hand in, say, May 2026 expires around November 2026, not May 2027.
Why the industry is doing this
Shorter lifetimes limit how long a mis-issued or compromised certificate stays useful, and make sure certificates reflect current domain ownership. They also push everyone towards automation, which makes it possible to replace certificates quickly when something like a CA distrust event happens. Browser makers had been signalling this direction for years; SC-081v3 gave it fixed dates.
What already works without changes
If a site's certificate is issued and renewed automatically, through ACME with Let's Encrypt, ZeroSSL or Google Trust Services, or by a managed platform or CDN that handles certificates for you, you're mostly fine. Let's Encrypt certificates have been 90 days from the start, and ACME clients normally renew when about a third of the lifetime is left.
"Mostly", because automated renewal fails more often than people expect: a DNS change breaks the HTTP-01 challenge, an API token for DNS-01 validation is revoked, a server migration leaves the cron job behind, or a CAA record blocks the CA. With shorter lifetimes there's less slack to notice before a certificate actually expires.
What breaks
- Manually installed certificates. OV/EV or paid DV certificates bought from a reseller and pasted into cPanel, Plesk or IIS. These will need replacing roughly twice a year now, about four times a year from 2027 and roughly eight or more times a year from 2029.
- Devices and appliances such as load balancers, firewalls and some hosting setups that don't support ACME.
- Mail and non-web services on ports 465, 993 and 995 that someone set up once and forgot.
- Multi-year "certificate subscriptions", which still exist commercially but now mean several reissues and reinstalls during the term.
- Anything that depends on one person remembering a calendar entry.
The agency action plan
1. Inventory every certificate, not just every site
List each hostname for every client: apex, www, shop, mail, API, staging, client portals. Then check what each one actually serves. The free domain + SSL checker shows the served certificate's expiry and issuer, and the bulk version handles 10 at a time. Certificate Transparency logs (for example crt.sh) can reveal hostnames you'd forgotten, because every public certificate is logged.
2. Classify each one: automated or manual
Tag each certificate "ACME", "platform-managed" or "manual". The manual list is your risk list.
3. Move manual certificates to automation
For most client sites, a free ACME certificate or the host's or CDN's built-in certificate is fine. Where a client insists on OV/EV, ask the CA about ACME support; many commercial CAs now offer ACME with pre-validated organisation details.
4. Monitor the served certificate, independently
Automation needs a second pair of eyes. Monitor every hostname from outside and alert well before expiry: 30, 14 and 3 days is a sensible ladder now, though under 47-day lifetimes you'll want to treat "less than about 15 days left" as a signal that automatic renewal has failed.
5. Update your contracts and pricing
If you charge per certificate installation, a 47-day world changes the economics. Fold certificate management into a maintenance plan, or move clients to automated certificates and stop selling manual installs.
6. Budget the timeline
- Now (200-day phase): finish the inventory and automate the easy wins.
- Before March 2027 (100 days): no manual certificates left on routine client sites.
- Before March 2029 (47 days): every certificate automated and independently monitored, with domain validation that can be repeated automatically (for example DNS-01 with scoped API tokens).
Frequently asked questions
Does this affect certificates I already have?
No. Existing certificates keep their original expiry. The limits apply to certificates issued on or after each date.
Does it apply to internal or private certificates?
No. The Baseline Requirements cover publicly trusted TLS certificates. Private CAs set their own rules.
Could the dates change?
The schedule is in the Baseline Requirements now. The Forum can amend it with a new ballot, so check the current Baseline Requirements if you're reading this much later.
For a shorter overview, see our guide on 47-day SSL certificates for agencies.
A worked example
Take a typical small agency with 40 client sites. Say 30 use their host's automatic certificates, 6 have paid certificates installed by hand on shared hosting, and 4 have certificates on mail servers or a client's own hardware. Under one-year certificates that's about 10 manual renewals a year. In the 200-day phase it's roughly 18. At 100 days it becomes about 36, and at 47 days, around 78 manual renewals a year, each with a fresh domain-control check. That's more than one a week, before counting any automated renewal that fails. The numbers make the case for automating the ten manual certificates now rather than later.
Know before any client certificate expires
RenewRoster tracks every client's domain and SSL expiry dates, sends reminders at 60, 30, 14 and 3 days (under your agency's brand if you like) and gives you a monthly renewals report. Free for 5 domains, no card needed.
Sources
- CA/Browser Forum: Ballot SC081v3, Introduce Schedule of Reducing Validity and Data Reuse Periods
- CA/Browser Forum: Latest Baseline Requirements
- CA/Browser Forum Server Certificate WG: SC-081v3 vote result (passed April 2025)
- Let's Encrypt: Integration guide (renewal timing and ACME)