Certificates now last 200 days, then 47: one renewal a year becomes eight

01The first of three cuts: 398 days to 200, then 100, then 47

The schedule comes from the CA/Browser Forum, the body where certificate authorities and browser makers agree the rules for public TLS certificates. Apple proposed the ballot, SC-081v3; Sectigo, Google Chrome and Mozilla endorsed it. When voting closed on 11 April 2025, 25 certificate issuers voted yes, none voted no and five abstained (Entrust, IdenTrust, Japan Registry Services, SECOM and TWCA). All four certificate consumers, Apple, Google, Microsoft and Mozilla, voted yes.¹

It is the fourth cut in eleven years. The Baseline Requirements capped certificates at 39 months from 2015, at 825 days from March 2018 and at 398 days from September 2020. The new steps are 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029.² DigiCert moved early: it set 24 February 2026 as the day it would start issuing at most 199 days, a day under the cap, so its systems were settled before the deadline.³

Nothing you already hold breaks today. The cap applies when a certificate is issued, so a 398-day certificate bought in February runs to its printed expiry; the new limit reaches it at its next renewal. That is why the change feels quiet now and will not by the end of the year.

02One renewal a year becomes eight

The arithmetic is simple. Divide a year by the maximum lifetime and you get the fewest renewals a certificate can need: under one a year at 398 days, almost two at 200, almost four at 100 and almost eight at 47. Nobody sensible renews on the last day, though. Let’s Encrypt tells clients that cannot ask the CA when to renew to renew about two-thirds of the way through a certificate’s life.⁴ On that schedule a 47-day certificate is replaced about every 31 days, nearly twelve times a year.

The hours are not the real risk. Each renewal is a chance to miss one, and a missed public certificate is an outage the moment it expires: browsers refuse the connection, and API clients fail without any warning to a person. Eight chances a year per certificate, instead of one, is what turns a calendar reminder into a liability.

03The quieter cut: proving you own the domain every ten days

Before a CA issues a certificate it must check that the applicant controls the domain, by finding a value it chose in a DNS record, on the website or in a reply to an email. The rules let a CA reuse that check for later certificates for a set period. Until 15 March 2026 that period was 398 days; it is now 200, falls to 100 in March 2027 and to 10 days in March 2029. Checks of the organisation’s identity, used in OV and EV certificates, may be reused for 398 days, down from 825.¹²

This is the change that breaks semi-manual processes. Many teams validate a domain once a year by approving an email sent to admin@ or webmaster@, then reissue freely for twelve months. From 2029 that approval would be needed for almost every certificate. And the email route itself is closing: the Baseline Requirements say CAs should not use the “constructed email” method from 15 March 2026 and must not rely on it from 15 March 2028, and a November 2025 ballot, SC090, phases out the remaining email- and phone-based methods.² What survives is a value placed in DNS or on the web server, which is exactly what software can do on its own. Let’s Encrypt plans to cut its own reuse period from 30 days to 7 hours by February 2028.⁴

04What automation is, and what it costs

The automation is a published standard. ACME, the Automatic Certificate Management Environment, became IETF RFC 8555 in March 2019.⁵ A small client on the server asks a CA for a certificate, proves control of the domain by answering the CA’s challenge, installs what it receives and does it again before expiry. A 2025 extension, ACME Renewal Information (RFC 9773), lets the CA tell the client when to renew, which matters when a CA has to replace certificates early.⁶⁴

The protocol costs nothing, and the cheapest certificates are free: Let’s Encrypt issues 90-day certificates today and plans 45-day ones as its default by February 2028, ahead of the industry cap.⁴ Cloud providers bundle renewal into their own services. AWS Certificate Manager gives public certificates at no charge to use inside AWS’s load balancers and CDN. When AWS launched certificates you can export to your own servers in June 2025, it priced them at $15 per name and $149 per wildcard, for a 395-day certificate paid once for its lifetime.⁷

The paid layer is certificate lifecycle management (CLM): software that discovers every certificate on the network and in the cloud, records who owns it and when it expires, enforces which CAs and key sizes are allowed, and pushes renewals to load balancers and servers through connectors. The enterprise suites are generally sold on quote and priced by the number of certificates managed. You need one when the inventory is the problem: several CAs, hundreds of certificates, nobody sure where each is installed. For a team with a few dozen certificates on servers that can run an ACME client, the free tools are enough.

05The certificates no script reaches: appliances

The hardest certificates are the ones inside boxes: firewall and VPN portals, load balancers, storage and server management consoles, printers, cameras. Many are installed by pasting a file into a web console, which no ACME client can do. Expired certificates inside equipment have taken down large networks before. In December 2018 Ericsson traced an outage at mobile operators in several countries to “an expired certificate in the software versions installed with these customers”, in its packet-core software.⁹

Some appliances have caught up. FortiOS 7.0 lets a FortiGate obtain and renew its own Let’s Encrypt certificate over ACME, with limits: the interface must be public with a DNS name, ports 80 and 443 must not be forwarded elsewhere, and the certificate covers the device’s own hostname only, with no wildcards.⁸ Check each model’s admin guide for the same feature rather than assuming it. Where it is missing there are three routes: a lifecycle tool with a connector for that vendor’s API, a reverse proxy or load balancer that renews automatically in front of the device, or, for a console only staff ever reach, a certificate from your own private CA, which the 200-day rule does not cover.

In order, before 15 March 2027:

1. Count them. List every public certificate, where it is installed, who owns it and how it renews today. Certificate Transparency logs show every public certificate issued for your domains, including ones nobody told IT about.
2. Automate the easy majority. Web servers, Kubernetes ingress and cloud load balancers move to ACME or the cloud provider’s managed certificates first.
3. Move validation to DNS. Replace email approvals with DNS-based validation that your automation can answer.
4. Sort the appliances. Mark each one ACME-capable, API-capable or neither, and put the “neither” list into the next refresh or behind a proxy.