← Blog

90-day SSL certificates are coming — here's what that actually means for you

March 25, 2026

By Nick Phillips, Founder

If you missed the news: in early 2025 Apple proposed — and the CA/Browser Forum ratified — a phased reduction in the maximum lifetime of publicly-trusted TLS certificates. Today the limit is 398 days. By March 2029, it'll be 47 days. The 90-day step happens first.

The schedule, per the ratified ballot:

• March 2026: max 200 days
• March 2027: max 100 days (the "90-day" milestone everyone refers to)
• March 2029: max 47 days

If you're issuing certs today through Let's Encrypt, you're already on 90 days and nothing changes for you. If you're buying year-long DigiCert or Sectigo certs, you have at most three more renewal cycles in your current rhythm before the ceiling drops below where you're sitting.

Why this is happening

The official rationale is the one we covered in the expiration explainer: shorter lifetimes limit the damage from a compromised private key, force the ecosystem to roll forward on cryptographic primitives, and reduce the time bad information stays trusted.

The honest unofficial rationale is that revocation doesn't work. CRLs are huge, OCSP is slow and privacy-leaky, OCSP stapling helps but isn't universal, and browsers (Chrome especially) have moved toward "we trust the expiration date more than we trust the revocation infrastructure." When revocation can't be relied on, expiration has to do its job. The shorter the expiration, the smaller the window of compromise.

The browsers are also tired of "we don't automate cert renewal" as an explanation. The industry has had Let's Encrypt and ACME for over a decade. There is no remaining excuse for a 2026 deployment to require human intervention every 13 months. Forcing the lifetime down is the lever that forces the automation.

What actually breaks

If your renewal is already automated and tested, nothing breaks. You'll see a higher rate of renewal events (six a year instead of one) but no actual operator work per renewal.

If your renewal is manual — someone gets an email from DigiCert and clicks through a portal — the workload goes from 1× per year to 8× per year in 2027 and 12× per year in 2029. That isn't manageable. You will automate, or you will have repeated outages.

If your renewal is automated but you've never tested the failure path, you're going to find out which mode it fails in. Today, certbot fails silently and you have ~25 days of "warning" to notice from a typical 90-day cert. In a 47-day world, your warning window is more like 7–10 days, depending on when you check. That isn't enough margin for a silent failure to get caught by a quarterly review.

Specifically affected:

• Manual processes with year-long certs. Procurement and ITSM departments that file a ticket once a year to renew. The ticket cadence will eat them alive at 8×/year.
• Long-lived embedded devices. IoT, embedded hardware, anything that pins a CA bundle at manufacture time. They were already on borrowed time; 47-day churn at the CA level makes the chain-trust assumptions even more fragile.
• Static binaries with pinned chains. Mobile apps that pin a specific intermediate. If your pinned intermediate rotates more frequently (and it will), pinning becomes a recurring outage vector instead of a one-time hardening step.
• Government and regulated environments where the cert lifecycle is part of a compliance process that wasn't designed for "every six weeks." Expect noise.

What you should do right now

Three things, in order of impact:

1. Make sure renewal is fully automated. If a human has to do anything other than approve initial issuance, that's a future incident. Let's Encrypt + certbot, or acme.sh, or your CA's API. The point is that no part of the renewal process requires a human typing or clicking in the moment.

2. Make sure the renewal is verified from outside. Automated renewal is necessary; not sufficient. As the renewal-failures post catalogs, certbot can exit cleanly and still have done the wrong thing. The fix is external monitoring — something that reads the cert off the live handshake and tells you the actual notAfter date.

In a 90-day world, you can tolerate a renewal failing once and getting fixed manually. In a 47-day world, you can't. The margin for "we'll notice next week" closes.

3. Stop pinning certs in mobile and embedded clients. Pinning was a good idea in 2014. In 2026 it's a liability — intermediates rotate more often, and your "security feature" turns into a kill switch every time the chain changes underneath you. If you must pin, pin the public key (SPKI), not the cert; rotate the pinned keys ahead of cert rotations, not after.

What you probably don't need to do

A few things people sometimes ask about that aren't actually the priority:

• Switching CAs. The lifetime reduction is industry-wide, not Let's Encrypt-specific. Every public CA will be capped at the same numbers. Switching from DigiCert to Let's Encrypt because of this is fine if you want to do it for cost reasons; it doesn't change the lifetime calculus.
• Buying "long-life" certs while you still can. Some resellers are marketing this. The ratified ballot is a maximum, not a grandfathered limit — certs already issued today at 398 days will continue to be honored for their full term, but you can't stockpile them. The CA/Browser Forum rules apply at issuance time, not at validity time.
• Worrying about TLS 1.3 / cipher negotiation. The lifetime change has nothing to do with the protocol versions. Your TLS config is unaffected.

What this looks like operationally

If you have, say, 30 production domains, here's what your year looks like:

• At 398 days (today): ~30 renewal events per year, distributed unevenly because the certs were issued at different times. One operator can handle this manually with a calendar.
• At 100 days (2027): ~110 renewal events per year. Manual is no longer feasible. Automation is required, and at this volume, monitoring becomes a real component — you cannot eyeball a list of 110 events per year and notice "wait, this one didn't run."
• At 47 days (2029): ~230 renewal events per year. Almost every working day has at least one cert renewing somewhere. Even spotting an anomaly in the renewal log becomes infeasible without summarization.

The infrastructure that handles 30 manual events a year is a calendar. The infrastructure that handles 230 automated events a year is a small monitoring problem. That's the gap the next three years will close.

Why Otterwatch exists in this future

The argument for "have someone else watch your certs" only gets stronger as lifetimes shrink. When the renewal cadence is yearly, you can tolerate a lot of silent breakage. When the cadence is monthly, you can't.

We built Otterwatch specifically for the "external sanity check on automated renewal" problem. It's not a replacement for certbot; it's the smoke detector you put above the kitchen so that when the renewal cron quietly fails one Tuesday, you find out before your visitors do.

You can check any site right now with the free checker, no signup needed. Daily monitoring with email alerts at 30 days, 7 days, and on-expiry starts at the signup page — and in a 47-day world, that 30-day window is going to be the difference between "fixed it on a Wednesday" and "Slack is on fire at 2am."

The 90-day move is just the first step. Plan for the 47-day one now and you won't have to plan for anything ever again.