Imagine if your driver's license, which used to last ten years, now lasted three months. Same license. Same photo. Same database. But every quarter you needed to go to the DMV, prove you're still you, and walk out with a fresh one.
You'd cope. Probably. But you'd cope by changing how you thought about the whole thing. You couldn't rely on "I'll handle it when the reminder comes." You'd need a system. You'd need it on autopilot. And the first time the autopilot misfired, you'd find out about it standing in front of a police officer.
That's the shift TLS certificates are going through right now.
For most of the public web's history, certs lasted a year or longer. Some lasted three. You renewed them about as often as you renewed your domain registrations - annually, with a calendar reminder, with a person who knew what to click.
In March 2026, the maximum validity for publicly trusted TLS certs dropped to 200 days. In March 2027, it drops to 100. In March 2029, it drops to 47. Those numbers aren't a proposal anymore; they're a published CA/Browser Forum schedule (Ballot SC-081v3, ratified in 2025).
If your renewal process still has a human in the middle, the milk-versus-canned-food analogy is about to become very vivid.
Why this is happening
Two reasons. Both reasonable.
Compromise containment. A leaked private key, a misissued cert, a CA mistake - these are all bad. The longer the validity period, the longer the bad cert stays trusted by browsers. Shorter certs mean a shorter blast radius when something goes wrong.
Automation as a forcing function. The CA/Browser Forum - the body of browser makers and CAs that sets these rules - has been nudging the industry toward automated issuance for a decade. Long-lived certs let teams stay manual. Short-lived certs make manual unsustainable. The schedule is a calendar applied to a policy goal: by 2029, "we handle renewals on the second Tuesday of the month" stops being a process anyone can sustain.
You can argue with the trade-off. Plenty of people have. But the schedule is set, and "my org is special" is not a feature browsers respect.
What breaks at small scale
Small teams - let's say one to ten engineers, fewer than a hundred certs - will feel this first.
Manual renewals stop working. If you had one cert with a 397-day lifespan and a calendar reminder, you'll have the same cert with a 47-day lifespan and the same calendar reminder. Eight reminders a year, not one. Each one a small risk of being missed. The math is unforgiving.
Convenience certs become a tax. Internal admin tools, staging environments, the dev machine with TLS on it - every place where someone generated a long-lived cert and forgot about it - turn into a small stream of expiry events.
"I'll just use Let's Encrypt" stops being free in the sense that matters. Let's Encrypt's 90-day validity has been the model from day one, and certbot does the work. But certbot has to be installed, kept up to date, integrated with the web server, monitored for failure, and tested. The licence is free; the operational cost is not.
The fix at small scale is one of two things: full automation (ACME everywhere, every cert), or a managed service (something like AWS ACM, Cloudflare, or a monitor sitting in front of whatever automation you already run). The middle path - "we have automation but also a person who handles edge cases" - gets crushed under the new frequency.
What breaks at large scale
Bigger teams have a different problem. Most of them think they've already solved this. ACME is set up, certbot runs, renewals happen. What could go wrong?
Three things. They all multiply at higher cert counts.
Silent automation failures. With annual renewals, a silent failure had eleven months to be noticed. With 47-day validity, it has six weeks. With 100-day validity, around fourteen. Failures that used to be caught by the next manual touch now run out of time. You need monitoring that doesn't trust the renewal pipeline - checks from outside, the way a real user would see it. "Even with automation, having external validation helps avoid blind spots," as one operator put it on Hacker News.
Inventory drift accelerates. When you renew once a year, your inventory error has a year to accumulate but also a year to be noticed. When you renew eight times a year, the same drift gets eight times as many chances to fail. You can't afford to have certs you don't know about.
Internal PKI workloads change. Internal CAs were often configured for multi-year certs because nobody wanted to deal with the issuance load. Service meshes, internal admin tools, microservice mTLS - all of these were quietly relying on long lifetimes. Tightening to 90 days internally is fine. Tightening when you didn't realise the cert was internally signed and never had monitoring is where things bite.
The fix at large scale isn't "more automation." You already have automation. The fix is closing the gap between the automation and the audit trail - independent monitoring, complete inventory, and alerts that don't depend on the renewal pipeline working.
The new operational reality
What does a team that's actually ready for the 47-day era look like?
Every cert renews automatically, or has a documented reason it doesn't. "We've always done it by hand" is not a reason.
Every cert is in the inventory, including the ones you don't think you have. Internal CAs, expired ones still being served by something, certs in keystores, certs in mobile app pins.
Renewals are observed, not assumed. When automation runs, something independent confirms the new cert is in production and serving correctly. Not just "the script returned zero."
Alerts go to a team, not a person. People leave. Shared mailboxes and shared channels survive turnover. The 47-day era will outlast at least three full org reorgs.
Failure paths are documented. When a CA has a bad day - and CAs have bad days now, see Let's Encrypt's May 2026 issuance halt - there's a known sequence of actions, not a Slack thread that starts with "wait, what?"
None of this is unique to short certs. It's just that long-lived certs let you skip parts of it. Short-lived certs don't.
What still works, what doesn't
Still works: - ACME, certbot, AWS ACM, Cloudflare-managed certs - the automated paths get more valuable, not less. - Internal PKI tools with API-driven issuance. - Service meshes that already do certificate rotation natively (Istio, Linkerd, SPIFFE).
Stops working: - Calendar reminders as the primary alarm. - Spreadsheets as the inventory of record. - Manual renewals as anything other than an emergency fallback. - "We have a person who handles certs" as a process.
The boundary between the two lists is roughly the same boundary as "milk versus canned food." Different shelf life, different rules.
One small ask
The shift is real, the schedule is published, and nobody is going to make an exception for your environment. The good news is the fix is mostly hygiene - observability, inventory, team-owned alerts. TLS Radar handles the monitoring side of that for any CA and any setup. The free tier covers three domains, which is enough to see whether your current automation actually works as well as you think it does.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.