Industry policy
Ballot SC-081: TLS certificates fall to 47 days by 2029
Ballot SC-081v3, adopted by the CA/Browser Forum on 11 April 2025, cuts the maximum lifetime of publicly trusted TLS certificates from 398 days to 47 days by March 2029. The Apple-proposed ballot also cuts domain validation reuse to 10 days. Each step applies to the issuance date, so certificates already in use are not shortened.
What happened
The ballot passed with no votes against. Voting ran from 4 to 11 April 2025: certificate issuers voted 25 in favour with 5 abstentions, and certificate consumers, the browser and operating system vendors, voted 4 to 0. The ballot amends the Baseline Requirements, the rulebook every publicly trusted certificate authority must follow.
The maximum validity period and the reuse period for domain control validation now depend on when a certificate is issued:
| Issued | Maximum validity | Domain validation reuse |
|---|---|---|
| Until 2026-03-14 | 398 days | 398 days |
| From 2026-03-15 | 200 days | 200 days |
| From 2027-03-15 | 100 days | 100 days |
| From 2029-03-15 | 47 days | 10 days |
Subject identity information validated for OV and EV certificates can still be reused for up to 398 days, so organisation checks do not have to be repeated every time a certificate is replaced. The 398-day ceiling that SC-081 replaces had applied since September 2020.
Who is affected
Every website, API or mail server on a publicly trusted certificate is affected. Teams that renew by hand once a year feel it first: from March 2026 a one-year purchase needs at least two certificates, and a 47-day maximum means at least eight issuances a year.
The shorter reuse period ends one-off domain checks. From 2029 a CA can rely only on a domain check that is at most 10 days old, so in practice every renewal needs a fresh HTTP-01 or DNS-01 challenge. DNS-based validation that depends on someone adding a TXT record by hand will not scale.
Users of ACME clients that already renew automatically, which covers most Let's Encrypt setups, mainly need to confirm that automation really runs everywhere, including load balancers, CDNs and appliances. Let's Encrypt's own move to 45-day certificates is covered in a separate report. Certificates from a private CA are out of scope.
What you should do
The deadline that matters most is the 100-day step on 2027-03-15 (upcoming).
- Inventory every public certificate and note how each one is renewed.
- Move manual renewals to ACME or your provider's automation before that date.
- Monitor expiry independently of the renewal system.
Check what a server currently serves:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -issuer -dates
Test that ACME renewal works without waiting for expiry:
sudo certbot renew --dry-run
Use the validity calculator to see the maximum lifetime for a given issuance date and the SSL checker to confirm what is deployed. The certificate validity timeline shows the full history, and the 47-day certificates guide covers automation in depth.
FAQ
Do certificates I already have stop working when a new limit starts?
No. Each limit applies to the date a certificate is issued. A 398-day certificate issued before 2026-03-15 stays valid until its original expiry date; only its replacement is capped at the new maximum.
Does SC-081 apply to private or internal certificates?
No. The Baseline Requirements govern publicly trusted TLS certificates. Certificates from a private CA that only your own devices trust are outside their scope, although many organisations shorten internal lifetimes too.
How often will a certificate need replacing under the 47-day limit?
At least eight times a year. From 2029-03-15 a certificate is valid for at most 47 days, and a CA may reuse a domain validation for only 10 days, so each renewal also needs a fresh domain check.