Let's Encrypt shifts to 64-day certificate lifetimes in February 2027

Let’s Encrypt announced a significant shift in its certificate issuance policy, moving to a default lifetime of 64 days for all new and renewed certificates. This change takes effect on February 10, 2027, impacting millions of websites and services that rely on the nonprofit certificate authority for automated TLS security. The transition aims to reduce the window of risk associated with compromised keys or mis-issued certificates, aligning with broader industry trends toward shorter validity periods.

What happened

The Internet Security Research Group (ISRG), the nonprofit behind Let’s Encrypt, confirmed that starting February 10, 2027, every certificate issued or renewed will have a validity period of just 64 days unless the subscriber explicitly chooses an even shorter duration. Previously, the standard lifetime was 90 days. This means the last 90-day certificate issued under the old policy will naturally expire on May 11, 2027. ISRG clarified that they will not revoke any valid certificates during this transition; the change applies only to new issuances and renewals after the cutoff date.

To help administrators prepare, Let’s Encrypt will enable 64-day certificates in their staging environment on October 14, 2026. This early access allows developers and system administrators to test their automation scripts and ACME clients against the new timeline before it hits production systems. The organization emphasizes that this move is part of a longer roadmap, with default lifetimes expected to drop further to 45 days in 2028. By adjusting now, teams can build resilience into their infrastructure for future reductions without facing repeated emergency updates.

Key details

• Effective date: All new and renewed certificates will have a 64-day lifetime starting February 10, 2027.
• Staging availability: Testing for 64-day certificates begins in the staging environment on October 14, 2026.
• Final 90-day expiry: The last existing 90-day certificate will expire on May 11, 2027.
• Authorization reuse reduction: The validation reuse period drops from 30 days to 10 days immediately, shrinking to seven hours in 2028.
• No revocations: Valid certificates issued before the change will remain active until their natural expiration.
• Rate limits: Existing rate limits for certificate issuance remain unchanged.

Background

TLS certificates are digital credentials that verify the identity of a website and encrypt data transmitted between the server and the user’s browser. Historically, these certificates were valid for one to three years, but security best practices have pushed for shorter lifetimes to limit the damage if a private key is stolen or if a certificate is issued in error. Let’s Encrypt automates this process using the ACME protocol, which allows servers to request and renew certificates without manual intervention.

A critical component of modern ACME clients is ACME Renewal Info (ARI), a feature that lets the certificate authority tell the client exactly when to renew. If your automation relies on ARI, it dynamically adjusts to lifetime changes. However, many legacy setups use hard-coded timers, such as cron jobs set to renew 30 days before expiration. With a 64-day lifetime, a fixed 30-day buffer leaves little room for error, and future reductions to 45 days will break these static schedules entirely. Additionally, the reduction in authorization reuse periods means that validation data expires faster, requiring more frequent checks during the issuance process.

Why it matters

For teams running self-hosted software, this change demands a review of current renewal automation. If your system uses hard-coded values like "renew 60 days before expiry" or "check every 80 days," it will fail or behave unpredictably under the new 64-day regime. The recommended practice is to renew at approximately two-thirds of the certificate’s lifetime. For a 64-day cert, this means renewing around day 42. Failing to adjust these timers can lead to service outages when certificates expire unexpectedly, causing browser warnings and loss of user trust.

Beyond renewal timing, the shorter lifecycle increases the frequency of deployment events. Each renewal requires the new certificate to be installed and the web server or application to reload its configuration. If your deployment pipeline is fragile or manual, doubling the renewal frequency compared to the old 90-day standard increases operational overhead. This is an opportune moment to automate not just the acquisition of the certificate, but also its installation and service restart, ensuring that shorter lifetimes do not translate into higher maintenance burdens.

What you can do

• Test in staging: Use the Let’s Encrypt staging environment after October 14, 2026, to validate your ACME client’s behavior with 64-day certificates.
• Audit hard-coded timers: Search your cron jobs, scripts, and runbooks for numbers like 83, 80, or 60, and replace them with dynamic logic based on two-thirds of the current lifetime.
• Verify ARI support: Check your ACME client’s documentation to confirm it supports ACME Renewal Info (ARI), which automatically handles schedule adjustments.
• Automate deployment: Ensure your server reloads or restarts automatically after a new certificate is installed to avoid serving expired certs.
• Monitor expiry dates: Implement external monitoring that alerts you if a certificate is nearing expiration, providing a safety net if automation fails.
• Review validation logic: If you have custom ACME clients, ensure they do not rely on long authorization reuse periods, as these will shrink to 10 days soon and seven hours in 2028.