Your TLS certificates will only last 47 days soon. Most teams have not done the math

Luke Thomas — Fri, 12 Jun 2026 10:51:36 +0000

In April 2025 the CA/Browser Forum voted 25 to 0 to shrink the maximum lifetime of public TLS certificates. Not by a little. The ballot is called SC-081v3 and this is the schedule it locked in:

Effective	Max validity	Roughly
Today	398 days	13 months
March 2026	200 days	6.5 months
March 2027	100 days	3.3 months
March 2029	47 days	1.5 months

I run a small network monitoring product and I keep having the same conversation about this. Someone tells me "we renew certs once a year, we are fine." Then I show them the renewal math and the room goes quiet.

The math nobody is doing

Picture a mid-size company with 600 public TLS certs. Websites, APIs, load balancers, CDN configs, VPN portals, the usual sprawl. Today that means roughly 600 renewals a year. Annoying, but a spreadsheet and a calendar reminder can survive it.

Walk the same estate forward:

2026, at 200 days: about 1,200 renewals a year
2027, at 100 days: about 2,400 renewals a year
2029, at 47 days: about 4,660 renewals a year

That last number is 120 renewals every working day. There is no spreadsheet workflow on earth that survives 2029. Manual cert management is not getting harder. It is ending.

There is a second cost hiding under the headline too. Organisation validation for OV and EV certs can currently be reused for up to 825 days. From March 2026 that drops to 398 days. So even if you buy a multi-year "subscription," you will be redoing the paperwork roughly every year on top of the extra renewals.

Why they are doing this

The short version: revocation never worked. CRLs got too big, OCSP leaks browsing history and mostly soft-fails, and everyone in the room knows it. If a private key leaks today, the worst case exposure is over a year. With 47-day certs the certificate dies on its own within weeks, whether or not revocation does its job.

Short lifetimes also force regular key rotation, which makes future algorithm migrations (hello, post-quantum) far less painful. And they push the whole ecosystem toward what Let's Encrypt already proved works: boring, automated issuance.

You can agree or disagree with the trade-offs. The vote was unanimous, so it is happening either way.

What it means for your setup

Already on ACME (Let's Encrypt, ZeroSSL, etc.): you are mostly fine on the issuance side. Your real risk is silent renewal failure. A DNS change, a rate limit, a webroot misconfig, and nothing tells you until the deployed cert expires. Monitor the certificate that is actually serving traffic, not the cron job that is supposed to renew it. Those are two different things and the gap between them is where outages live.

Manual paid certs (DigiCert, Sectigo, GlobalSign and friends): the calendar-reminder workflow stops being sustainable in 2027 and stops being possible in 2029. Most of these CAs now offer ACME endpoints. Ask your account manager, move to automation this year, and keep the CA relationship if you like it.

Appliances that cannot speak ACME: the long tail of pain. Old load balancers, VPN concentrators, vendor firewalls where renewal means a portal upload and a service restart. Your realistic options are a firmware upgrade that adds ACME, or a reverse proxy in front that owns the cert and re-encrypts upstream. Start the inventory now because procurement cycles are slower than CA/B Forum ballots.

The plan I would follow

2026: inventory and monitor. Find every public cert you own, including the ones nobody remembers (status pages, legacy mail hosts, partner integrations). Put expiry monitoring on all of them, not just the critical ones. Daily checks are plenty. The goal is to never be surprised.
2027: automate everything renewable. By year end, your manual list should be down to appliances you physically cannot upgrade, each with a remediation plan.
2028: dry-run the 47-day cadence. Set internal certs to 47 days a year early and watch what breaks while breaking is still cheap.

And one cultural change: route cert expiry alerts into the same on-call rotation that gets paged for outages. An expired cert is a production outage. It just happens to be one you can schedule.

Disclosure

I build Trace Warrior, a small network tools site with an SSL expiry monitor, so yes, I have skin in this game. The certificate checker is free with no signup if you want to spot-check a host right now. But honestly, use anything. Use a bash script and cron if that is your style. Just do the inventory before March 2026 makes it urgent.