If you administer anything that terminates TLS, this is the infrastructure deadline worth putting in a calendar. It is not a proposal or a vendor recommendation: it passed the CA/Browser Forum ballot process in April 2025, which means every publicly trusted certificate authority is bound by it, and browsers enforce it whether or not your renewal process is ready.
The exact schedule
| Effective date | Max certificate lifetime | Max domain validation reuse |
|---|---|---|
| Before March 15, 2026 | 398 days | 398 days |
| March 15, 2026 (in force now) | 200 days | 200 days |
| March 15, 2027 | 100 days | 100 days |
| March 15, 2029 | 47 days | 10 days |
Two columns matter, and the second one catches people out. Domain validation reuse is how long a CA may rely on a previous proof that you control the domain before making you prove it again. Today that proof lasts most of a year. By 2029 it lasts ten days, which means the validation step itself has to be automated, not just the issuance step. A workflow where someone manually adds a DNS TXT record to pass validation is on the same clock as everything else.
Why 47 days, specifically
The number looks arbitrary and is not. It is built to fit a monthly renewal cadence with slack: roughly one month (31 days), plus a renewal window of about a third of the lifetime, plus a few days of margin. A certificate renewed monthly with a two-week grace period never comes close to expiring, and 47 days is the smallest ceiling that comfortably permits that pattern.
The deeper reason is that certificate revocation does not work. When a private key is compromised, the theory says you revoke the certificate and browsers stop trusting it. In practice, CRLs are large and stale, OCSP checks were soft-failed by browsers for performance and privacy reasons (and OCSP is now being phased out entirely), and a meaningful share of clients never check revocation at all. If you cannot reliably untrust a certificate, the only remaining lever is making sure it expires soon on its own. Lifetime is the revocation mechanism.
What actually breaks
Automated web infrastructure mostly shrugs at this. The breakage concentrates in specific places:
- Network appliances and management interfaces. Load balancers, firewalls, hypervisors, storage controllers and IPMI boards frequently have no ACME client and expect a human to paste a certificate into a web form. At eight renewals a year across a rack of them, this stops being viable.
- Anything with a pinned certificate. Mobile apps, B2B integrations and payment terminals that pin a leaf certificate need a coordinated release every 47 days. Pin to a CA or an intermediate, or stop pinning.
- Internal PKI habits applied to public certs. Private CAs are not bound by these rules and can still issue long-lived certificates. Teams that treat both the same way get surprised on the public side.
- Certificates on things that are hard to reach. IoT fleets, embedded devices, air-gapped-ish systems and anything whose update path involves a site visit.
- Manual approval gates. Change management processes that require a ticket and a sign-off per certificate do not survive an eightfold increase in renewals.
What to do, in order
- Inventory every certificate you serve, including the ones you forgot. Not the ones on your list: the ones actually answering on the internet. Certificate transparency logs record every publicly issued certificate for your domains, which is how you find the hostnames missing from the spreadsheet.
- Automate issuance with ACME everywhere it is possible. Let's Encrypt, ZeroSSL and most commercial CAs support it; Caddy, Traefik, nginx with certbot, and every major cloud load balancer handle renewal without human involvement. Prefer DNS-01 validation, since it works for internal hosts and wildcards and does not require port 80 reachability.
- Automate the validation, not just the renewal. With ten-day reuse in 2029, DNS-01 means your ACME client needs API credentials for your DNS provider. Sort that out well before it is urgent.
- List the appliances that cannot do ACME and decide now: replace them, put them behind a reverse proxy that terminates TLS, or accept a manual process you will run every six weeks forever.
- Monitor from outside regardless. Automation fails silently, and a renewed certificate that never got deployed to a CDN edge looks fine from the inside. External checks per hostname with escalating alerts are the backstop. That is the monitoring setup worth having in place before 2027.
The part that is genuinely good news
Shorter lifetimes force a property worth having on its own terms: if renewal is fully automated, certificate expiry stops being a category of outage. Teams that finish this migration early tend to report that the 2027 step passes without anyone noticing, which is the point. The teams that struggle are the ones who treat each deadline as a one-time scramble rather than as a prompt to remove the human from the loop.
Frequently asked questions
Why are TLS certificates going to 47 days?
Because certificate revocation is unreliable. CRLs go stale, browsers soft-fail OCSP checks (and OCSP is being retired), and many clients never check revocation at all, so a compromised certificate can stay trusted until it expires. Shortening the maximum lifetime is the only mechanism that dependably limits that window, and it also forces the automation that prevents expiry outages.
How long is an SSL certificate valid for in 2026?
A maximum of 200 days for certificates issued on or after March 15, 2026. Many are already shorter in practice: Let's Encrypt issues 90-day certificates and renews them automatically. The maximum drops to 100 days in March 2027 and 47 days in March 2029.
Does this apply to internal or private CA certificates?
No. The CA/Browser Forum baseline requirements govern publicly trusted certificates, so a private CA you run for internal services can still issue certificates with long lifetimes. Be careful not to let internal habits set expectations for public certificates, since only the public ones are on this schedule.
What happens if my certificate is longer than the new maximum?
Certificates issued before a deadline stay valid for their original lifetime; the limits apply at issuance. So a 398-day certificate issued in early March 2026 remains trusted until it expires. You cannot get a new one longer than the current ceiling, which is what compresses renewal cadence over time.