Cut-paper illustration of a TLS certificate with a green padlock beside torn, shrinking calendar pages and a small paper clock

On October 7, Let's Encrypt announced the first reduction to its default certificate lifetime in the organization's history. Staging starts issuing 64-day certificates on October 14. Production follows on February 10, 2027, when the default profile drops from 90 days to 64. The last 90-day certificate is expected to expire on May 11, 2027, and Let's Encrypt says it will not revoke anything to force the transition.

This is not a surprise. Let's Encrypt laid out the roadmap back in December 2025: 64 days in February 2027, then 45 days in February 2028. The CA/Browser Forum is on the same track, with maximum lifetimes heading to 47 days by March 2029. Shorter lifetimes limit how long a compromised key or a mis-issued certificate stays usable. Revocation has never worked well enough to rely on, so the industry answer is to make certificates die faster.

The part that matters to you is not the date. It is whether your renewal logic knows the date changed.

The timeline in one table

Date What changes
Oct 14, 2026 Staging starts issuing 64-day certificates
Feb 10, 2027 Production default drops from 90 to 64 days
Feb 10, 2027 Authorization reuse drops from 30 days to 10 days
May 11, 2027 The last 90-day certificate expires
Feb 16, 2028 Default drops again to 45 days; reuse shrinks to 7 hours

Two details worth noting. First, the authorization reuse change lands on the same February date: the window for reusing domain validation drops from 30 days to 10. Unless you built your client to depend on validation reuse, Let's Encrypt says you do not need to change anything. Second, rate limits are not affected, and the ACME endpoints and issuance chains stay the same.

Who actually breaks

If your ACME client supports ARI, which is ACME Renewal Information, you are probably fine. ARI lets the certificate authority tell your client when to renew, so the client never has to guess from a fixed schedule. Check your client's documentation to confirm.

The risk sits with fixed renewal schedules. Renewing a 90-day certificate when it is 60 days old is the classic pattern, and it has worked for a decade. Against a 64-day certificate, that same schedule renews with 4 days of margin. It works, but it is uncomfortably tight, and it is the kind of margin that turns a quiet weekend into a Monday incident.

Scott Helme makes the point that this tightness looks deliberate. A fixed 60-day renewal just barely catches the new certificates before they expire, so this first reduction should pass without widespread breakage. The 45-day certificates coming in February 2028 are the ones that will actually break fixed schedules. The 64-day step is the warning shot. Treat it that way.

Let's Encrypt's own guidance is plain about what to do. If your renewals are hardcoded to a fixed number of days before expiry, change them to renew at roughly two thirds of the certificate lifetime. For a 64-day certificate that means renewing around day 42. They also suggest grepping cron jobs, wrapper scripts, and runbooks for the usual hardcoded numbers: 83, 80, and 60.

ARI is the real fix

The durable fix is not a new magic number. It is ACME Renewal Information. With ARI, your client asks the CA when it should renew, and the CA answers. The lifetime can change again, and it will in 2028, without you touching a schedule. Certbot, cert-manager, and most maintained clients have ARI support or are adding it. Verify yours instead of assuming.

This is the same lesson as every other automation story. Hardcoded values are a snapshot of assumptions that were true when you wrote them. The 90-day default was true for ten years, which is exactly why so many scripts baked it in. The fix is to stop encoding the CA's policy in your cron and let the CA tell you when to act.

What to check this week

  1. Grep your cron jobs, certbot wrapper scripts, Ansible roles, and runbooks for 83, 80, and 60. Those numbers are the fingerprints of a fixed renewal schedule.
  2. Check whether your ACME client supports ARI, and enable it if it does.
  3. If you renew on a fixed schedule, change it to roughly two thirds of the certificate lifetime instead of a fixed day count.
  4. Point a test at the staging environment after October 14 and watch a full renewal cycle complete.
  5. Confirm your reload hooks still fire. A renewed certificate that never gets loaded into the service is the same as an expired one.
  6. Add alerting on renewal failure if you do not have it. Shorter lifetimes mean less time to notice when a renewal breaks.

None of this is hard. It is just the kind of work that only gets done before the deadline, not after.

Sources

The 90-day certificate had a good run. Ten years is practically forever in infrastructure. The next era is shorter lifetimes and renewal logic that does not care what the number is. Check your timers now, while the margin is still comfortable.