Certificate Validity Is Shrinking. Your Renewal Process Has to Keep Up.
On March 15, 2026, the CA/Browser Forum's 200-day maximum validity rule for public TLS certificates took effect. Any certificate issued on or after that date expires within 200 days, not 398. This is the first of three scheduled reductions: 100 days in March 2027, then 47 days in March 2029.
The teams that issued one-year certs in early March are now hitting their first renewal under the new cadence. The teams that issued certs after March 15 are about to find out what their renewal pipeline really looks like when it has to fire twice a year instead of once - and soon, four times a year, then eight.
The timeline you need to plan against
- March 15, 2026 - 200-day max for new certs. Already in effect.
- March 15, 2027 - 100-day max. Renewal cadence roughly doubles again.
- March 15, 2029 - 47-day max. Renewal cadence roughly doubles again.
Validation reuse periods are shrinking on the same schedule. Domain validation information you collected can be reused for 200 days as of March 2026, 100 days in March 2027, and just 10 days by March 2029. For OV and EV certificates, the Subject Identity Information reuse period dropped from 825 days to 398 days on March 15, 2026.
The combined effect: even with automated issuance, the validation cadence shortens too. The "set it and forget it for two years" pattern that worked for OV/EV certs is dead.
What this actually breaks
Three things, in roughly the order most teams hit them.
Manual renewal processes. If you had a calendar reminder for a once-a-year cert renewal, you now need that reminder twice a year, soon four times, soon eight. Manual processes that worked at a once-a-year cadence become operational debt at biweekly cadence.
Scattered ownership. When a cert renews twice a year, it's usually the same person doing it both times. When it renews eight times a year, it's whoever's on call that week. The handoff cost rises, and "who owns this cert" becomes a real question instead of a tribal-knowledge answer.
Audit windows. If your SOC 2 audit looks at "the last time each cert was renewed," and the audit window is now smaller than the cert lifetime, you have a different kind of evidence problem. Most audit programs were designed around annual cert lifecycles. Quarterly cert lifecycles need a different rhythm of evidence collection.
What automation actually requires
"Just automate it" is the advice everyone gives. The actual requirements are more involved than "deploy ACME."
- Discovery. You have to know which certs need renewing. Renewing the certs you know about is the easy part; the certs that aren't in your renewal automation are the ones that take you down. Continuous discovery, not annual audits.
- Issuance. ACME (Let's Encrypt, Sectigo, others) handles this for most cases. Commercial OV/EV certs still need portal-based validation flows; those don't disappear with shorter validity.
- Deployment. The cert was issued; was it deployed to every edge, every container, every load balancer that serves it? This is where most "renewal automation" pipelines actually fail.
- Verification. External probing that confirms the new cert is live and trusted from a customer's perspective. Internal state checks aren't enough - "the file on disk is the new cert" doesn't mean "the cert your customer's browser is receiving is the new cert."
- Alerting. If any of the above fails, someone needs to know quickly enough to fix it before the old cert expires. At 47-day validity with a 10-day issuance buffer, that window is tight.
All five of these have to work, every renewal cycle, across every certificate. At 200-day validity, a failure rate that was tolerable becomes operationally painful. At 47-day validity, the same failure rate becomes an outage-per-quarter problem.
Check your own certs
Scan a domain you care about and look at the "valid from" date on the leaf certificate. If it's after March 15, 2026, the cert is on the 200-day clock - so the next renewal is in roughly the next six months from issuance, not the next year. Worth knowing before your operations calendar tells you otherwise.
Renewal cadence just doubled. Yours doesn't have to suffer for it.
TLS Radar monitors expiry across every certificate in your inventory, alerts you on a multi-tier schedule (30/14/7/3/1 days), and surfaces the renewal-pipeline failures (deployment didn't sync, edge didn't pull, verification didn't fire) that turn 'we renewed it' into 'we thought we renewed it'. Built to scale from a handful of sites to enterprise portfolios with API integration, SAML/SSO, and pricing tailored to your certificate volume.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.