Let's Encrypt Reduces Certificates to 64 Days — And It's Just the Beginning

The Internet Security Research Group (ISRG), which operates Let's Encrypt, announced on October 7 that starting February 10, 2027, all certificates issued by the project will have their validity reduced from 90 to 64 days. This is the first reduction in the project's history since its launch in 2015, and marks the beginning of a gradual transformation in the digital infrastructure that secures billions of web connections.

The change applies automatically to the default ACME profile (`classic`) — the same one serving the vast majority of Let's Encrypt users. Those who already opted for short-lived profiles, such as `shortlived` (6 days) or `tlsserver` (45 days), will not be affected by the change but will continue to have even more aggressive options available.

Context: pressure from the CA/Browser Forum

The reduction does not arise from an isolated decision by Let's Encrypt. It is part of a schedule set by the CA/Browser Forum, the body that establishes technical rules for all certificate authorities (CAs) that want to integrate their certificates into major browsers. In December 2025, Ballot SC-081 was approved, instituting a progressive reduction in maximum certificate validity:

- March 2026: maximum validity reduced from 398 days to 200 days - March 2027: further reduction to 100 days - March 2029: the ceiling drops to 47 days

Let's Encrypt's 90-day certificates were already within the limits for 2026 and 2027, so the project had no operational urgency. Instead, it chose to move forward gradually, reducing to 64 days in February 2027 and then to 45 days in February 2028 — a year before the final deadline imposed by the Forum.

Why reduce validity?

Two arguments underpin the change. The first is security: certificates issued by mistake or with compromised keys remain valid for a shorter period, reducing the exposure window. The second is pragmatic: once certificate management is automated, short-lived certificates offer no practical disadvantage over long-lived ones — and this premise is exactly what Let's Encrypt designed for from the start.

Sarah Gran, ISRG's director of operations, emphasized in the announcement that the reduction also allows eliminating "CAA rechecks" — additional validations the system must perform when validation data is older than 7 hours. By reducing the authorization reuse period from 30 days to 10 days (and to 7 hours in 2028), the project simplifies its own validation infrastructure.

What might break

The big question for system administrators is compatibility with existing renewal tools. If the ACME client supports ARI (ACME Renewal Information), Let's Encrypt will inform when to renew automatically, and the administrator does not need to worry about validity. The problem is that ARI is relatively new, and an estimated significant share of deployments still uses fixed-schedule renewal.

For 90-day certificates, it is common to configure renewal at day 60. In that case, 64-day certificates would be renewed naturally before expiring — an intentional choice from the project, according to analysts. The real risk appears in 2028, when validity drops to 45 days: fixed schedules configured to renew at 60 days will already have expired.

Scott Helme, a security researcher and author of the Security.irl blog, observed that Let's Encrypt has always been ahead of the curve — launching with 90-day certificates when 3-year certificates were the norm — and this reduction is simply the continuation of that trend. "After more than a decade at 90 days, the default is finally moving, and in a little less than 18 months from now, every Let's Encrypt certificate will be valid for half as long as it is today!", he wrote.

How to prepare

Let's Encrypt has already begun the transition in the staging environment (October 14, 2026), allowing teams to test before the production change. The official recommendation is to verify whether the ACME client supports ARI and migrate to that approach whenever possible. For fixed-schedule configurations, the suggestion is to adjust renewal to approximately two-thirds of the validity — for a 64-day certificate, this means renewing on day 42 or 43.

The transition also calls for a review of expiration alerts: if a 64-day certificate is renewed on day 43, there is a 21-day window remaining. An alert configured for 30 days would arrive before the expected renewal, even when automation works correctly.

The broader landscape

Let's Encrypt has processed over 600 million certificates since its launch and is now responsible for approximately 40% of active TLS/SSL certificates on the web. The change to 64 days affects not just website owners, but the entire chain of certificate management tools — from infrastructure managers like Ansible and Terraform to hosting platforms that issue certificates automatically for thousands of clients.

The reduction from 90 to 64 days is, in fact, just the first stop on a journey that ends at 45 days in less than two years. If the ecosystem can adapt without significant disruptions, the next question will be how much more the web can shorten validity without compromising its availability — and whether, at the limit, total certificate automation will become the only viable path forward for the internet as we know it.

Sources: Let's Encrypt Blog, Scott Helme — Security.irl, UptimeObserver

✓ Independent sources cross-checked and verified before publishing