Part 1 of 5 in TLS in 2026 — a series on the year the public TLS stack quietly rewrote itself. This post sets the stakes; the next four cover the automation, cryptography, and monitoring that follow from them.
Here’s the thing most “47-day certificates are coming” posts get wrong: it isn’t coming. It started. As of March 15, 2026, the maximum lifetime of a public TLS certificate is 200 days — down from 398. If your renewal process assumed “once a year and forget it,” that process is already non-compliant. The era everyone was warned about is the one you’re standing in.
And 200 days is the gentle part. The same schedule takes us to 100-day certificates in 2027 and 47-day certificates in 2029. This is not a proposal, a trial balloon, or a vendor’s opinion. It’s a dated, ratified plan, and it changes the job of running certificates from an annual chore into a continuous system you operate.
The schedule
In April 2025 the CA/Browser Forum — the body that governs the rules public certificate authorities must follow — passed Ballot SC-081v3. It sets a stepped reduction in the maximum validity of publicly-trusted TLS certificates, with three hard dates:
- March 15, 2026 — max lifetime drops 398 → 200 days (in effect now)
- March 15, 2027 — max lifetime drops to 100 days
- March 15, 2029 — max lifetime drops to 47 days
These are ceilings, not targets. A CA can issue certificates shorter than the maximum — and many automated issuers already do, handing out 90-day or even shorter certs today. What changes is the longest leash you’re allowed: after each date, no publicly-trusted CA may sign a cert that outlives the new cap.
The number “47” looks arbitrary until you do the arithmetic the ballot’s authors did. A roughly six-week certificate, renewed with sane overlap, gives you about one calendar month of certificate plus a buffer — short enough to make the cert itself a poor target, long enough that a healthy automation pipeline can renew it several times before it ever approaches expiry.
Why this is happening
The short answer: revocation never really worked, so the industry gave up on it and chose expiry instead.
When a certificate’s private key is compromised or a cert is mis-issued, the theoretical fix is revocation — telling the world “don’t trust this one anymore” via CRLs or OCSP. In practice, revocation has always been the weakest link in the web PKI. OCSP added a real-time, privacy-leaking dependency on the CA’s infrastructure and was widely soft-failed by clients (if the check times out, trust it anyway), which makes it nearly useless against an active attacker. The industry has spent the last couple of years actively winding OCSP down rather than fixing it.
If you can’t reliably revoke, the only lever left is time. A certificate that lives 47 days is one that an attacker can abuse for at most 47 days, with no revocation infrastructure required. Shorter lifetimes turn expiry itself into the safety mechanism. They also do something subtler and arguably more important: they make automation non-optional, and automation is itself a security control. A fleet that renews every six weeks without humans is a fleet where renewal is tested constantly, key material rotates regularly, and “the one person who knew how to renew that cert” stops being a single point of failure.
There’s a second motive that doesn’t get enough airtime, and it’s the one that makes this series hang together: agility. A web full of year-long certificates is a web that takes a year-plus to change anything about certificates — an algorithm, a key size, a chain construction. A web of six-week certificates can turn the whole fleet over in six weeks. That matters enormously right now, because 2026 is also the year the cryptography inside certificates is in motion: post-quantum signatures are coming, certificate shapes are being redesigned, and nobody wants to be locked into a five-year-old cert when the ground is shifting. Short lifetimes are the prerequisite for everything else this series covers. You can’t migrate a fleet you can’t rotate.
200 days is already the test
It’s tempting to treat the live milestone as the easy one and save the worry for 2029. Do the opposite. The 200-day cap that landed in March is the cheapest, most forgiving version of this change you will ever get — and it’s already enough to break the worst processes. If anything you run still depends on a human remembering to renew a certificate, the 200-day world has merely been kind enough not to expose it yet, because the interval is still long enough to paper over with calendar reminders. 100 days, a year from now, will not be. Treat the current window as a free dress rehearsal: whatever you can’t comfortably renew at 200 days without a human in the loop is a guaranteed outage at 47.
The detail that breaks naive automation
Most coverage stops at the cert lifetime. The operationally dangerous half of SC-081v3 is the part about domain control validation (DCV) reuse.
When you get a certificate, you first prove you control the domain — an HTTP challenge, a DNS record, whatever your ACME flow uses. Historically a CA could reuse that proof for up to 398 days, so you validated once and re-issued freely for a year. SC-081v3 collapses that reuse window on the same schedule as the cert lifetime — and pushes it further:
This is the line where teams who think they’re automated discover they’re only
half-automated. Issuing a cert from a cached authorization is easy. Re-running
domain validation 35 times a year — including for wildcards, which can only be
validated via DNS — is a real dependency on your DNS provider’s API, your
challenge plumbing, and the propagation behavior of whatever records you’re
flipping. If your dns-01 challenge takes a manual step, you don’t have
automation; you have a recurring incident.
What actually changes operationally
Put the two worlds side by side and the shift is obvious:
| The 398-day world | The 47-day world |
|---|---|
| Renew ~once a year | Renew ~8x as often (every ~6 weeks) |
| Validate domain once, reuse for a year | Re-prove control ~35x/year per domain |
| A human can do it from a runbook | Humans can't keep up; automation is mandatory |
| A missed renewal is a yearly risk | A missed renewal is a near-monthly risk |
| Expiry monitoring = a 30-day calendar alert | Calendar alerts are meaningless; you watch rotation health |
| Cert management is a task | Cert management is a system you operate |
The frequency multiplier is the headline, but the risk-shape change is the part that bites. At one renewal a year, a failure is rare and loud — somebody notices, it’s a story, you fix the process. At eight-plus renewals a year across a fleet, failures become statistically routine, and the dangerous ones are quiet: a cert that renewed at the CA but never deployed to the load balancer, one node out of twenty that missed the push, a wildcard whose validation lapsed while everything looked green. The expiry date stops being a useful signal because everything is always close to expiry by design.
Picture the failure that’s about to get common. Your ACME client renews a cert on schedule and writes it to disk. The reload hook that’s supposed to tell the load balancer to pick it up silently fails — a permissions change three sprints ago, never noticed, because the old cert was still valid for months and nobody was watching that closely. The CA’s records say you’re current. Your renewal logs say success. The certificate on disk is fresh. And the certificate actually being served to users is the previous one, ticking down toward an expiry that, in a 47-day world, is now weeks away instead of a year. Nothing in your renewal pipeline is wrong. The cert renewed. It just didn’t arrive — and the only place that’s visible is from the outside, looking at what the endpoint actually presents. Multiply that by a fleet and a weekly cadence and you have the defining operational hazard of this era.
The certs that will actually hurt you
If everything you serve already runs through a modern ACME client behind a CDN, the lifetime changes are a non-event — your automation just renews more often and you never notice. The pain lives in the long tail nobody automated:
- Network appliances and load balancers with certs uploaded by hand through a web console.
- Vendor and SaaS portals where someone pastes a PEM into a settings page twice a year.
- Internal services riding public certs because that was easier than running an internal CA.
- mTLS between services where both ends pin or manually rotate.
- The forgotten subdomain on a host whose renewal lived in one engineer’s personal cron job — and that engineer left.
Every one of these worked fine at 398 days because a human could absorb a once-a-year task. None of them survive contact with a six-week cycle. The work of the next few years isn’t renewing your already-automated certs faster — it’s finding and fixing the ones that were never automated at all.
What to do now
You have runway before 47 days, but the 200-day cap is live today and 100 days arrives in under a year. A practical order of operations:
- Inventory every public certificate you serve — and how each one is issued and deployed today
- Flag every cert that involves a human step (console upload, manual paste, personal cron)
- Move everything you can onto ACME, including wildcard and dns-01 flows
- Make domain validation itself automated and resilient — it now runs ~35x/year
- For certs that genuinely can't do ACME, plan the replacement or the runbook now
- Shift monitoring from 'expiry countdown' to 'did rotation actually happen, everywhere'
That last item is the one most teams skip, and it’s the one this series ends on. Faster certificates don’t remove certificate risk — they relocate it from “we forgot to renew” to “we renewed, but something downstream is wrong.” Your monitoring has to move with it.
If you want a starting point for the inventory, you can see exactly what any hostname is serving today — issuer, validity window, and time remaining — with the SSL certificate checker, and get a broader read across domains with the domain health checker. For the human side of the problem, our earlier guide on what to do when a certificate is about to expire still applies — there will just be a lot more about-to-expire moments.
Next week
The 47-day schedule makes one thing certain: manual renewal is finished. The open question is what robust automation actually looks like when the CA itself needs a say in your renewal timing — early revocations, load spreading, mass-revocation events. That’s ACME and ARI, and it’s the next post in the series.