Your Clients’ Certificates Now Expire Twice a Year, and 100 Days Is Coming

Tom Schlick · 5 min read
Certificates MSP
Your Clients’ Certificates Now Expire Twice a Year, and 100 Days Is Coming

In March 2026, the maximum lifetime of a public TLS certificate dropped from 398 days to 200. That was only the first step. In March 2027 the ceiling falls to 100 days, and in 2029 it drops again to 47.

If you’re an MSP managing certificates across dozens of client domains, the renewal process you built around “once a year, roughly” is already out of date. Here’s what changed, why the 2027 deadline is the one that breaks manual tracking, and what to put in place before it arrives.

The Timeline Nobody Can Opt Out Of

In April 2025, the CA/Browser Forum passed ballot SC-081v3 with support from every major browser root program. It sets a fixed schedule for shrinking certificate lifetimes:

Effective date

Maximum certificate lifetime

Domain validation reuse

Before March 15, 2026

398 days

398 days

March 15, 2026

200 days

200 days

March 15, 2027

100 days

100 days

March 15, 2029

47 days

10 days

There is no opting out. A certificate authority that issues longer-lived certificates gets distrusted by browsers, so every publicly trusted certificate (DV, OV, and EV alike) follows this schedule.

Look at the last column too. By 2029, domain control validation can only be reused for 10 days. At that point the validation step itself has to be automated, not just the renewal. The industry has decided that certificate management is a machine’s job now.

The Math That Breaks Manual Tracking

Say you manage 40 clients averaging 25 certificates each: web, mail, APIs, client portals, the odd legacy appliance. That’s 1,000 certificates.

Under 398-day lifetimes, that meant roughly 1,000 renewals a year. A spreadsheet, some calendar reminders, and one conscientious engineer could keep up. Barely.

Under 200-day lifetimes, where we are today, it’s about 2,000 renewals a year. Six or seven every business day. The spreadsheet is stale by the time anyone reviews it.

Under 100-day lifetimes it’s roughly 4,000 renewals a year. And since nobody renews on the last day, the practical cadence works out to every 60 to 70 days per certificate. That’s sixteen renewals every business day across your client base.

Somewhere between 200 and 100 days, tracking expirations in a sheet stops being a process and starts generating incidents. For an MSP, an expired certificate is not a minor annoyance. It’s a browser warning on a client’s storefront, an SLA conversation, and a “what exactly are we paying you for?” email.

Why “Just Automate Renewals” Isn’t the Whole Answer

The standard advice is correct: automate issuance with ACME wherever you can. Let’s Encrypt users have lived comfortably with 90-day certificates for a decade because renewal is automated.

But automation moves the risk rather than eliminating it. Automated renewals fail silently all the time:

CAA record change blocks issuance. Someone tightens DNS on a client zone and the CA can no longer issue. Nothing alerts you. The renewal just doesn’t happen.

DNS validation breaks. The _acme-challenge delegation gets cleaned up by a well-meaning admin, or a provider migration drops the record. The renewal job errors into a log nobody reads.

The renewal runs, but not where you think. A load balancer or CDN renews its own certificate while an origin server keeps serving the old one.

The replacement comes from the wrong place. A certificate for a client domain suddenly issued by a CA you’ve never used is either a misconfiguration or something much worse. Either way you want to know before it goes live.

At a once-a-year cadence, a human eventually catches these. At a 60-day cadence across 1,000 certificates, the only thing standing between a silent renewal failure and a public outage is monitoring that confirms the renewal actually happened.

What to Do Before March 2027

You have until March 15, 2027 before the 100-day limit lands. That’s enough time to do this properly:

  •  Build a complete certificate inventory. Every client domain and subdomain that serves TLS. If you monitor DNS zones already, you’re most of the way there, since certificates live where records point.

  •  Automate issuance everywhere you can. ACME support is table stakes for hosting platforms, load balancers, and CDNs at this point. Flag anything that still needs a manual CSR (appliances, legacy systems) as your highest-risk items.

  •  Audit CAA records across all client zones. Make sure they permit the CAs your automation actually uses, and monitor them for changes so a DNS edit can’t silently block renewals.

  •  Monitor for replacement issuance, not just expiration. An expiry-date alert tells you a deadline exists. What you actually need to know is whether the replacement certificate has been issued yet, and whether it came from the expected issuer.

  •  Route alerts per client. At 100-day lifetimes, certificate events happen daily. If they all land in one inbox, they’ll be ignored by April.

Where ZoneWatcher Fits

We built TLS/SSL certificate monitoring for exactly this cadence. ZoneWatcher watches Certificate Transparency logs for every domain you monitor and does the one thing an expiry countdown can’t: it verifies that a replacement certificate has actually been issued.

Alerts only when action is needed. You get escalating notifications at 7, 5, 2, and 1 days before expiration. If the replacement has already been issued by the same issuer, those alerts are suppressed. Once each certificate renews two (soon four) times a year, that suppression is what keeps the alert channel from getting muted.

Replacement verification catches silent failures. If your ACME automation broke three weeks ago, the missing replacement triggers the alert well before the expiry date turns it into an outage.

Issuer changes stand out. A renewal from an unexpected CA gets surfaced instead of blending into the noise. That matters when a “renewal” might actually be a hijack.

It’s already organized by client. Certificate status lives alongside DNS monitoring for each client’s zones, with per-client notification routing. When something needs attention at 2am, you know whose it is.

The 200-day era has already started. The 100-day era is a few months away, and 47 days is on the calendar. MSPs that turn certificate renewal into a monitored, automated pipeline now will find March 2027 completely uneventful. That’s the goal.

Start monitoring your clients’ certificates with ZoneWatcher

Ready to protect your DNS?

Start your free trial today and get full access to all monitoring features.