On March 15, 2026 the CA/Browser Forum's Ballot SC-081 took effect. Any TLS server certificate issued by a public certificate authority after that date cannot exceed 200 days of validity. The old 398-day maximum is gone, and the 90-day floor for short-lived certificates remains unchanged. If you run SSL certificate expiry monitoring, or just manage renewals manually, this is the biggest practical change to certificate lifecycles since the move from three years to two in 2018 and from two years to one in 2020.
The shift is gradual, not a cliff
Certificates issued before March 15, 2026 still honor their original 398-day lifetime. Only newly issued certificates are constrained. Through the rest of 2026 you will see a mix. Older 398-day certs sit alongside new 200-day certs, both renewable on their own clocks. By mid-2027 the long tail will have aged out and nearly every public certificate in the wild will be on a 200-day or shorter cadence.
That is the steady state the CA/B Forum is steering toward. Fewer days of exposure if a private key leaks, and more frequent re-issuance to keep pace with cryptographic agility.
What it means for the way you monitor SSL certificates
- Your alert window matters more. With 200 days of validity the comfortable safe buffer shrinks. A 30-day pre-expiry alert used to fire when 7.5 percent of a certificate's life remained. On a 200-day certificate it now fires at 15 percent. That is still workable, but it is no longer generous. The teams that handle the transition cleanly bump their first reminder from 30 days to 45 days and tighten the gap between reminders so a single missed alert does not put renewal close enough to zero-day to be a fire drill.
- The 90-day floor has not moved. Let's Encrypt and other ACME-based CAs still default to 90-day certificates, and their internal default of 60-day lifetimes for shorter options is unchanged. The 200-day maximum only affects traditional Organization Validation and Extended Validation certificates from commercial CAs. Most teams that already used Let's Encrypt will not see any change in the certificates they get. Only the underlying allowed maximum has shifted.
- Certificate Transparency log volume is going up. Every renewal is a new entry in CT logs, and shorter lifetimes mean more renewals per host per year. The crt.sh-style lookup that public check pages rely on, the OCSP responders, and your CA's own revocation infrastructure all see roughly twice as many events. None of this breaks, but monitoring services that pull from CT logs will see higher latency under load as a side effect. Worth a heads-up if you operate one.
- Renewal automation is no longer optional. A 200-day validity with a 30-day pre-expiry alert gives you roughly 170 days of margin for renewal. That is enough if your certificate management workflow is automated end-to-end. ACME for Let's Encrypt, an API-driven CA for commercial certificates, cert-manager in Kubernetes, or a properly configured Ansible or Terraform pipeline for traditional hosts. It is not enough if a human has to remember to do it. The 398-day certificate forgave the occasional "we forgot, expired in production" outage. The 200-day certificate does not.
- Watch for double-renewal bugs. CAs commonly reissue a certificate in the final 30 days of its life to smooth customer transitions. With shorter lifetimes, the overlapping window for both old and new certificates being live at the same time is now shorter but more frequent. Make sure your monitoring tool deduplicates by issuer and serial rather than by hostname, or you will see phantom duplicate-cert alerts every time someone renews.
Who actually needs to care
If you already run SSL certificate expiry alerts at the standard 30, 15, 7, 1, and 0 day cadence, the move to 200 days is mostly a non-event for you. The 90-day-floor certificates you have been using do not change at all, and the longer certificates that do change have plenty of headroom under existing alert windows. The transition mostly bites teams that were running manual renewals against 398-day certificates and happened to be relying on the long lifetime as a backstop.
Why the Forum is doing this
The CA/B Forum's stated goal with Ballot SC-081 is to accelerate the move to automated, short-lived certificates in line with practices that major certificate authorities have already adopted. The 200-day step is the bridge between the 398-day world most operators got comfortable with and the eventual 90-day-everywhere model that automation makes routine.
Plan for it the same way you planned for the 3-year to 2-year and 2-year to 1-year transitions. Shorter lifetime, tighter alerts, automation first, manual processes only for the exceptions.