Let's Encrypt moves to 64-day certificates by default in 2027

Let's Encrypt will cut its default certificate lifetime from 90 days to 64 days on February 10, 2027, and shorten it again to 45 days in 2028. The CA announced the move in a October 7 post; 64-day certificates land in the staging environment on October 14, 2026 for testing. If any of your renewals are manual, or hardcoded to a fixed number of days before expiry, they will start failing before most teams notice — which is the only reason this is worth your attention today.

What's changing

On February 10, 2027, every newly issued or renewed Let's Encrypt certificate gets a 64-day lifetime unless you explicitly request a 45-day or 6-day profile. The last 90-day certificate is expected to expire May 11, 2027. Alongside the lifetime cut, the authorization reuse period drops from 30 days to 10 days now, and to seven hours in 2028. Staging flips to 64-day issuance on October 14, so you can validate against it before production changes.

Why

The reduction tracks the CA/Browser Forum Baseline Requirements, which are pushing the whole WebPKI toward shorter-lived certificates. Shorter validity narrows the window a compromised or mis-issued certificate stays useful and makes revocation less load-bearing, since a certificate you can't revoke cleanly expires on its own in weeks instead of months. Let's Encrypt frames the 64-day step as groundwork for the 45-day default in 2028, as reported by SecurityWeek.

What could break

The failure mode is not the new lifetime itself — it's renewal automation that assumes the old one.

• Clients that renew at a fixed offset (for example, "renew 30 days before expiry") were tuned for 90-day certs. On a 64-day cert, a 30-day offset renews too late relative to the lifetime, and on shorter profiles it may not renew at all before expiry.
• Any workflow that still renews by hand, or on a cron job sized for quarterly rotation, will miss windows.
• Pinned or long-lived certificate assumptions in internal tooling, monitoring, and mTLS between services.

Action checklist

1. Confirm every certificate renews automatically. Enumerate where Let's Encrypt certs live — load balancers, ingress controllers, reverse proxies, appliances, internal mTLS — and verify each has a working ACME client, not a human in the loop.
2. Prefer a client that supports ACME Renewal Info (ARI). With ARI, the CA tells your client when to renew; that is the clean path through every future lifetime cut, not just this one.
3. Fix hardcoded renewal offsets. Where renewal is pinned to a fixed point before expiry, set it to roughly two-thirds of the certificate lifetime so it scales with 64-, 45-, and 6-day certs.
4. Test against staging after October 14. Point a non-production endpoint at the staging environment and watch a full issue-and-renew cycle on a 64-day cert before February.
5. Account for the 10-day authorization reuse window. Pipelines that batched validations across many domains on the old 30-day reuse will revalidate more often.

Context

This is the same direction every major CA is heading: Apple, Google, and the CA/Browser Forum have all signaled a march toward ~47-day maximum validity by 2029. Let's Encrypt is simply arriving early and in steps. The practitioner takeaway doesn't change between now and 2028 — the only durable fix is automation that renews on the CA's signal rather than a calendar assumption. Teams that get ARI working once stop having to care each time the number drops.