TLS certificate lifetimes are dropping from 398 days to 47 over the next three years. Here's what changes, why it's happening, and the eight things every platform team should fix before the first cliff in 2027.
For the first ten years of the modern web's encrypted era, the median platform engineer thought about TLS certificates roughly twice a year. Renew. Click. Forget. By the late 2010s automation crept in. ACME took the click out, and most teams stopped thinking about certificates at all.
That's about to change.
Over the next three years, the maximum lifetime of a public TLS certificate is going to drop from 398 days to 47 days. The window inside which a Certificate Authority can reuse a previous domain validation collapses from 398 days to 10. Renewal goes from "set and forget" to "if anything in your renewal pipeline silently breaks for two weeks, your customers see browser warnings."
If your strategy today is "we've got Let's Encrypt and a cert-manager pod somewhere in the cluster," you should keep reading. The 47-day floor is not a hypothetical — the schedule is set, the votes are in, and the first cliff lands in March 2027.
In April 2025, the CA/Browser Forum — the standards body that governs what every public Certificate Authority is allowed to issue — passed ballot SC-081v3. The vote came after multiple rounds of negotiation and a public proposal led by Apple. The result is the most aggressive certificate-lifetime reduction in the history of the public web PKI.
Here's what the schedule looks like:
| Date | Max certificate lifetime | Max DCV reuse |
|---|---|---|
| Today | 398 days | 398 days |
| 15 March 2026 | 200 days | 200 days |
| 15 March 2027 | 100 days | 100 days |
| 15 March 2029 | 47 days | 10 days |
A few things are worth pointing out about this table.
First, the maximum certificate lifetime is what Certificate Authorities are allowed to issue — it's a ceiling, not a floor. The dominant ACME-issuing CA today is Let's Encrypt, which has issued 90-day certs for years. So if you're already on Let's Encrypt, the first transition (200 days in 2026) doesn't change your renewal cadence at all.
Second, the Domain Control Validation (DCV) reuse window — the second column — is the one that is going to hurt. DCV is the proof that you control the domain you're getting a certificate for: an HTTP-01 challenge file, a DNS TXT record, a TLS-ALPN handshake. Today, once you complete a DCV check, the CA can reuse that proof to issue you new certificates for up to 398 days without re-validating. From March 2029, that drops to 10 days.
That means: every certificate request, in steady state, will require a fresh DCV check. Every. Single. One.
If your DCV depends on anything that requires a human in the loop — a TXT record someone copy-pasted into Cloudflare three years ago, a manual DNS change ticket, a CDN provider's "rotate certificate" button — that pipeline stops working in 2029.
The case for shorter certificate lifetimes is, broadly, that revocation is broken.
In theory, when a private key is compromised, the CA revokes the certificate, browsers check the revocation status (via OCSP or CRL), and the bad cert stops being trusted. In practice, OCSP soft-fails universally — if a browser can't reach the OCSP responder, it just shrugs and accepts the cert. CRLs are huge and rarely fetched in practice. OCSP stapling has limited adoption. Mozilla shut down OCSP responders entirely in 2024 because the system was so unreliable it was actively harmful.
Without working revocation, the only real bound on how long a stolen key remains useful is the certificate's expiry date. A 398-day certificate with a leaked private key is a 398-day MITM opportunity. A 47-day certificate is a 47-day one.
That's the security argument. There's also a quieter operational argument: the people pushing for shorter lifetimes — Apple, Google, Mozilla — have a vested interest in a web where automation is mandatory. Manual TLS practices are correlated with security incidents, with a long tail of small operators running ancient OpenSSL versions and never updating their pinned root stores. Forcing 47-day renewals forces automation. Forcing automation forces modern crypto, modern key handling, and modern revocation hygiene.
You can disagree with the philosophy. You're not going to win the argument. The schedule is set.
If you're already on a 90-day Let's Encrypt cadence, you might wonder what changes. Here's the answer: the failure modes don't change, but the consequences of a failure get a lot worse.
Renewal slack disappears. Today, if your ACME client fails for a week and nobody notices, you've still got 83 days to fix it. At 47 days, that same week of silent failure means a critical-state cert with a fortnight to live, and you'll be the second person to find out about it.
DCV failure now blocks the next cert, not the one after. With 398-day DCV reuse, an HTTP-01 outage on Tuesday only matters if your cert happened to be due for issuance on Tuesday. Most weeks, nothing happens. With 10-day DCV reuse, every renewal is a fresh challenge, so every renewal is exposed to every transient HTTP-01 / DNS-01 / TLS-ALPN failure your infrastructure can produce.
The number of renewals quadruples. A team running 200 monitored hostnames at 398-day lifetimes does ~200 renewals a year. The same fleet at 47 days does ~1,560 — roughly 30 a week. The probability that at least one of those silently fails on any given day is much, much higher than "tiny."
Vendor-issued certs get expensive (and weird). Most paid-cert CAs sell a "1-year certificate" today and re-issue mid-cycle. They'll have to re-architect that around the new ceiling. Expect new pricing models, expect API rate limits, expect at least one major CA's automation to silently break in 2027.
Edge / CDN refresh cycles matter. A lot of load balancers, edge proxies, and CDN configurations cache TLS material for 6-24 hours after rotation. Some refresh on signal, some refresh on a timer, some refresh "next time the box reboots." At a 90-day cadence with weekly slack, those edge cases are absorbed. At 47 days they're not.
This is not theoretical. The first cliff (200-day max, 2026) doesn't bite if you're on Let's Encrypt. The 100-day cliff in March 2027 is roughly two ACME renewal cycles away. That's the deadline you should be planning around.
1. Build a real certificate inventory, today. The single most common reason a cert expires unexpectedly is that nobody knew it existed. Vendor-issued certs on marketing subdomains, a legacy admin panel someone stood up in 2022, a third-party SaaS that mounted cname.yourcorp.com for white-labelled hosting. Public Certificate Transparency logs are the canonical source of truth for "every cert ever issued for your domain" — if your inventory doesn't reconcile against CT logs, it's incomplete.
2. Automate every single renewal. No exceptions. "We have a calendar reminder" doesn't survive 47 days. "Bob renews it manually" doesn't survive 47 days. If a human has to type a command for a renewal to happen, that renewal will eventually fail, and at 47 days you have ~17 days of warning before it does so visibly.
3. Make DCV self-healing. Domain Control Validation can fail for a hundred reasons: a CSP header that breaks the HTTP-01 path, a DNS provider rate-limiting your TXT record updates, a CNAME flattening rule that quietly drops a challenge subdomain. Decouple your DCV from any human approval. Build runbooks for HTTP-01 fallback to DNS-01. Test DCV failure modes regularly.
4. Monitor renewals from outside the renewal system. If the same system that renews your certificates is also the system that alerts on missed renewals, you're trusting the alarm to wake the burglar up. Run external monitoring that fetches each cert from the public internet — the same way browsers do — on an independent schedule. When an ACME silently fails, you want a check that doesn't share any code with ACME to notice.
5. Audit your edge. Walk every load balancer, every CDN, every reverse proxy, every TLS-terminating service. For each one, answer: when ACME issues a new cert, how does this box pick it up? Is it instant, on a timer, on signal, on reboot? What's the worst case? At 47 days, anything worse than "within an hour" is going to bite you.
6. Decommission what you don't need. Every certificate is a renewal pipeline. If you've got legacy-admin.yourcorp.com returning a 301 to the new domain and nothing else, kill the cert. Reduce the surface area before the surface area gets harder to monitor.
7. Revisit your wildcard strategy. Wildcards are convenient, but they hide which subdomains are actually in production. With the new DCV cadence you'll be re-validating wildcards every 10 days anyway, so the operational benefit shrinks. Per-subdomain certs give you better CT visibility and finer-grained failure isolation.
8. Pre-test the 2027 cadence in 2026. You don't have to wait for the regulatory deadline. Drop a representative chunk of your fleet to 90- or 60-day Let's Encrypt certs now and run that for a quarter. Whatever breaks at 60 days will absolutely break at 47.
Most platform teams I've spoken to about this in the last six months immediately go to renewal automation as the answer. ACME this, cert-manager that, a Vault PKI mount over there.
But the failure mode that's actually going to kill teams isn't a renewal that fails. It's a certificate that nobody knew existed in the first place — and so wasn't in any renewal system.
This is the part that surprises people. Run a Certificate Transparency search against your apex domain right now. If you've got more than a handful of subdomains, the result is going to be larger than you expect. A vendor SaaS subdomain from a 2020 marketing campaign. A staging-old. from a migration nobody finished. A wildcard cert someone provisioned for a subdomain takeover that never actually launched. Each one is a quiet expiry that, in the 47-day era, is going to make a lot more noise.
CT-log enumeration is publicly available and isn't hard. The problem isn't getting the data — it's that nobody runs the query, because there's no obvious place in your week to do it. So it doesn't get done. So the inventory drifts. So the first time you find out about legacy-internal.yourcorp.com is when its expired cert lands in customer support.
If you take one thing from this post, take this: before you do anything else about the 47-day transition, run CT-log discovery against every domain your company owns. Reconcile what you find against your renewal system. Whatever is in the discovery output that isn't in your renewal system is your inventory gap, and your inventory gap is your 2027 incident waiting to happen.
We started Tidelock because we kept seeing the same incident pattern: a cert nobody owned expired, customers screenshotted the warning, the platform team found out about it on a Sunday afternoon. The runbook existed. The Slack channel existed. The alert didn't.
Tidelock is the alert. It pulls every subdomain you own from public Certificate Transparency logs, watches the TLS cert on each one from outside your stack, and pages you 30 days before anything expires. It works alongside whatever ACME client or CA you're already using — it doesn't replace your renewal pipeline, it watches it.
We're in private beta right now. Join the waitlist and you'll lock in launch pricing for the lifetime of your account; first cohort invites ship monthly. If you want to see what we'd find on your domains before signing up, the free certificate discovery tool is open to anyone — paste a domain and we'll show you the subdomains and the certs on each one, no email required.
47 days isn't a hypothetical. The first cliff is two ACME cycles away. The teams that come out of this transition cleanly are the ones who started doing inventory work in 2026.
That'd be a good week to start.