Let's Encrypt moves to 64-day certificates on 10 February 2027; its last 90-day one should expire 11 May

Renew with 30 days left: day 60 at 90 days, day 15 at 45

A rule that renews a certificate when 30 days remain renews it on day 60 of a 90-day certificate, day 34 of a 64-day certificate and day 15 of a 45-day certificate (derived: the lifetime less 30). That is about 6.1, 10.7 and 24.3 renewals a year (derived: 365 divided by 60, 34 and 15). The rule has not changed. The certificate under it has. At 45 days it renews a certificate that is 15 days old, 24 times a year. Let's Encrypt, the non-profit certificate authority (CA), says that from 10 February 2027 any certificate it issues or renews will have a 64-day lifetime by default, that 45-day lifetimes follow in 2028, and that it expects the last 90-day certificate to expire on 11 May 2027 (its post of 7 October 2026).

This briefing reads Let's Encrypt's own pages, not the news about them. SecurityWeek and Help Net Security reported the change on 12 October 2026, and both match the source on the dates. The source is the 7 October post, read in full, with its post of 2 December 2025, its documentation on profiles, rate limits, staging and renewal, and the CA/Browser Forum Baseline Requirements, version 2.3.1 of 4 October 2026. One correction to how the change has been framed: the 64-day default on 10 February 2027 is not new. The December 2025 post already gave that date, the 45-day default of 16 February 2028 and the reuse changes, 309 days before the October post (derived). What October adds is the expected expiry of the last 90-day certificate, a date for testing in staging, 14 October 2026, and two practical hints: what to renew at, and what to search for in old scripts.

The expiry date checks. 10 February 2027 plus 90 days is 11 May 2027 (derived), which fits a switch at some hour on 10 February; the post does not give the hour.

What this does not establish is most of what an operator needs. It is one CA stating what it will do to its own certificates. It does not say how many certificates in any organisation are renewed by a person, whether your ACME client supports renewal information, which of your systems can run an ACME client at all, or which other CAs will follow and on what dates. Let's Encrypt's interest is plain: it runs the CA, and it says shorter lifetimes encourage automation, which it calls essential for ease of use and reliability (its lifetimes page). The sections below set out whose dates these are, what the same rule does at each lifetime, what the pages state and leave out, what the UK sources ask for, and an ordered checklist.

Whose dates these are: Let's Encrypt's, and the Forum's

The table sets Let's Encrypt's dates beside the maximums in the CA/Browser Forum Baseline Requirements, the rules that publicly trusted CAs follow. The Forum's schedule comes from ballot SC-081v3, which 25 certificate issuers and four browser makers (Apple, Google, Microsoft and Mozilla) voted for, with none against and five abstentions among issuers, on the Forum's results page.

Let's Encrypt's dates for its default (classic) profile, from its posts of 2 December 2025 and 7 October 2026 and its Upcoming Features page, against the Forum's maximums for certificates issued on that date, from Baseline Requirements 2.3.1 sections 4.2.1 and 6.3.2. Read on 12 October 2026.

Date	Let's Encrypt, default profile	Forum maximum: validity, reuse
Now, 12 Oct 2026	90 days, reuse 30 days	200 days, 200 days (since 15 Mar 2026)
14 Oct 2026	64-day certificates start in staging	200 days, 200 days
10 Feb 2027	64 days, reuse 10 days	200 days, 200 days
15 Mar 2027	No change stated	100 days, 100 days
11 May 2027	Last 90-day certificate expected to expire	Not applicable
16 Feb 2028	45 days, reuse 7 hours	100 days, 100 days
15 Mar 2029	No change stated	47 days, 10 days

Read the table sideways. The Forum sets maximums: section 6.3.2 of its text forbids a validity period over 100 days for certificates issued from 15 March 2027, falling to 47 days from 15 March 2029. Let's Encrypt sits under the maximum on every date. Its 64 days is 136 days under the 200-day maximum on 10 February 2027 and 36 days under the 100-day maximum from 15 March 2027, and its 45 days is already 2 days under the 47-day maximum of 2029 (all derived). The reuse period goes further: 10 days is the Forum's 2029 maximum for reusing a validation, reached 764 days early (derived).

Let's Encrypt says this in two forms. Its lifetimes page says industry rules will limit lifetimes to 47 days from 15 March 2029 and that it will therefore cut its maximum to 45 days by February 2028, and its profiles page describes the 45-day certificate as preparation for that limit. Its December 2025 post says the change is made as the Baseline Requirements require. Read against the table, what is required is the 2029 end state. Nothing the Forum requires puts 64 days on 10 February 2027. The step is Let's Encrypt's own pacing, and none of its pages presents it as the Forum's date. Section 6.3.2 sets maximums only, so a phrase such as the Forum's minimum is the wrong frame: there is a ceiling, and Let's Encrypt is going under it earlier than it has to.

Which other CAs follow, and when? The December post says all publicly trusted CAs will make similar changes. It names no CA and no date, and the October post does not repeat the sentence. The commercial CAs read for this briefing publish the Forum's schedule, not Let's Encrypt's. DigiCert's change calendar lists 99-day public TLS validity and a 99-day validation reuse period from 1 March 2027 (the Forum date is 15 March 2027) and 47-day validity from 1 March 2029, a date DigiCert marks as subject to change. GlobalSign's FAQ says it limits publicly trusted TLS certificates to 199 days against the Forum's 200. Sectigo and the other CAs were not read. So an estate that buys from more than one CA will hold 64-day, 99-day and 199-day certificates side by side from March 2027 (inference from those pages), and the 11 May 2027 date concerns only one of those sources.

The date also lands close to another on this site. Microsoft says a set of Windows Update certificates expires on 17 May and 19 June 2027, as set out in our briefing on the Windows Update certificates. 17 May is six days after 11 May (derived). The two are unrelated: one is a CA's lifetime change, the other a Microsoft signing-certificate rotation, and nothing in either source connects them. The only link is the calendar: a team that plans one change window for May 2027 will find two dated certificate events six days apart.

One more client-side change is signposted but is not part of these dates. Let's Encrypt's post of 3 June 2026 says it plans to support Merkle Tree Certificates for post-quantum authentication, with a staging environment targeted for late 2026 and production readiness for 2027, and that some changes will need client support. That is a format change, not a lifetime change. What the format does and does not protect is covered in our briefing on Cloudflare's post-quantum certificate authority, which had issued nothing at the time.

What the same renewal rule does at 90, 64 and 45 days

For clients that count days, Let's Encrypt's advice is to renew at about two-thirds of the lifetime. Its December 2025 post puts the failure plainly: "renewing at a hardcoded interval of 60 days will no longer be sufficient" once certificates last 45 days. The table runs the rules through the three lifetimes.

Renewal day and renewals a year by rule and lifetime. Derived from Let's Encrypt's lifetimes (90, 64 and 45 days); the 60-day row uses the interval its December 2025 post gives as its example. Day 0 is the day of issue. It models rules, not any client.

Rule	90 days	64 days	45 days
Two-thirds of lifetime: renew on day	60	42.7	30
Renew when 30 days remain: day	60	34	15
Renewals a year at two-thirds	6.1	8.6	12.2
Renewals a year at 30 days left	6.1	10.7	24.3
Renew every 60 days from issue: days left	30	4	Expired 15 days before

Three things follow. First, the two sensible-looking rules agree only at 90 days. The integration guide recommends, as a backstop to renewal information, renewing when a third of the total lifetime is left, and notes that for 90-day certificates that means 30 days before expiry. A fraction survives a change of lifetime. A count of 30 days does not. At 45 days the count renews at day 15, twice as often as the fraction (24.3 against 12.2 a year, derived). The NCSC's range, renewing with between a quarter and a third of the lifetime left, gives day 30 to 33.75 at 45 days and leaves 11.25 to 15 days to fix a failure (derived), against 22.5 to 30 days at 90.

Second, the client and its version decide which rule you have. Certbot's changelog says version 4.0.0 (7 April 2025) replaced a hardcoded renewal at 30 days before expiry with renewal when a third of the lifetime is left, and that the renew_before_expiry setting still overrides the new default, so a certificate whose configuration pins that setting keeps the old rule. Renewal information arrived in 4.1.0 (10 June 2025). In acme.sh's source on GitHub, tags 3.0.0, 3.0.7 and 3.1.0 set a default of 60 days from issue and contain no renewal information code, so a 45-day certificate would expire 14 days before the scheduled renewal (derived: it renews on day 59). The master branch, version 3.1.7, sets 30, follows renewal information and caps the schedule before expiry. The same client gives two answers, depending on the version installed.

Third, the numbers Let's Encrypt tells you to search for are open to two readings. Its post says to search cron jobs, wrapper scripts and runbooks for common hardcoded numbers such as 83, 80 or 60, and does not say whether they are days since issue or days remaining. As days since issue, 83 and 80 are longer than a 64-day certificate lives and 60 leaves 4 days (derived). As days remaining, 83 and 80 are longer than a 64-day lifetime, so the condition would be true at every run, and 60 would renew on day 4 (derived). Either reading is a reason to look. On Let's Encrypt's optional six-day profile, which lasts 160 hours, a threshold of 30 days left is satisfied at every run (derived: 30 days is 720 hours), so a client reading the number that way would try to renew whenever it ran.

The same arithmetic changes what an expiry alert means. Alerts are usually set in days, and the days have not moved.

What a fixed expiry alert consumes, and how long after a two-thirds renewal falls due it fires. Derived from the lifetimes in the table above; the alert days are common settings, not Let's Encrypt's.

Alert threshold	90 days	64 days	45 days
14 days left, share of the lifetime	15.6%	21.9%	31.1%
7 days left, share of the lifetime	7.8%	10.9%	15.6%
Days after a two-thirds renewal falls due that a 14-day alert fires	16	7.3	1
Days after a two-thirds renewal falls due that a 7-day alert fires	23	14.3	8

A 14-day alert was a warning that a job had failed to renew a certificate 16 days earlier. At 45 days it fires one day after the renewal fell due (derived), so it is close to a calendar event, and it fires for every certificate whose renewal is a day late. The NCSC says the renewal timeframe should leave enough time to detect and fix a renewal problem before the certificate expires. Do not expect the CA to tell you: Let's Encrypt's expiry email service ended on 4 June 2025, 495 days before this briefing (derived), and it points subscribers to third-party monitors.

What Let's Encrypt states, and what it leaves out

Each row is a claim as the coverage made it, set against Let's Encrypt's own words. The last column is what the same pages do not say. It is the column that matters for planning.

Claims in the 12 October coverage against Let's Encrypt's blog posts of 7 October 2026, 2 December 2025, 15 January 2026 and its documentation, all read on 12 October 2026. The middle column paraphrases.

Claim	What Let's Encrypt's pages say	Not stated
64-day default from 10 February 2027	Any certificate it issues or renews on or after that date gets 64 days. The same date was in the December 2025 post	The hour of the switch, and whether the date can move
Last 90-day certificate expires 11 May 2027	It expects the last 90-day certificate to expire on 11 May 2027, and says it will not revoke valid certificates in the process	Anything about other CAs' certificates
64-day certificates in staging this week	It will switch staging on 14 October 2026 and recommends testing there before production	Whether it has happened: it had not at the time of reading, two days earlier. The staging page, last updated 10 April 2026, does not mention it
Clients with ARI should be all set	Automated renewals with a client that supports ACME Renewal Info (ARI) should be fine, because ARI tells the client when to renew	Which clients and versions support it. The client list does not say. Your client's documentation decides
Hardcoded renewals should use two-thirds	Renew at about two-thirds of the lifetime; search scripts and runbooks for 83, 80 or 60	Whether those numbers are days since issue or days remaining
Reuse falls to 10 days, then 7 hours	From 30 days to 10 days, then seven hours in 2028; no change needed unless a client is built to rely on reuse	The date of the 10-day step in the October post (the December post gives 10 February 2027); which clients rely on reuse
Endpoints, chains and rate limits unaffected	Rate limits are not affected, and neither are ACME endpoints or issuance chains	The effect on your own retry behaviour or on non-ARI renewals with changed names
All publicly trusted CAs will follow	December 2025: all publicly trusted CAs will make similar changes	Any CA name or date. The October post does not repeat it
Shorter lifetimes limit the damage of a compromise	Reduces the risk of key compromise and mis-issuance; revocation is described as unreliable	Any figure for how much, or a case where it mattered

Rate limits hold; validation reuse is where the work moves

Let's Encrypt's rate limits page, updated on 5 August 2026, allows 5 certificates per exact set of names every 7 days (refilling at 1 every 34 hours), 50 per registered domain every 7 days and 300 new orders per account every 3 hours. Renewals that use renewal information are exempt from all rate limits. A renewal without it that asks for the exact same names is still exempt from the per-account and per-domain limits, but remains subject to the exact-set limit and the limit on authorisation failures.

Does a hardcoded 30-days-left rule stay inside that? Yes, by a wide margin. At 45 days it is a renewal every 15 days, 0.47 a week against a limit of 5 a week, or 9.3 per cent of the limit (derived). At 64 days it is 4.1 per cent and at 90 days 2.3 per cent (derived). Let's Encrypt's own February 2026 post says renewals will double (from day 60 of 90 to day 30 of 45) and that the limits need no change. What can still bite is a job that changes the names on a certificate, because that is a new order rather than a renewal, or one that retries failing validation: the limit is 5 failures per name per account per hour.

Validation reuse is different. Reuse is how long a completed check of control of a domain can back a new certificate. It falls from 30 days to 10 days, a cut of two-thirds (derived), and then to seven hours, 2.9 per cent of the 240 hours in 10 days (derived). Why seven hours? The Baseline Requirements' CAA rule (section 4.2.2.1) says a CA that issues after a CAA lookup must do so within the record's TTL or 8 hours, whichever is greater. Let's Encrypt says a reuse period shorter than that removes the need to look again, and its profiles page gives the 7 hours against 8 as the reason. How long a passed check can matter under the Forum's maximums is the subject of our briefing on the ccTLD registry hijacks, where it runs to 30 September 2027. Let's Encrypt's figures are far below that ceiling.

What changes in practice? A renewal on day 60 of 90 already comes more than 30 days after the previous check, so ordinary renewals have not been using reuse (inference from the dates). What uses reuse is a second order for the same name inside the window: a re-issue after a failed deployment, a second certificate for the same name, or a script that reorders in a loop. From 2027 those validate again. That costs most where validation needs a person or a credential: a DNS record edited by hand, or a DNS provider token nobody wants to give an unattended job. Let's Encrypt's December post says shorter lifetimes and reuse will make users demonstrate control more often, and points to a new DNS challenge, DNS-PERSIST-01, in which one standing record is set once. Whether that is live in production is not established: its February 2026 post targeted the second quarter of 2026, a staff reply on its forum on 7 May 2026 said it might ship in the third quarter, and its challenge-types page, last updated on 12 February 2026, does not list it.

The CAA record is the other change to plan. The NCSC recommends a CAA record for every domain, as specific as possible, using the accounturi and validationmethods parameters. The Forum's text says that from 15 March 2027 CAs must process those parameters, and DigiCert's calendar lists 1 March 2027 for its own checks. A record that names one ACME account will then be enforced by more CAs, and a client that changes account, after a reinstall or a move to a new host, may be refused by your own record (inference).

What shorter lifetimes limit, and what they do not

Let's Encrypt gives two reasons: shorter certificates limit the damage from mis-issuance and key compromise, and they encourage automation. Its six-day certificate post says why it leans on lifetime: revocation is unreliable, so relying parties can stay exposed until a certificate expires, which has been as long as 90 days. The Forum's ballot text goes further. It calls relying solely on revocation untenable and says certificate validity periods, and relying parties' enforcement of them, are very reliable. The NCSC agrees on the first half: its Web PKI guidance says a revocation cannot be guaranteed to reach every end user.

So what is the claim, exactly? It is a ceiling. The longest a stolen key or mis-issued certificate can be trusted is the lifetime: 90, then 64, then 45 days, which is 28.9 per cent and 50 per cent below the 90-day maximum (derived). If compromise could happen at any moment of a certificate's life with equal chance, the expected time left would be half the lifetime, 45, 32 and 22.5 days (derived, on that assumption). It is not a claim that the use stops sooner than the ceiling, that anyone notices, or that revocation can be dropped. None of the pages read gives a figure for harm avoided.

Two limits are worth stating. The ceiling applies to the certificate, and the NCSC advises generating a new private key at each renewal, because the old key is then no use to an attacker once the old certificate expires. A client set to keep the same key at renewal carries one key across many short certificates, so the shorter lifetime does not shorten that key's exposure (inference). And Let's Encrypt turned off its OCSP service on 6 August 2025 and publishes revocation by certificate revocation lists only, so whether a given client checks those lists is a question for that client's documentation.

Three friendly names, and what each one hides

Automated renewal is a client and a schedule, not a guarantee. In March 2026 a Shopify infrastructure engineer described, on Let's Encrypt's blog, a system that renewed at a static threshold of 30 days before the end of a 90-day lifetime, and said the rule was not resilient to a change of lifetime (post of 17 March 2026). That is the rule this briefing opens on, and it ran for millions of domains until the platform moved to renewal information. Administrators are asking the same question now: a thread on Let's Encrypt's community forum dated 9 October 2026 asks how and when to change the cron job once certificates last 64 days.

We use Let's Encrypt hides which of your systems can. Let's Encrypt's client list, updated on 22 July 2026, says the clients are third-party and that Let's Encrypt gives no guarantee about them. It does not say which support renewal information. The table below sets ten kinds of system against what that list shows and what it leaves out. No appliance vendor's or OT vendor's documentation was read for this briefing.

Ten kinds of system that may hold a Let's Encrypt certificate, against what Let's Encrypt's client list and integration guide name, read on 12 October 2026. The third column is what only your own documentation and inventory can answer.

Kind of system	Named by Let's Encrypt	Not stated
Web server or reverse proxy	Apache mod_md, an nginx module, HAProxy, Caddy, Traefik	Which version renews at a fraction or uses renewal information
Hosting control panel	cPanel, Plesk, ISPConfig, Virtualmin	Whether your panel still renews at a fixed day count
CDN, SaaS or managed hosting	The integration guide says the subscriber is whoever holds the private key, so for hosting that is the provider	Which of your names the provider renews, and with what rule
Kubernetes and containers	cert-manager, KCert; the guide warns that containers which issue at start-up and keep nothing can hit rate limits	Whether your pods store certificates durably
Windows servers and IIS	win-acme, Posh-ACME, Certify The Web and others	The version, and whether the scheduled task counts days
Load balancer or delivery appliance	No hardware vendor named	Whether your model runs ACME or only takes an uploaded certificate
Firewall or VPN gateway	pfSense is listed as an integration	Whether your product and version support ACME and reload after renewal
Mail server or mail gateway	The FAQ says certificates suit mail servers; Mail-in-a-Box is listed	Whether renewal reloads the service without a person
Embedded and IoT device	A client library for ESP32 boards and one for microcontrollers	Whether your firmware has any client, and who can update it
Industrial control and OT equipment	Nothing	Everything

Valid for 64 days hides that the failure mode is a calendar. An expired certificate is not an attack. It is a date that arrived with nobody holding it, and the result is an outage. The NCSC lists it as the second of three threats to a service that relies on the Web PKI: mis-management that leaves you with a weakened certificate or none. Shortening the lifetime makes that date arrive more often, and it only improves the position if the work behind each date has been automated.

What this means for UK organisations

NCSC guidance, as read. The NCSC's Provisioning and managing certificates in the Web PKI, published on 10 December 2025 as version 1.0, covers server certificates. It says: use automated provisioning and renewal; renew with between a quarter and a third of the lifetime remaining; consider renewal information (RFC 9773) if your CA supports it; generate a new key at each renewal; prepare for shorter lifetimes, down to 47 days in 2029; and, because lifetimes are shortening, monitor the certificate automation software itself so a fault is found and fixed before expiry. It also says to keep track of which certificates are in use where, to monitor Certificate Transparency logs for certificates you did not request, and to publish a CAA record for every domain. Its advice on revocation is not to rely on it.

NIS Regulations 2018, as read. Regulation 10(1) and (2) require an operator of essential services to take appropriate and proportionate technical and organisational measures to manage risks to its network and information systems and to prevent and minimise the impact of incidents, with a view to keeping the service continuous. Regulation 1 defines an incident as any event with an actual adverse effect on the security of those systems, and defines that security to include availability, among other properties. Regulation 11 requires an operator to notify its competent authority of an incident with a significant impact on continuity within 72 hours of becoming aware, judged by users affected, duration and area. My reading, which is not legal advice: an expired certificate that takes an essential service offline is an event affecting availability, so the duty to prevent it sits in regulation 10, and whether a given outage is notifiable under regulation 11 turns on those three factors and the competent authority's guidance. A Bill on network and information systems security, the Cyber Security and Resilience (Network and Information Systems) Bill, is in the Lords, with report stage listed for 26 October 2026 (provisional); its content was not read for this briefing.

Cyber Essentials v3.3, as read. The April 2026 Requirements for IT Infrastructure run to 26 pages. A text search of all of them for the words certificate, TLS and SSL finds nothing. Certificate expiry is not a requirement as v3.3 is written, so holding Cyber Essentials says nothing about it.

PCI DSS, only where it applies. In the PCI Security Standards Council's Self-Assessment Questionnaire D for merchants, for PCI DSS v4.0 (April 2022), requirement 4.2.1.1 asks for a maintained inventory of the trusted keys and certificates used to protect card numbers in transmission, and requirement 4.2.1 includes confirming that certificates protecting card numbers over open, public networks are valid and not expired or revoked. Both were best practice until 31 March 2025 and are required after it. That applies to organisations that send card numbers over open, public networks. The requirement was read through the Council's questionnaire, because the full standard document returned a block to a script and no attempt was made to get round it.

What an assessor or a board could ask for. An inventory of every public certificate with, for each: the issuer, the owner, where it is deployed, the renewal method (automated with renewal information, automated at a fixed interval, or by a person) and who is alerted. Evidence that expiry is monitored independently of the renewal job. The number of renewals that failed in the last 12 months and how each was found. And the count the question at the end asks for.

Ten actions, in the order worth doing

How this was read, and what was not

• Read in full. Let's Encrypt's posts of 7 October 2026, 2 December 2025, 15 January 2026, 18 February 2026, 24 February 2026, 17 March 2026, 3 June 2026, 26 June 2025 and 6 August 2025, and its profiles, rate limits, staging, integration guide, lifetimes, client list, monitoring, FAQ and Upcoming Features pages. The ACME directory answered with the three profiles, classic, tlsserver and shortlived.
• Rules. The Baseline Requirements version 2.3.1, sections 4.2.1, 4.2.2.1 and 6.3.2, and the SC-081v3 ballot page. The standard for renewal information is RFC 9773.
• UK. The NCSC Web PKI guidance and its blog post of 10 December 2025, the NIS Regulations 2018, Cyber Essentials v3.3, and the Council's questionnaire for PCI DSS.
• Pointers only. SecurityWeek and Help Net Security, 12 October 2026. Both match the source on the dates. Help Net Security adds that subscribers already on the 45-day or 6-day profiles are not affected, which the source supports.
• Not read. Any appliance, VPN, load balancer, mail gateway or OT vendor's documentation, Sectigo and other commercial CAs, anything on whether a CA other than Let's Encrypt will adopt 64 or 45 days, and the Bill's text.
• Time-stamped. Sources were read between 11:14 and 11:33 BST on Monday 12 October 2026. Staging had not yet switched at that time, and a page could change within hours.

The question that exposes the gap

How many of your public certificates are renewed by a person, and who is that person on the day the 45-day rule starts?

Key facts