TLS Certificate Lifetimes Drop to 47 Days by 2029: The Schedule

Event date: 2025-04-11 · Source: CA/Browser Forum, Ballot SC-081v3, published 2025-04-11. First step in effect since 2026-03-15.

What happened

On 11 April 2025 the CA/Browser Forum, the body in which certificate authorities and browser vendors agree on the rules for publicly trusted TLS certificates, finished voting on Ballot SC-081v3. The ballot passed with 25 certificate issuers and all 4 certificate consumers (browser and operating-system vendors) in favour, nobody against, and 5 issuers abstaining. It writes a schedule into the Baseline Requirements that reduces the maximum lifetime of a TLS certificate from 398 days to 47 days in three steps.

The first step is no longer in the future: it has applied since 15 March 2026.

The schedule

These figures are in sections 6.3.2 and 4.2.1 of the current Baseline Requirements:

Certificates issued on or after	Maximum validity	Maximum reuse of domain/IP validation
before 15 March 2026	398 days	398 days
15 March 2026	200 days	200 days
15 March 2027	100 days	100 days
15 March 2029	47 days	10 days

The second column is what everybody quotes. The third matters just as much: it is the period during which a CA may rely on an earlier proof that you control the domain. From March 2029 that proof is good for ten days, so in practice every renewal includes a fresh domain validation. The ballot also reduces the reuse period for validated organisation details (the identity information in OV and EV certificates) from 825 to 398 days.

Who is affected

Everyone who uses publicly trusted TLS certificates: websites, APIs, mail servers, VPN gateways, appliances. The limit applies to the certificate's issue date, so a certificate issued before a step keeps its original expiry date.

Not affected: certificates from a private CA that your own devices trust, because the Baseline Requirements only bind publicly trusted CAs. If you already use an ACME client with 90-day certificates, you are inside every limit until March 2029, and the last step then only changes the renewal interval.

What to do

Make an inventory. List every certificate, where it is installed and how it is renewed. The ones that hurt are the manual ones: an appliance with an upload form, a certificate pasted into a load balancer, a mail server somebody set up years ago.
Automate issuance and installation with ACME (RFC 8555) or your provider's API. Many CAs, including commercial ones, offer ACME today. A 100-day certificate renewed by hand means four or more renewals a year per host; a 47-day one means nobody does it by hand.
Automate domain validation too. With DNS-01, that means API access to your DNS zone for the ACME client, preferably limited to the _acme-challenge names.
Check your CAA records before switching CA or validation method, so that the new CA is allowed to issue.
Monitor expiry independently of the renewal job. Automation fails silently: a changed API token, a firewall rule, a moved DNS zone.
Buying multi-year plans is still possible, but they are subscriptions: the CA reissues a new, shorter certificate within the plan, and somebody or something has to install it each time.

$ echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
    | openssl x509 -noout -dates
notBefore=Sep  1 00:00:00 2026 GMT
notAfter=Mar 19 23:59:59 2027 GMT

How to check

The OrbitProbe SSL checker shows the issue date, the expiry date, the days remaining, the issuer and the names on the certificate a host serves right now. Run it for every hostname in your inventory, including the mail and API hosts people forget.

Background

Sources

CA/Browser Forum, Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods, voting ended 2025-04-11.
CA/Browser Forum, Baseline Requirements for TLS Server Certificates, sections 4.2.1 and 6.3.2, read 2026-09-21.