Your Certificates Expire Every 64 Days From February. Is Anything Actually Renewing Them?

The Announcement That Turned a Cron Job Into a Roadmap Item

On October 7, 2026, Let's Encrypt published a short post with a long tail. From February 10, 2027, all subscribers will receive 64-day certificates by default unless they choose a shorter lifetime. The staging environment switches on October 14, 2026, existing certificates will not be revoked, and Let's Encrypt expects the last 90-day certificate to expire on May 11, 2027. The same post cuts the authorization reuse period from 30 days to 10, and says it will shrink to seven hours in 2028.

The post went quickly around Hacker News, Reddit's sysadmin communities and DevOps LinkedIn, mostly with the same reaction: this should be fine if your automation is good. That condition carries a lot of weight. Let's Encrypt itself tells operators to search for hard-coded renewal values like 83, 80 or 60 days in cron jobs, wrapper scripts and runbooks, which is a polite way of saying that a lot of renewal automation was built around the assumption that certificates last 90 days.

Let's Encrypt is also not the outlier here. It is moving early on a schedule that every publicly trusted certificate authority must follow. Teams that buy certificates from commercial CAs and renew them once a year by hand are on the same path, just with a slightly later start. The difference is that they have usually automated nothing at all.

For a CTO or head of platform, the useful framing is simple. Certificate renewal is moving from an annual task someone remembers to a continuous production system that has to run unattended. Like any production system, it needs an owner, monitoring, tests and a failure plan. Most organisations have none of those for their certificates today.

The Schedule Nobody Gets to Opt Out Of

The industry timeline comes from the CA/Browser Forum, the body where certificate authorities and browser makers agree the rules for publicly trusted certificates. In April 2025, its members passed Ballot SC-081v3, which reduces maximum certificate validity from 398 days to 47 days and SAN validation data reuse from 398 days to 10 days, in steps between March 2026 and March 2029. Certificate issuers voted 25 in favour, none against, with five abstentions, and Apple, Google, Microsoft and Mozilla all voted yes. Browsers enforce these rules, so there is no vendor you can switch to that escapes them.

The first step has already happened. DigiCert stopped issuing 397-day certificates on February 24, 2026 and moved to a 199-day maximum, ahead of the March 15, 2026 industry deadline. Its documentation lists the next step as 100 days from March 15, 2027, which DigiCert will implement as 99 days from early 2027, and 47 days after March 15, 2029. Commercial CAs issue slightly under each limit to leave room for time zone differences, so the practical deadline for each step comes a few weeks early.

Let's Encrypt's own path is set out in its December 2025 plan to move from 90 to 45 days: an opt-in 45-day profile from May 13, 2026, the 64-day default in February 2027, and a 45-day default with a seven-hour authorization reuse period from February 16, 2028. Changes reach staging about a month before production.

At 47 days, a certificate renewed at the usual two-thirds point is replaced roughly every month. A company with 2,000 public certificates moves from about 2,000 renewal events a year to well over 20,000. Nobody does that by hand, and nobody should be watching it happen in a spreadsheet.

Why the Old Way Breaks

Most renewal setups were designed around one fixed number. A cron job runs certbot every night and renews anything within 30 days of expiry. A script renews every 60 days. A runbook says to rotate the load balancer certificate in the first week of each quarter. Each of those worked for 90-day or one-year certificates, and each becomes wrong on a known date.

Let's Encrypt's guidance is direct: renewing at a hardcoded interval of 60 days will no longer be sufficient once 45-day certificates arrive, and clients should renew at about two-thirds of the way through a certificate's lifetime. A 60-day interval technically still works against a 64-day certificate, but it leaves four days of margin. One failed run over a long weekend, one DNS provider incident or one expired API token is enough to take a site down.

Shorter validation reuse is the less visible half of the change. Today many setups validate a domain once and then reissue for weeks without proving control again. At 10 days of reuse, and seven hours from 2028 for Let's Encrypt, nearly every renewal triggers a new challenge. If your DNS-01 validation relies on someone pasting a TXT record into a registrar's console, or your HTTP-01 challenge depends on a path that a new CDN rule now blocks, failures that used to happen once a year will happen every month.

Notifications are also going away. Let's Encrypt ended its expiration email service on June 4, 2025. Teams that treated those emails as their safety net no longer have one, and many have not noticed yet because nothing has expired.

Expired Certificates Already Take Production Down

Certificate expiry is not a theoretical risk that shorter lifetimes create. It already takes production systems down, often at organisations that would never expect it to. Keyfactor's September 2025 survey of 450 PKI practitioners at companies with at least 1,000 employees found that 86% had at least one outage from expired or mismanaged certificates in the past year, 31% had one at least quarterly and 10% had one every week. Only 17% reported complete, real-time visibility across their certificates, and only 46% had automated renewals.

The well-known incidents show how wide the damage can spread. In December 2018, millions of O2 customers in Great Britain and SoftBank users in Japan lost service when Ericsson equipment shut down because its software certificates had lapsed. In April 2023, Starlink suffered a multi-hour global outage, and Elon Musk posted that it was caused by expired ground station certificates, adding that SpaceX was scrubbing the system for other single-point vulnerabilities.

Both were organisations with large, capable engineering teams. The problem in each case was not technical difficulty. A certificate existed that nobody was tracking, in a place where nobody expected it to fail. Shorter lifetimes do not create that kind of blind spot, but they make it show up far more often. A certificate nobody owns used to fail once every year or two. From 2029, it will fail within weeks.

The same survey points at why automation alone does not fix it: 53% had automated at least part of their certificate lifecycle, but 40% reported only partial success and 7% said their efforts had failed entirely. Automating the certificates you know about while missing the ones you do not leaves you exactly as exposed as before.

Where Certificates Actually Hide

Ask most engineering teams how many certificates they run, and the answer covers the main web domains. The real number is usually several times higher, because certificates live wherever TLS terminates, and modern systems terminate TLS in a lot of places.

The usual suspects are cloud load balancers and API gateways with uploaded certificates, CDN configurations, Kubernetes ingress controllers, and service meshes. Below those sit the harder cases: Java keystores baked into container images, appliances such as firewalls, VPN concentrators and storage arrays that only accept certificates through a web UI, mail servers, legacy Windows hosts, staging environments that someone set up in 2023 and left running, and SaaS integrations where you uploaded a certificate for a custom domain once.

Then there are the dependencies that are not certificates themselves but break when certificates change. Mobile apps that pin a specific leaf certificate will reject a renewed one. Partners that allowlist your certificate fingerprint for mutual TLS will refuse connections after renewal. Monitoring checks that alert at 14 days before expiry will fire constantly against a 47-day certificate, until someone mutes them and they stop protecting anything.

Certificate Transparency logs are the fastest way to see your public footprint, because every publicly trusted certificate issued for your domains is recorded there. Comparing that list with what your automation actually manages usually turns up the gap within an afternoon. Internal certificates need a network scan and a look through infrastructure-as-code repositories.

What a Production-Grade Renewal Pipeline Looks Like

The target state is unattended renewal that you can see working. In practice, that means ACME everywhere it can reach, a clear plan for everything it cannot, and monitoring that checks the certificates actually served rather than the ones your tooling thinks it installed.

ACME clients should support ACME Renewal Information. RFC 9773, published in June 2025, lets a certificate authority suggest renewal windows to clients, which spreads renewal load and lets the CA trigger early renewal during a mass revocation. Let's Encrypt says that if your client supports ARI, it can tell your client when to renew, so lifetime changes need no configuration change. Clients without ARI should calculate renewal as a fraction of the lifetime of the certificate they hold, not a fixed number of days.

Validation needs the same attention. DNS-01 works for wildcard certificates and hosts that are not publicly reachable, but it should run with narrowly scoped DNS API credentials stored in a secrets manager, not a registrar login with access to everything. Let's Encrypt also expects DNS-PERSIST-01 to be available in 2026, a method where the DNS TXT record proving control does not have to change on every renewal. That will help with the shorter reuse windows, and it is worth tracking for setups where DNS changes go through a slow approval process.

For systems that cannot speak ACME, such as appliances, some SaaS platforms and older middleware, you need either a certificate lifecycle management platform with connectors that push renewed certificates through vendor APIs, or a documented and tested manual process with alerting set well ahead of expiry. For purely internal traffic, a private CA with its own short-lived certificates removes the dependency on public rules entirely, and is often the cleaner long-term answer for service-to-service TLS.

Finally, monitor what users see. A renewal job that succeeds but never reloads the web server, or that writes a new certificate to one node of a cluster but not the others, will pass every internal check and still serve an expired certificate. External probes that read the served certificate and alert when less than a third of its lifetime remains catch exactly that case.

A Plan That Fits Before February

There are four months between Let's Encrypt's staging switch and its production change, and about five before the 100-day public maximum. That is enough time to do this properly if the work starts now, and not enough if it waits for the first incident.

In the first month, build the inventory and assign owners. Pull every certificate for your domains from Certificate Transparency logs, scan internal ranges, and grep infrastructure repositories and runbooks for hard-coded renewal values, exactly as Let's Encrypt suggests. Point your non-production ACME clients at the staging environment and confirm they handle 64-day certificates and the shorter authorization reuse without errors.

In the second and third months, fix what the inventory found. Replace fixed-interval renewals with ARI or lifetime-based logic, move manual DNS validation to scoped API automation, remove leaf pinning from mobile apps in the next release cycle, agree a key rotation process with partners using mutual TLS, and put external expiry monitoring in front of every public endpoint. For appliances and SaaS platforms, decide case by case between connector automation, a private CA or a documented manual process.

In the fourth month, prove it works. Force early renewals in production during working hours, watch them complete and reload across every node, and run a game day where a renewal is deliberately broken to confirm the alerts reach a human who knows what to do. Then write down the owner of each certificate class, because the schedule tightens again in 2028 and 2029 and the people who did this work will not always be around.

Why This Is a Team Problem, Not a Ticket

Certificate automation sits in an awkward place in most organisations. It touches networking, platform, security, mobile and sometimes partner integrations, and it rarely belongs to a single team. That is why it so often ends up as a ticket that waits until something expires. It is also why it fits the same pattern we described in our look at 2026's outage year: the failures that hurt most are the ones in shared infrastructure nobody clearly owns.

The work itself is well understood but detailed: inventory, refactoring renewal scripts across many repositories, changing DNS credential handling, coordinating mobile releases, and building monitoring. It is exactly the kind of bounded platform project that internal teams struggle to prioritise against product work, and that a focused external team can finish in weeks. It also pairs naturally with other cryptographic housekeeping, including the inventory you will need for a post-quantum cryptography migration and the credential cleanup covered in our piece on secrets sprawl.

At Stepto, our cloud and DevOps engineers work as part of dedicated development teams that take on this kind of platform work end to end. We start with a full certificate inventory, replace fragile renewal logic with ACME and ARI-based automation, wire up external monitoring and alerting, and hand over runbooks and ownership maps your team can maintain. Where you already run Terraform, Kubernetes or a lifecycle management platform, we build on what is there rather than introducing another tool.

Our engineers work from Serbia on Central European time, which gives full working-day overlap with European clients and a useful daily window with US East Coast teams. That matters for work like this, where forced renewals and game days should happen while your own engineers are online to watch them. If February 2027 is closer than your current automation is ready for, a short engagement now costs far less than the outage it prevents.