TLS certificates used to last two years. Then the CA/Browser Forum capped them at 13 months in 2020. As of March 15, 2026, the new maximum is 200 days. By 2029, it will be 47 days.
This isn't a gradual drift — it's a deliberate, scheduled reduction with clear industry deadlines. If you manage certificates manually, you're running out of time to change that.
The SC-081 Timeline
Ballot SC-081v3, approved by the CA/Browser Forum in April 2025, sets the following schedule for maximum TLS certificate validity:
| Effective Date | Maximum Certificate Lifetime |
|---|---|
| March 15, 2026 | 200 days |
| March 15, 2027 | 100 days |
| March 15, 2029 | 47 days |
Domain validation reuse periods follow the same schedule, dropping to just 10 days in 2029. That means re-validating domain ownership far more frequently, which is only practical with automation.
The March 2026 milestone has already passed. If you issued a certificate today from any public CA, its maximum validity is 200 days. AWS Certificate Manager has already updated to a 198-day maximum, with a 45-day renewal window.
Let's Encrypt Is Moving Even Faster
Let's Encrypt has announced its own accelerated timeline, independent of the SC-081 schedule:
| Date | Change |
|---|---|
| May 13, 2026 | Opt-in 45-day certificates available ("tlsserver" profile) |
| February 10, 2027 | Default profile switches to 64-day certificates |
| February 16, 2028 | Full transition to 45-day certificates |
The authorization reuse period also shrinks from 30 days to 7 hours in the final phase. At that point, domain validation happens essentially every renewal cycle.
Why Shorter?
The security case is straightforward. A shorter certificate lifetime limits the window of exposure when a certificate is misissued or a private key is compromised. With a 398-day certificate, a problem can persist undetected for over a year. With a 47-day certificate, the maximum exposure is seven weeks.
Shorter lifetimes also accelerate post-quantum cryptography adoption. As quantum-resistant algorithms are standardized, the industry needs the ability to rotate certificates quickly. Infrastructure locked into year-long certificates will be slow to migrate.
The third reason is simpler: if you're renewing frequently, you have to automate. Automation is more reliable than humans for routine operational tasks. The CA/Browser Forum is effectively mandating good practice by making manual management impractical.
What This Means Operationally
At 47 days, a certificate needs to be renewed roughly every 30-35 days to maintain a safety buffer. For a single server that's a minor nuisance. For an infrastructure with hundreds of endpoints, manual renewal is not a viable strategy.
The practical requirement is:
- Automation: an ACME client (certbot, acme.sh, Caddy's built-in client) or a managed service (AWS ACM, Google-managed certificates) handling renewals without manual intervention.
- Monitoring: alerting that catches failures before they expire, giving you time to intervene. As lifetimes shorten, the intervention window shrinks alongside them.
For a 90-day certificate, a 15-day expiration alert gives you a comfortable recovery window. For a 45-day certificate, that same alert gives you less than a week. You'll want to tune your thresholds as certificate lifetimes change.
See Certificate Monitoring and Let's Encrypt for a practical guide to pairing automation with monitoring and choosing the right alert threshold.
Generator Labs certificate monitoring tracks expiration dates across your infrastructure and alerts you at the threshold you configure, so you always have time to respond before a certificate causes an outage.