47-day certificates: what changes, and when
The longest a publicly trusted TLS certificate may last is falling from 398 days to 200 days on 15 March 2026, 100 days on 15 March 2027 and 47 days on 15 March 2029. Domain validation can be reused for only 10 days by then, so renewal has to be fully automated.
Checked against the sources on 27 October 2026.
The schedule
The CA/Browser Forum — the certificate authorities and the browser makers that decide which certificates browsers trust — approved ballot SC-081 on 11 April 2025, with every browser vendor voting yes. It changes the Baseline Requirements in three steps:
| Certificates issued from | Maximum validity | Domain validation reusable for |
|---|---|---|
| Before 15 March 2026 | 398 days | 398 days |
| 15 March 2026 | 200 days | 200 days |
| 15 March 2027 | 100 days | 100 days |
| 15 March 2029 | 47 days | 10 days |
Validated company details (the subject identity information in OV and EV certificates) can be reused for 398 days from 15 March 2026, down from 825. A certificate issued before a deadline keeps the lifetime it was issued with; each limit applies to certificates issued on or after its date.
What it means in practice
- Renewal becomes routine. Renewed with a safe margin, a 47-day certificate is replaced about every month — a dozen times a year, for every certificate you have.
- Domain control is checked almost every time. With validation reusable for only 10 days, proving you control the domain becomes part of nearly every renewal, so it has to be automated too (for example ACME with DNS or HTTP challenges).
- Manual steps break. A ticket, an approval or an engineer copying a file onto a server once a year is tolerable. Twelve times a year, across hundreds of certificates, it is an outage waiting to happen.
What it does not cover
SC-081 governs publicly trusted TLS server certificates — the ones browsers check. Certificates from your own private CA, for internal services, devices and mutual TLS, are outside it. Many teams are shortening those too, for the same reason the browsers did: a short-lived certificate limits the damage of a stolen key, and an estate that renews automatically is one that can change algorithms when it needs to.
How to prepare
- Find every certificate — on servers, load balancers, appliances and devices — with its owner and expiry date. The ones nobody knew about are the ones that expire.
- Automate issuance and renewal end to end: ACME for public certificates, EST, SCEP or ACME for internal ones.
- Automate domain validation so the 10-day reuse window never blocks a renewal.
- Make sure services pick up a new certificate without a restart or a change window.
- Alert on renewals that fail, not just on certificates that are about to expire.
Why this matters for post-quantum
The automation that keeps up with 47-day certificates is the same machinery that will move certificates to post-quantum algorithms. An estate that can reissue every certificate in a month can change what those certificates are signed with in a month. See a post-quantum migration roadmap.