Every secure website relies on a small digital document, a TLS certificate, and the length of time that document stays valid has been shrinking for more than a decade. This article explains what the certificate does, why validity keeps getting shorter, and why the practical result is that renewal is turning into an automated background task.
What a TLS certificate actually does
TLS, short for Transport Layer Security, is the protocol that encrypts traffic between a browser and a website. The certificate is how a site proves it is who it claims to be. It is issued by a certificate authority, or CA, an organization that browsers trust to vouch for a domain name. When a browser connects, it checks that the certificate matches the domain, that a trusted CA signed it, and that it has not expired.
Expiry is the lever that matters here. A certificate carries a “not after” date, and once it passes, browsers show a full-page warning or refuse to connect. That makes the validity period a trade-off: a long one means fewer renewals, but a stolen or mistakenly issued certificate stays dangerous for longer.
A short history of shrinking lifetimes
Cloudflare, in a 2023 post on automating certificate validation, traced the accepted validity period over time. According to the company, certificates before 2011 could last up to 96 months, about eight years. The limit fell to 60 months (five years) in 2012, 39 months in 2015, 24 months in 2018 and 13 months in 2020. The same post said it expected 90-day certificates to become the standard, and noted that Let’s Encrypt and Google Trust Services already capped validity at 90 days.
Cloudflare is describing an industry trend in its own words, and the dates are the company’s account, not a rules document. Still, the direction is plain: each step cut the window in which a compromised or outdated certificate can be abused.
What is the 47-day plan?
In an August 2026 post about certificate monitoring, Cloudflare said the CA/Browser Forum had “voted to cut the maximum certificate lifetime to 47 days by 2029.” The CA/Browser Forum is the body where browser makers and certificate authorities agree the baseline rules that public certificates must follow.
That post gave no vote date, vote count or intermediate steps, and this article does not try to fill them in. Readers who need the exact schedule for planning, for example when a 100-day or 200-day limit takes effect, should consult the Forum’s published requirements directly. What can be said is that the end point is far shorter than the 13 months that applied in 2020.
Shorter validity is not only a future prospect. Cloudflare’s Radar analysis, published in September 2025, reported that the majority, 92%, of issued certificates already had durations between 47 and 100 days. In other words, much of the web has moved to short lifetimes ahead of the formal deadline, largely because automated issuance made it easy.
Why shorter is considered safer
The arguments for short certificates are fairly consistent across the industry, though they come mostly from browser and CA communities rather than from independent audits.
- Smaller exposure window. If a private key leaks or a certificate is issued in error, it stops working sooner.
- Weak revocation. Revocation, the process of declaring a certificate invalid before it expires, has historically been unreliable in practice. A short life reduces dependence on it.
- Fresher validation. Domain ownership changes hands. A short certificate forces the CA to re-check that the requester still controls the name.
- Agility. When cryptographic requirements change, shorter lifetimes mean old certificates age out faster.
There are costs too. More frequent renewals mean more chances for something to fail, and every failure lands on the site operator, not the CA.
How automated renewal works
The standard tool is ACME, the Automatic Certificate Management Environment, a protocol standardized by the IETF (Internet Engineering Task Force) that lets software request, validate and install certificates without human involvement.
The key step is domain control validation, or DCV. Cloudflare explains that the CA issues a token, and the domain owner must prove control by publishing it, either as a file at a specific web address or as a DNS TXT record, a text entry in the domain’s DNS settings. The relevant record sits under a label called _acme-challenge. If the token is found, the CA concludes the requester controls the domain and issues the certificate.
Wildcard certificates, which cover every subdomain of a name, add a wrinkle. Cloudflare notes that since a May 2021 CA/Browser Forum vote they require DNS-based validation, so a simple web-file check is not enough.
The hidden dependencies
Automation moves the failure points rather than removing them. A renewal can break when:
- DNS is hosted by a provider whose records the renewal software cannot edit automatically.
- A firewall or load balancer blocks the validation request.
- A certificate is installed on a device, such as a network appliance, that does not speak ACME.
- A forgotten test or legacy hostname still serves a certificate nobody owns.
Cloudflare’s post warned that, for customers hosting DNS elsewhere, tokens must be fetched and placed by hand at each renewal, which becomes a management burden quickly with more than ten domains. It also said missed renewals can cause “a certificate renewal failure and downtime.” DNS therefore sits at the heart of the process, a point covered in our explainer on how DNS works and why outages spread.
A worked example: what 47 days does to the workload
The arithmetic below is illustrative and assumes every certificate is renewed only once its previous one expires, which is a simplification, since in practice clients renew before expiry.
- A certificate valid for 90 days needs 365 ÷ 90 ≈ 4.06 issuances a year.
- A certificate valid for 47 days needs 365 ÷ 47 ≈ 7.77 issuances a year.
For an organization running 50 public certificates, that is roughly 203 issuances a year at 90 days and about 388 at 47 days, close to double. Done by hand, with someone logging in, pasting a token and installing a file, 388 tasks a year is not sustainable. Done by software, the count barely matters. This is the core reason the industry treats automation as a prerequisite rather than an optional extra.
| Validity period | Issuances per certificate per year | For 50 certificates |
|---|---|---|
| 90 days | about 4.1 | about 203 |
| 47 days | about 7.8 | about 388 |
Can renewal traffic overload the issuers?
One side effect is load on the CAs themselves. An IETF draft specification, ACME Renewal Information (ARI), describes the problem. It says most ACME clients decide when to renew using a fixed schedule such as a cron job (a timer on a computer), a set time before expiry, or a percentage of the lifetime, and that these approaches make it hard for a CA to change lifetimes and can cause renewals to bunch up, creating load spikes.
The draft’s remedy is for the CA to publish a suggested renewal window. A client asks for that window, picks a random time inside it, and renews then. The server can also steer clients away from a certificate that must be replaced early. The document is a draft, not a final standard, so details may change.
The concentration of issuance matters as well. In the same Radar analysis, Cloudflare said the Internet Security Research Group, which runs Let’s Encrypt, issues more than 66% of all certificates. It also referred to a July Let’s Encrypt API outage that reduced issuance rates. Heavy reliance on a few issuers is a resilience question similar to those in our look at why cloud outages spread so far.
What is still unknown, and what operators can do
Several questions remain open. The full Forum schedule was not available to this article, so intermediate deadlines are unconfirmed here. It is also unclear how quickly devices that cannot automate, such as some older appliances, will be replaced or wrapped in proxies. And while the safety case for shorter lifetimes is widely accepted among browser makers and CAs, independent measurements of how many incidents it prevents are limited.
Sensible preparation is not exotic:
- Inventory every public certificate and where it is installed.
- Use ACME-capable clients wherever the platform supports them.
- Monitor expiry dates independently and alert well before they pass.
- Subscribe to certificate transparency monitoring. Cloudflare describes certificate transparency as a set of public logs recording certificates, which browsers such as Chrome and Safari require, and which can alert owners when an unexpected certificate appears for their names.
- Review how encrypted connections are negotiated more broadly, including newer transports covered in our piece on HTTP/3 and QUIC.
Conclusion: renewal becomes infrastructure
Certificate lifetimes have fallen from years to months and are heading toward weeks. For individual site owners using a hosting platform, little changes, because the platform handles renewal. For organizations running their own servers, the shift turns certificates into something to be monitored like any other service. The main risk is not the shorter period itself but the forgotten certificate nobody automated.
This article is general information, not a substitute for professional security advice.
Sources: Cloudflare; Internet Engineering Task Force
