TLS Certificate Lifetimes: 3 Critical Dates and 1 Costly Habit

TLS certificate lifetimes were capped at 200 days in March 2026, and in March 2027 the cap falls to 100. If your renewal process is a diary entry and a person who remembers, that process has about seven months left before it starts costing you outages rather than afternoons.

This is not a vendor scare story. It is a published schedule, voted through by the CA/Browser Forum in April 2025 and written into the Baseline Requirements that every publicly trusted certificate authority is audited against. Every date below comes from that document, or from the browser root policy that implements it.

Checked against version 2.2.9 of the Baseline Requirements, dated 6 August 2026 — nine days before this was published. The schedule has not moved since the ballot passed, which is worth saying because plenty of vendor timelines quietly have.

What the TLS certificate lifetimes rule actually says

The governing text for TLS certificate lifetimes is section 6.3.2 of the CA/Browser Forum Baseline Requirements, and it is unusually readable for a standards document. Four sentences, one per phase.

Certificates issued before 15 March 2026 could run to 398 days. Those issued on or after 15 March 2026 and before 15 March 2027 “SHOULD NOT have a Validity Period greater than 199 days and MUST NOT have a Validity Period greater than 200 days”. From 15 March 2027 the pair becomes 99 and 100. From 15 March 2029 it becomes 46 and 47.

Note the gap between SHOULD NOT and MUST NOT. The document explains it: a day is defined as exactly 86,400 seconds, and certificates “SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments”. In practice that is why your certificate authority sells you 199 days and not 200.

The change arrived through ballot SC-081v3, proposed by Apple and endorsed by Sectigo, Google Chrome and Mozilla. It passed with 25 certificate issuers in favour and none against, and all four certificate consumers — Apple, Google, Microsoft and Mozilla — voting yes. There is no dissenting bloc waiting to overturn it, and no browser that will keep trusting longer certificates out of sympathy.

The second clock nobody mentions

Shorter TLS certificate lifetimes are the headline. The change that actually breaks manual processes is in section 4.2.1, and it governs how long a certificate authority may reuse the proof that you control the domain.

That reuse window used to be 398 days. On 15 March 2026 it dropped to 200 days. On 15 March 2027 it drops to 100, and on 15 March 2029 it drops to ten. Separately, validation of subject identity information — the organisation details in an OV or EV certificate — fell from 825 days to 398.

The distinction matters because these are two independent clocks. A shorter certificate on its own means more renewals. A shorter validation reuse window means each renewal is more likely to require the domain control check to be performed again: a DNS record placed, an HTTP token served, a file put somewhere specific. That is the step people schedule a person for, and by 2029 a ten-day window makes doing it by hand plainly untenable.

The arithmetic behind shorter TLS certificate lifetimes

Nobody publishes a figure for how much work this adds, so here is the arithmetic rather than a borrowed statistic. These are our numbers derived from the published maxima, not the Forum’s.

A 398-day certificate needs renewing slightly less than once a year. A 200-day certificate needs it about 1.8 times a year, a 100-day certificate about 3.7 times, and a 47-day certificate about 7.8 times. Take whatever renewal work you did in 2025 and multiply it by roughly eight to see where 2029 lands.

One derived date is worth putting in your calendar now. The rule took effect on 15 March 2026, so the first certificates issued under the 200-day cap begin expiring around the start of October 2026 — and because most authorities issue at 199 days rather than 200, the leading edge of that wave lands in the last days of September. Roughly six weeks from this post. If your organisation renewed anything in March, that is when you find out whether the renewal was automated or merely done.

We are deliberately not quoting any of the outage percentages circulating with this story. Every one we chased led to a certificate vendor’s own blog rather than to measured data, and a number without a source is marketing wearing a lab coat.

Where the certificates actually are

Most organisations underestimate this badly, because they think of the website and stop. Shorter TLS certificate lifetimes are only a problem in proportion to how many certificates you have forgotten about.

The public website and any marketing subdomains, usually behind a CDN that may or may not renew on your behalf. The mail gateway. The VPN concentrator and the firewall’s administrative portal. A remote desktop or virtual desktop gateway. Load balancers and reverse proxies. Line-of-business applications published to the internet. And the awkward tail: network appliances, cameras, print servers and building systems that have a web interface, a certificate, and no automation story whatsoever.

Each one has an owner, a renewal method and a reload requirement, and in most estates none of the three is written down. That inventory is the actual deliverable here — the same argument our note on distributed IT architecture makes about every other component that got decided by default.

Why the reminder email stopped arriving

A lot of organisations have been running on a hidden dependency: the expiry warning from the certificate authority. That dependency is being removed across the industry, and the largest issuer removed it first.

Let’s Encrypt ended its expiration notification service on 4 June 2025. The stated reasons are worth reading in full, but the first one is the relevant one: “More and more of our subscribers have been able to put reliable automation in place.” The stored email addresses were deleted. The recommendation is to use independent monitoring instead.

So the safety net under manual renewal was quietly cut a year before TLS certificate lifetimes halved. If nobody at your organisation noticed, that is itself the finding — it means the emails were the control, and the control is gone.

Certificate expiry monitoring should be external to the thing being monitored, and it should alert a role rather than a person. An alert routed to someone who has left is indistinguishable from no alert at all until the morning it matters.

What automation actually requires

The mechanism is ACME, RFC 8555 — a standards-track protocol from March 2019 describing, in its own words, “a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance”. It is not new, not proprietary, and not limited to free certificates; most commercial authorities now offer an ACME endpoint.

The browsers have made their position explicit. Chrome Root Program Policy version 1.8 states that “routine certificate issuance and renewal SHOULD NOT involve human input except as needed for identity or business document verification”, and from 15 March 2027 every subordinate CA in the Chrome Root Store must be integrated with an automation solution.

Read that policy carefully, though, because it is precise about what it does not do. The same section says these requirements do not “require website operators to rely on the automation solution(s) for certificate issuance and renewal”, and do not prohibit authorities from continuing to offer non-automated methods. Nobody is going to force you to automate. Falling TLS certificate lifetimes are a pricing signal aimed at your process, not a mandate aimed at you — the 100-day cap simply makes the manual alternative expensive enough that the decision makes itself.

Two refinements are worth knowing. RFC 9773, published June 2025, adds ACME Renewal Information so a certificate authority can tell your client when to renew — which matters during a mass-revocation event, when everyone renewing at once is the problem. And the Baseline Requirements now define a “Short-lived Subscriber Certificate” as one valid for seven days or less, tightened from ten days on 15 March 2026. Those certificates are exempt from mandatory revocation: the document says plainly that “the CA MAY support revocation of Short-lived Subscriber Certificates”, where every other certificate must be revoked within 24 hours of a qualifying event.

That exemption is the real argument for short certificates. Revocation checking has never worked reliably in browsers; expiry always works. Let’s Encrypt made six-day certificates generally available on 15 January 2026 — a 160-hour validity under the profile name shortlived, sitting neatly under that seven-day bar. They are opt-in, and Let’s Encrypt says it has “no plan to make them the default at this time”, while signalling that its ordinary lifetime will fall “from 90 days down to 45 days over the next few years”.

When shorter TLS certificate lifetimes are not your problem

This is the section the certificate vendors leave out, so here it is.

The schedule governs publicly trusted certificates only. An internal certificate authority issuing to your own domain-joined machines is not bound by any of it. If you run a private PKI for internal services, nothing above applies to those certificates, and re-platforming them because of a headline about the public web would be work for its own sake.

It also does not apply to code signing, S/MIME or client authentication certificates, which have their own separate requirements and their own separate dates. If somebody has told you all your certificates now expire in 47 days, they have generalised from one document to four.

Automation itself is occasionally the wrong answer. An appliance whose firmware cannot import a certificate without a manual reboot is not made safer by an automated issuance job that leaves a fresh certificate sitting unused on disk — you have added a moving part and kept the outage. For those, the honest plan is a documented manual procedure with a named owner, a diarised date and monitoring, and a replacement decision at the next hardware refresh.

And it is not the most urgent thing in most estates. An organisation with standing global administrator rights and no tested restore is not made materially safer by tidier certificates. Our pieces on identity attacks and backup testing both describe failures that end businesses; an expired certificate is usually a bad afternoon.

Where you are on the timeline

Now, through 14 March 2027. The 200-day cap is live and the first certificates issued under it start expiring at the turn of October. This is the cheap window: everything still renews roughly twice a year, so there is time to inventory, automate and test before the cadence doubles.

From 15 March 2027. The cap becomes 100 days and domain validation reuse falls to 100 days with it. Manual renewal becomes a quarterly ritual across every certificate you own, and the certificate authorities themselves must be running automation by this date under the Chrome policy. If you arrive here without an inventory, the inventory gets built during an incident.

From 15 March 2029. Forty-seven days, with a ten-day validation reuse window. At that cadence a human process is not a process, and shorter TLS certificate lifetimes stop being a scheduling question and become an architectural one: anything that cannot renew unattended has to be fronted by something that can.

The part with no expiry date

Every date above will pass. The pattern will not, and it is the same pattern as the Windows 10 retirement we covered under Extended Security Updates: the deadline was published years ahead, in a document anyone could read, and almost nobody maintained a list.

A certificate inventory is that list for this problem. Every certificate, its common name, where it terminates, who owns it, how it renews, what has to be restarted afterwards, and the date it expires. It takes an afternoon to build and it converts every future change of this kind into a filtered view rather than a fire drill. Falling TLS certificate lifetimes are only the current reason to have one; the next reason will be something else entirely, published just as far in advance.

One control from the Baseline Requirements is worth borrowing for your own side of the fence. Section 6.5.1 requires that certificate authorities “SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance”. The account at your registrar or DNS provider that can approve a domain validation deserves the same treatment, because control of DNS is control of certificate issuance — a point our note on remote systems hardening makes about every other credential that quietly outranks its owner.

What to do in the next fortnight

Inventory first. Not the certificates you remember — the ones actually presented on every public endpoint you own. Certificate Transparency logs will show you certificates issued for your domains that nobody told you about, which is frequently the uncomfortable part.

Then, for each one, answer three questions: does it renew automatically, does the service reload automatically afterwards, and who gets alerted if neither happens. Anything with three no answers is a scheduled outage with a date already on it.

Then fix the reload, not just the issuance. Issuance is rarely what breaks; the service still holding the old certificate in memory a fortnight later is. Automating issuance without automating the reload creates a system that looks healthy and fails anyway — and that is exactly the shape of problem our automation and systems hardening work exists to remove.

Falling TLS certificate lifetimes are one published schedule of this kind; the European Union’s Cyber Resilience Act is another, and its first obligation lands on 11 September 2026 with no grandfathering for products already shipped.

If you would rather hand someone the estate and get back a list with dates against it, that is a conversation worth having. The dates in it will be the CA/Browser Forum’s, not ours.