398-day certs
~1renewal a year
Easy to do by hand. Easy to forget, too.
Resources / Guide
The 47-day certificate guide
Public TLS certificates used to last over a year. By 2029, the maximum will be 47 days. Here’s what’s changing, when each step lands, and how to get ready without losing sleep.
Updated 21 Oct 20268 min read
the short version
- 01Public TLS certificate lifetimes shrink in three steps: 200 days (March 2026), 100 days (March 2027), 47 days (March 2029).
- 02Domain-control validation data can be reused for less time too, down to 10 days from March 2029.
- 03Certificates already issued keep their validity. Each maximum applies to certificates issued from its effective date.
- 04Automate issuance and deployment, and monitor for renewals that fail silently.
What’s changing
A rule agreed by the people who make browsers and certificates
The CA/Browser Forum is where certificate authorities and browser makers agree rules for publicly trusted certificates. In April 2025 it passed Ballot SC-081v3, which updates the Baseline Requirements to shorten certificate lifetimes between 2026 and 2029.
The ballot passed with 25 certificate-authority votes in favor, five abstentions, and all four browser-maker votes in favor. No member voted against it.
It covers publicly trusted TLS server certificates: DV, OV and EV certificates used by websites and APIs. Private-CA, S/MIME email and code-signing certificates are outside this ballot.
The schedule
Three steps, one every year or two
Each limit applies to certificates issued on or after its effective date. The first step is already in effect; the next one begins 15 March 2027.
before 15 Mar 2026the old rule
398 d
15 Mar 2026in effect now
← we’re here
200 d
15 Mar 2027next step
145 days away (from 21 Oct 2026)
100 d
15 Mar 2029final step
47 d
It’s not only the lifetime that shrinks
Before issuing, a CA checks that you control the domain and, for OV/EV certificates, verifies organisation information. Those checks can be reused for a limited period, which also gets shorter.
| Issued on or after | Max certificate lifetime | Domain validation reuse | Organisation info reuse (OV/EV) |
|---|---|---|---|
| Before 15 Mar 2026 | 398 days | 398 days | 825 days |
| 15 Mar 2026 | 200 days | 200 days | 398 days |
| 15 Mar 2027 | 100 days | 100 days | 398 days |
| 15 Mar 2029 | 47 days | 10 days | 398 days |
Individual CAs may apply stricter limits. The rule sets maximums, not a promise that every CA will issue certificates up to those limits.
What it means in practice
More renewals than you’d guess
The minimum comes from dividing a year by the certificate lifetime. Renewing at about two-thirds of the lifetime leaves time to recover from a failure, so plan around that safer rhythm.
200-day certs · now
~3renewals a year
At least 2, about 3 with a safe buffer.
100-day certs · 2027
~6renewals a year
At least 4, about 6 with a safe buffer.
47-day certs · 2029
~12renewals a year
At least 8. Monthly renewal is a realistic rhythm per certificate.
Domain checks at nearly every renewal
With 10-day reuse, the CA will ask you to prove domain control again almost every time. That means automated DNS or HTTP challenges, not someone clicking an email link.
Old certificates don’t disappear overnight
A 398-day certificate issued on 14 March 2026 can remain valid into April 2027. For a while, your inventory will contain certificates issued under different lifetime limits.
Why it’s happening
A certificate is a snapshot, and snapshots go stale
1
The facts behind it change. Domains get sold, companies reorganise, servers move. The longer a certificate lives, the more likely it describes something that is no longer true.
2
Revocation has limits at scale. Shorter lifetimes reduce how long a misissued or compromised certificate can remain valid.
3
Cryptography keeps changing. Shorter lifetimes make it easier for the Web PKI to respond when algorithms or trust assumptions need to change.
If you use Let’s Encrypt
It’s moving faster than the rules
Let’s Encrypt is shortening its default lifetimes ahead of the 2029 industry deadline. The changes apply to new certificates at the next renewal after each date; valid certificates won’t be revoked as part of the change.
If renewal timing is hard-coded, it may stop working. Use a client that supports ACME Renewal Information (ARI), or renew at roughly two-thirds of the current certificate lifetime.
Read Let’s Encrypt’s latest announcement →- Until 9 Feb 202790-day certificates by defaultAuthorisations reused for 30 days
- Since 13 May 202645-day certificates, opt-inFor early adopters and testing
- 10 Feb 202764-day certificates by defaultAuthorisations reused for 10 days
- 16 Feb 202845-day certificates by defaultAuthorisations reused for 7 hours
Get ready
A checklist for the next 145 days
Find every certificate you own
Including the forgotten ones. Certificate Transparency logs list publicly issued certificates for your domains.
Automate issuance with ACME
Most major certificate authorities and clients such as Certbot, acme.sh and cert-manager support automated issuance.
Automate deployment and reloads
A renewed certificate sitting on disk is not enough. Load balancers, CDNs and appliances need the new certificate too.
Stop hard-coding renewal dates
Search cron jobs and runbooks for fixed day counts. Renew at about two-thirds of the lifetime, or use ARI.
Automate domain validation
Use DNS-01 or HTTP-01 challenges. Wildcard certificates require DNS-01 validation.
Watch from the outside
Automation can fail quietly. Check what each host actually serves and alert when a renewed certificate was not deployed.
Make certificate checks part of your routine
Check what each host actually serves, and catch certificates that were renewed but never deployed.
Sources
- CA/Browser Forum · Ballot SC-081v3 and voting results
- Let’s Encrypt · Decreasing certificate lifetimes to 45 days
- Let’s Encrypt · 64-day certificate lifetimes coming February 2027
This guide summarises public announcements. Certificate authorities may set stricter limits; check with your CA for its current policy.