Certificate Lifetime Changes: 200, 100 and 47 Day Limits

The maximum lifetime of a publicly trusted TLS certificate is dropping from 398 days to 47 days in three steps. The CA/Browser Forum passed ballot SC-081v3 in April 2025 with 29 votes in favor and none against. Since March 15, 2026 the limit has been 200 days. It becomes 100 days on March 15, 2027 and 47 days on March 15, 2029. Domain validation reuse shrinks alongside it, down to 10 days by 2029. The practical effect is that manual certificate renewal stops being viable and expiry monitoring stops being optional.

What changed, exactly

Certificate lifetimes have been shrinking for over a decade. Five year certificates became three year certificates, then two, then 398 days in 2020. Ballot SC-081v3 is the first time the industry published a dated schedule for the rest of the journey rather than moving the limit once and waiting.

All four major browser vendors, Apple, Google, Mozilla and Microsoft, voted for it. That matters more than the certificate authorities' opinion, because the browsers are the ones that enforce root program rules. There is no realistic path where this gets reversed.

Read the last column again. A company running 50 certificates handled roughly one renewal a week under the old rules. At 47 days that becomes 388 renewals a year, which is more than one every single day including weekends. No spreadsheet and no calendar reminder survives that workload.

The schedule applies to certificates issued after each date, not to certificates already in the field. A 398 day certificate issued in February 2026 stays valid for its full term. That is why the change arrives quietly: nothing breaks on the cutover date, and the pressure builds over the following year as the long certificates age out.

Domain validation reuse is the part people miss

The same ballot shortens how long a certificate authority may reuse the evidence that you control a domain. That window drops to 10 days by 2029, from 398 days previously.

This is the more disruptive half for anyone renewing manually. Today a CA can often reissue against validation it performed months ago. Once reuse is measured in days, essentially every renewal requires a fresh domain control check, which means the DNS record or the HTTP challenge path has to work every time. A validation method that quietly broke six months ago will not be discovered at renewal time, because renewal time is now always.

Why the industry is doing this

Three reasons, and they are all about the same underlying problem: revocation does not work.

When a private key is stolen, the certificate is supposed to be revoked. In practice, revocation checking is inconsistent. Some clients do not check at all, some fail open when the revocation server is unreachable, and CRL and OCSP infrastructure has its own availability problems. A revoked certificate can keep being accepted by a meaningful share of clients. Shortening the lifetime is the blunt fix: a compromised certificate stops working on a known date whether or not anyone noticed the compromise.

Second, shorter lifetimes force domain ownership to be re-verified. Domains change hands. A certificate valid for over a year can outlive the relationship between the domain and the company that proved control of it.

Third, it lets the industry retire weak cryptography on a predictable timetable. When every certificate turns over several times a year, deprecating an algorithm takes months instead of years.

The unstated fourth reason is that shorter lifetimes force automation, and automated certificate management is more reliable than the human kind. That argument is genuinely correct, and it is also the thing that will cause real outages during the transition, because the automation has to actually be in place first.

What actually breaks

The failure mode is not that certificates expire faster. It is that the gap between the way most organizations manage certificates and the way the rules now require them to be managed gets wider every year.

The fourth row is the one worth dwelling on, because it is the trap. Teams that automate renewal often treat the problem as solved and stop watching. Renewal automation and expiry monitoring are two different controls. The first does the work; the second tells you when the first stopped working. Removing the second because you added the first is how well-run infrastructure ends up with an expired certificate.

Nobody knows how many certificates they have

Ask any team how many TLS certificates their organization owns and the answer is a guess. The certificates that cause outages are almost never the ones on the main website. They are the API subdomain set up three years ago, the staging host that quietly started taking production traffic, the vanity domain a campaign still points at, and the internal tool that someone exposed to the internet for a contractor.

Inventory is genuinely hard because ownership information is scattered across wikis, tickets, old Slack threads and the memory of people who have left. Some teams solve the discovery half by making it possible to search across every internal system at once so that finding who owns a given hostname stops being an archaeology project. Whatever the method, the inventory has to be built from what is actually resolving and serving traffic, not from what someone remembers provisioning.

A practical starting point: pull every hostname from your DNS zones, every SAN from every certificate you already know about, and every domain in your registrar accounts. The union of those three lists is usually 20 to 50 percent larger than the list people expected.

What to do about it

In order of leverage, not effort.

Step 2 sitting above step 3 is deliberate and it is the part most guidance gets backwards. Monitoring is cheap, quick and covers every certificate including the ones you cannot automate. Automation is the better long-term answer and takes months to roll out across a real estate of servers, appliances and vendor services. Putting monitoring first means you are protected during the years it takes to finish the automation.

If you want to see where a specific host stands right now, our SSL certificate checker reads the live certificate and reports the expiry date, days remaining, issuer, covered hostnames and whether the chain is complete. For ongoing coverage, SSL certificate monitoring runs that same check daily against every hostname you list and alerts before expiry rather than after.

Does this apply to internal and private certificates?

No. The CA/Browser Forum Baseline Requirements govern publicly trusted certificates, meaning the ones chaining to a root in the browser and operating system trust stores. A private certificate authority you run internally can issue certificates with whatever lifetime you choose, because your own devices trust your own root.

Two caveats. Private certificates still expire, and internal expiry outages are just as real, often more so because internal services get less attention. And organizations increasingly mirror the public schedule internally, on the reasoning that if the tooling has to handle 47 day certificates on the edge, it may as well handle them everywhere rather than maintaining two processes.

Frequently asked questions

How often do SSL certificates expire?

As of March 15, 2026 a publicly trusted certificate can be issued for at most 200 days. That drops to 100 days in March 2027 and 47 days in March 2029. Many certificates are already shorter than the maximum: Let's Encrypt issues 90 day certificates and has offered 6 day certificates since 2025, because short lifetimes are easy when renewal is fully automated.

Why do SSL certificates expire at all?

Because revocation is unreliable. If a private key is stolen, revoking the certificate should stop it being trusted, but many clients do not check revocation or fail open when the check is unreachable. A fixed expiry guarantees a compromised certificate stops working on a known date. Expiry also forces periodic re-verification of domain ownership and lets weak algorithms be retired on a schedule.

Will 47 day certificates be mandatory?

Yes, for publicly trusted certificates issued on or after March 15, 2029. It is a maximum rather than a target, so shorter is always allowed and longer is not. Certificates issued before that date keep the lifetime they were issued with, so the change rolls in over the following weeks rather than all at once.

What is the best practice for certificate lifetime?

Use the shortest lifetime your automation handles comfortably, and renew at roughly one third of the remaining lifetime rather than at a fixed number of days. Short certificates are safer, and they surface renewal problems while there is still time to fix them. A 47 day certificate that fails to renew gives you weeks of warning if you are watching; a 398 day certificate that fails gives you the same warning but you have had a year to forget the process existed.

How do I check when my certificate expires?

Run echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates to print the notBefore and notAfter dates, or use a checker that connects from outside your network. The -servername flag sends SNI and matters on any server hosting more than one site. For a certificate file on disk, openssl x509 -in cert.pem -noout -checkend 2592000 exits non-zero if it expires within 30 days, which drops straight into a script.

The short version

The 200 day limit is already here and the 47 day limit is scheduled. The certificates that will cause outages during this transition are not the ones on your main website, which someone is watching. They are the hosts nobody has listed, and the ACME jobs that stopped running without telling anyone. Build the inventory, monitor expiry on everything in it, and automate renewal behind that. If a certificate is going to expire, the goal is to find out with weeks to spare rather than from a customer.