47-Day TLS Certificates: The CA/Browser Forum SC-081 Timeline Explained
Publicly trusted TLS certificates are on a fixed path to 47-day lifetimes. The maximum fell from 398 to 200 days on , drops to 100 days on and to 47 days on . This guide explains the schedule, the rules that change with it, why it is happening and what it means for the number of renewals you handle.
Last reviewed:
The schedule at a glance
Ballot SC-081v3 amends the CA/Browser Forum TLS Baseline Requirements, the rules every publicly trusted certificate authority must follow. It cuts the maximum validity of a TLS server certificate in three steps, and shortens how long a CA may reuse an earlier domain-control check at the same time. The limit is decided by the date a certificate is issued, not the date it is installed.
| Certificates issued | Maximum validity | Domain validation reuse |
|---|---|---|
| Before | 398 days | 398 days |
| From | 200 days | 200 days |
| From | 100 days | 100 days |
| From | 47 days | 10 days |
The 200-day step is already in force: certificates issued since cannot be valid for longer. A certificate issued just before a cut-off keeps its full validity, so 398-day certificates issued in early March 2026 stay valid into 2027. Mixed lifetimes in one estate are normal during each transition.
The validity period is counted from the certificate's notBefore to its notAfter time. Issuing a longer certificate would break the Baseline Requirements, so a CA cannot offer one on request, whatever the price or product.
Domain validation reuse shrinks too
Before issuing a certificate, a CA must confirm that the requester controls each domain name in it (domain control validation, DCV). Until now a CA could rely on a completed check for up to 398 days, which is why a manually ordered certificate often did not need a new DNS record or file upload at every renewal.
SC-081v3 shortens that reuse period in step with the validity limit, ending at just 10 days for certificates issued from . In practice that means domain control is proven again for almost every issuance. A renewal process that still involves someone adding a DNS record by hand will hit that step every time, not once a year.
The ballot also shortens reuse of verified organization details (subject identity information, used in OV and EV certificates) from 825 to 398 days for certificates issued from . Domain-validated certificates, which carry no organization details, are not affected by that part.
Why lifetimes are getting shorter
A certificate is a statement about a point in time: this key belonged to this domain when the CA checked. The longer the certificate lives, the more likely that statement is out of date. The ballot's stated reasons follow from that.
Revocation does not work well enough
In theory, a certificate that is mis-issued or whose key leaks is revoked and clients stop trusting it. In practice, clients often cannot or do not check revocation reliably: lookups fail open when the responder is slow or blocked, and large revocation lists are expensive to distribute. A short lifetime puts a hard ceiling on how long a bad certificate stays usable, whether or not anyone checks its revocation status.
Stale data and validation errors age out faster
Domains change hands, hosting moves and validation methods turn out to be flawed. With shorter validity and reuse periods, a certificate based on outdated or wrongly validated information is replaced sooner by one based on a fresh check.
Crypto agility
When an algorithm, key size or certificate format has to be retired, the ecosystem can only move as fast as the longest-lived certificates expire. With 47-day certificates, a change rolls through every automated deployment within weeks. The same applies to replacing a CA intermediate or responding to a mass-revocation event.
Automation becomes the default
A renewal that happens once a year is easy to forget and hard to practise. One that happens every few weeks has to be automated, and automated renewals are the ones that keep working during an incident. See the guide to certificate renewal automation for how.
Who is affected, and who is not
The limits apply to publicly trusted TLS server certificates: the certificates browsers and operating systems accept out of the box for websites, APIs, login pages, customer portals and anything else reached over HTTPS from the public internet. Every CA in the public trust stores has to follow them, whether you buy the certificate or get it free.
They do not apply to:
- Private PKI: certificates issued by your own internal CA, trusted only on devices you configure. You set those lifetimes yourself.
- Certificates that are not TLS server certificates under the Baseline Requirements, such as code signing or client authentication certificates from a private CA.
The work lands wherever a public certificate is installed by hand: load balancers, CDN and hosting control panels, network appliances, management interfaces, and servers set up years ago with a certificate ordered through a reseller. These are also the places that are easiest to lose track of, which is why an inventory comes first. Certificate Transparency logs list every public certificate for your domain; the Certificate Transparency guide explains how to use them.
What it means in renewals per year
The simplest way to size the change is to count renewals. If a certificate is replaced exactly when it expires, it needs 365 ÷ lifetime renewals per year. This is the same calculation the Certificate Readiness Check uses for its projection.
| Maximum lifetime | Renewals per year | For 40 certificates |
|---|---|---|
| 398 days | 0.9 | 37 |
| 200 days | 1.8 | 73 |
| 100 days | 3.7 | 146 |
| 47 days | 7.8 | 311 |
That is a lower bound. Nobody waits until the last day: a common rule of thumb is to renew once about two-thirds of the lifetime has passed, which leaves time to retry if something fails. Each early renewal adds to the count, and with a 10-day validation reuse period nearly every one of them also needs a fresh domain check.
For a team that renews 40 certificates by hand today, the move from one or two renewals a year to about 8 per certificate per year turns an occasional chore into continuous work. If each manual renewal takes 30 minutes including validation, installation and checking, that is about 3 hours of renewal work every week of the year, before any early renewals.
How to prepare
- Build an inventory. List every public certificate, where it is installed and who renews it. Start from Certificate Transparency logs, then confirm what each host actually serves.
- Automate the easy majority. Web servers, reverse proxies and container platforms can renew through ACME today. Moving them first frees time for the hard cases.
- Plan for the hard cases. Appliances and services that cannot run an ACME client need a vendor integration, an API-driven upload, or a proxy in front that terminates TLS.
- Monitor what is served. Check expiry from the outside, on the certificate each host presents, so a renewal that succeeded on disk but never reached the server is caught.
- Rehearse. Shorten renewal intervals now, while the limit is 200 days, so problems surface before .
Frequently asked questions
Do I need to replace my current certificates now?
No. A certificate stays valid until its own expiry date. The new limits apply to certificates issued on or after each date, so you meet them at your next renewal.
Can I still buy a one-year certificate?
Some providers sell multi-year subscriptions, but the certificate itself can only be valid for the current maximum. Within the subscription the CA reissues it, and each reissued certificate still has to be installed.
Does this apply to certificates from my internal CA?
No. Certificates that chain to a private root you distribute yourself are outside the Baseline Requirements. Only publicly trusted TLS certificates are affected.
Could the dates change?
The schedule was adopted by ballot in April 2025 and is part of the Baseline Requirements. Like any part of them it can be amended by a later ballot. We check the dates against the ballot and the current requirements and show the review date at the top of this page.
Are wildcard or OV/EV certificates exempt?
No. The validity limit applies to every publicly trusted TLS server certificate, whatever its validation level or how many names it covers.
Our renewals are already automated for 90-day certificates. Are we done?
Probably, if your client decides when to renew from each certificate's actual lifetime, for example at two-thirds of it or from the CA's renewal information. Check for anything built on a fixed calendar instead, such as a job that renews every 60 days, and for steps after renewal that are still manual, such as copying the new certificate to another system.