On 7 October, Let's Encrypt announced that its default certificate will last 64 days instead of 90. The free certificate authority signs a large share of the certificates on the public web, so this touches almost every engineering organisation, including the ones that think they stopped worrying about certificates years ago.
The change does not arrive overnight. But it moves a quiet piece of plumbing back onto the risk register, and it is the first of several steps.
The dates that matter
- 14 October 2026: the Let's Encrypt staging environment starts issuing 64-day certificates, so teams can test.
- 10 February 2027: production switches. Every certificate issued or renewed from this date lasts 64 days.
- Around 11 May 2027: the last 90-day certificates expire.
- 2028: Let's Encrypt expects the default to drop again, to 45 days.
There is a second, less visible change. Let's Encrypt will reuse a successful domain check for 10 days instead of 30, and that window shrinks to seven hours in 2028. In practice this means your systems prove control of a domain far more often.
Some things stay the same. Existing certificates will not be revoked. The ACME endpoints, the certificate chains and the rate limits are unchanged. Teams that want even shorter certificates can still ask for 45-day or 6-day ones.
Why this is happening
This is not a Let's Encrypt quirk. The browser makers and certificate authorities agreed in 2025 to shrink the maximum life of every public TLS certificate in stages, ending at 47 days in 2029. Shorter certificates limit how long a stolen or wrongly issued certificate stays useful. Let's Encrypt is simply moving early and on its own schedule.
So even if you buy certificates from a commercial provider, the same pressure is coming your way. Treat this as the first warning, not a one-off.
Where it breaks
Well-run automation should barely notice. Modern ACME clients that support ACME Renewal Info (ARI) ask the certificate authority when to renew and adjust on their own.
The risk sits in the setups nobody has looked at for a while:
- Fixed timers. A cron job that renews every 80 days used to be safe. With 64-day certificates it leaves sites running on an expired certificate for more than two weeks. A job that renews every 60 days leaves four days of slack, which is not enough to recover from a single failed run.
- Hand-made scripts and runbooks. Let's Encrypt itself suggests searching your scripts, cron entries and documents for numbers like 83, 80 and 60. Those are usually old assumptions about a 90-day life.
- Certificates that are renewed but never reloaded. A new file on disk does nothing until the web server, load balancer or appliance picks it up. Halve the life of a certificate and you double the number of times that last step has to work.
- Appliances and edge devices where someone copies a certificate in by hand every quarter. That habit will not survive 64 days, and it certainly will not survive 45.
The rule of thumb from Let's Encrypt is to renew at about two thirds of a certificate's life. For a 64-day certificate that is roughly day 43.
Why leaders should care
Expired certificates cause some of the most embarrassing outages in the industry. They are entirely predictable, they usually hit customer-facing endpoints, and the fix takes minutes once someone notices. The cost is in the hours before anyone does.
Shorter lifetimes raise the number of renewal events across your estate by about 40% in 2027, and by about twice the current number once 45 days arrives. If your renewal success rate is 99%, more renewals means more failures in absolute terms. The only real defence is automation you can see working.
What to do this quarter
- Build an inventory. List every place a Let's Encrypt certificate is used, including load balancers, ingress controllers, internal tools and vendor appliances. Certificate transparency logs can show you certificates issued for your domains that you did not know about.
- Test against staging from 14 October. Point a non-production system at the Let's Encrypt staging environment and confirm the full cycle works: request, renew, reload.
- Move to an ARI-capable client where you can, and remove fixed day counts where you cannot.
- Alert on expiry, not just on failure. A simple check that warns when any public certificate has fewer than 14 days left catches the cases your automation misses.
- Give it an owner. Certificate renewal often belongs to everyone and therefore no one. Name a team.
If all of this is already in place, the change is a non-event, and that is the goal. If it is not, you have four months before production switches. That is plenty of time, but only if someone starts now.
