Let's Encrypt Cuts Default Certificate Validity to 64 Days Ahead of 45-Day Switch

Let's Encrypt Shortens Default Certificate Lifetime to 64 Days

Let's Encrypt, the nonprofit certificate authority run by the Internet Security Research Group (ISRG), announced on October 7, 2026 that it will cut the default validity period of its TLS certificates from 90 days to 64 days, with the change landing in its staging environment on October 14, 2026 and reaching production on February 10, 2027. It is the first reduction in default certificate lifetime in Let's Encrypt's eleven-year history, and it is only the first step: a further cut to 45 days is scheduled for February 16, 2028, part of an industry-wide CA/Browser Forum mandate that will cap all publicly trusted TLS certificates at 47 days by March 2029. ISRG's Sarah Gran said the shorter lifetimes "reduce the risk of key compromise and mis-issuance" and advance the organization's mission to make the web more secure by default.

Change Details

What's Changing and Why

A phased rollout, not a sudden cutover

Let's Encrypt is staging the change deliberately. Starting October 14, 2026, its staging environment will begin issuing 64-day certificates so administrators and ACME client maintainers can test renewal behavior before anything changes in production. The default production profile switches to 64-day certificates on February 10, 2027; any certificate issued before that date keeps its original 90-day term, so the last 90-day certificate is expected to expire around May 11, 2027. Let's Encrypt says no currently valid certificates will be revoked as part of the transition. A second reduction, to 45 days, follows on February 16, 2028.

The CA/Browser Forum roadmap behind it

This is not a Let's Encrypt-only initiative. The change follows Ballot SC-081, passed by the CA/Browser Forum in 2025, which sets a binding schedule for every publicly trusted certificate authority:

• 398 days maximum validity through March 2026 (the long-standing status quo)
• 200 days maximum validity starting March 15, 2026
• 100 days maximum validity starting March 15, 2027
• 47 days maximum validity starting March 15, 2029

Domain control validation (DCV) reuse periods — how long a CA can rely on previously validated domain-control evidence before re-checking it — shrink on a parallel schedule, ending at 10 days by 2029. Let's Encrypt's own authorization reuse period is moving even faster than the Forum's floor: from 30 days today to 10 days in February 2027 and down to 7 hours in 2028. The ballot was championed by Apple, which argued that the certificate revocation ecosystem built on CRLs and OCSP is unreliable in practice because many clients and browsers ignore revocation signals outright — so shrinking the window a compromised or mis-issued certificate can remain valid is a more dependable mitigation than revocation.

Why Let's Encrypt is moving now

Let's Encrypt frames the 64-day step as compliance groundwork rather than a one-off change. Shorter authorization reuse windows eliminate the need for CAA rechecking — the extra validation step CAs must perform when cached authorization data is more than a set number of hours old. By shrinking its own reuse period ahead of the Forum's hard deadlines, Let's Encrypt avoids maintaining that extra rechecking logic altogether. The organization also points to the direct security benefit: a stolen private key or a mis-issued certificate is only useful to an attacker for as long as the certificate remains valid, so cutting validity periods by nearly a third immediately shrinks that exposure window fleet-wide.

What it means for automation

Let's Encrypt has supported ACME Renewal Info (ARI) since late 2025, an ACME extension that lets the CA tell a supporting client exactly when to renew rather than leaving the client to guess based on a fixed day count. Operators running an ARI-aware ACME client — including recent versions of Certbot, win-acme, and several other major clients — need to take no action; renewal timing adjusts automatically as validity periods shrink. The risk falls on infrastructure that hardcodes renewal logic: cron jobs, wrapper scripts, load-balancer configs, or runbooks that trigger renewal at a fixed day offset (commonly 83, 80, or 60 days into a 90-day certificate) will start failing or renewing too late once certificates expire in 64 or 45 days. Let's Encrypt is not changing ACME endpoints, issuance chains, or rate limits as part of this rollout — only the default validity period and authorization reuse window.

Impact Assessment

Recommendations

For system administrators

• Search cron jobs, systemd timers, deployment scripts, and documented runbooks for hardcoded renewal-day values (commonly 83, 80, or 60) tied to a 90-day assumption, and update them before February 10, 2027.
• Where a fixed offset is unavoidable, Let's Encrypt recommends renewing at roughly two-thirds of the certificate's validity period rather than a fixed number of days before expiry.
• Test renewal workflows against Let's Encrypt's staging environment starting October 14, 2026, well ahead of the production switch.

For security and platform teams

• Confirm that ACME clients in use (Certbot, win-acme, acme.sh, lego, or internal tooling) support ACME Renewal Info (ARI); upgrade clients that don't.
• Automate certificate reload and deployment end-to-end — issuance without an automated reload step still creates an outage risk as renewal cycles compress.
• Set up alerting on failed or missed renewals now, before the shorter windows reduce the margin for error.
• Inventory all certificates (internal and external) and their issuing CA, since the CA/Browser Forum schedule applies to every publicly trusted CA, not only Let's Encrypt.

For developers of internal tools and appliances

• Audit any product or internal tool that displays, stores, or validates certificate expiry assuming a 90-day (or longer) lifetime; shorter default validity periods can expose off-by-one or stale-cache bugs in monitoring dashboards.
• Favor ACME-native renewal over any proprietary "renew X days before expiry" setting that requires manual tuning every time CA defaults change.

Key Takeaways

1. Let's Encrypt's default certificate validity drops from 90 to 64 days on February 10, 2027, with staging tests starting October 14, 2026 — the first such cut in its eleven-year history.
2. A further drop to 45 days is already scheduled for February 16, 2028.
3. The change implements CA/Browser Forum Ballot SC-081, which caps all publicly trusted certificates at 47 days maximum validity by March 15, 2029, with 200-day and 100-day milestones in 2026 and 2027.
4. Authorization/domain-validation reuse periods are shrinking in parallel — from 30 days to 10 days in 2027, then to 7 hours in 2028 — eliminating the need for CAA rechecking.
5. Organizations using ACME Renewal Info (ARI)-aware clients need no action; those with hardcoded renewal schedules must update them before the February 2027 switch to avoid expired-certificate outages.
6. This is an industry-wide mandate, not a Let's Encrypt-specific policy — every publicly trusted CA must follow the same validity-reduction schedule, making certificate lifecycle automation effectively mandatory going forward.

Sources

• Let's Encrypt Cuts Default Certificate Validity to 64 Days Ahead of 45-Day Switch — SecurityWeek
• Let's Encrypt TLS certificate lifetimes to drop from 90 to 64 days starting February 2027 — Help Net Security
• Let's Encrypt — Internet Security Research Group (ISRG)