Why Certificate Lifetimes Are Shrinking to 47 Days

A little over ten years ago you could buy a website certificate valid for up to five years and forget about it. Today public certificates last at most 200 days, from March 2027 only 100 days, and from March 2029 just 47 days. The CA/Browser Forum agreed this in 2025. This guide shows how certificate lifetimes have changed, sets out the exact timetable, explains the reasons and the odd number 47, and works out what it means for anyone running servers.

From five years to 47 days: a short history

The maximum lifetime of publicly trusted website certificates has fallen in stages:

until 2015: up to 60 months, about 5 years,
from April 2015: 39 months,
from March 2018: 825 days, just over 2 years,
from September 2020: 398 days, a year plus a month of slack. Apple pushed this change through, and Google and Mozilla followed.
from 15 March 2026: 200 days.

Let’s Encrypt took its own route from the start in 2015, issuing 90-day certificates that renew automatically right from the start. The certificate of this website is an example; see what is an X.509 certificate.

Bar chart: about 1,826 days until 2015, about 1,187 days from 2015, 825 days from 2018, 398 from 2020, 200 from 2026, 100 from 2027 and 47 days from 2029. — How the maximum lifetime has fallen since 2015.

The timetable to 2029

Ballot SC-081, passed in April 2025 with no votes against, sets this schedule:

from 15 March 2026: maximum lifetime 200 days; a domain validation may be reused for 200 days.
from 15 March 2027: maximum lifetime 100 days; domain validation reuse 100 days.
from 15 March 2029: maximum lifetime 47 days; a domain validation is valid for only 10 days.

Since March 2026, validated organisation details in OV and EV certificates may be at most 398 days old. Let’s Encrypt is moving faster: its standard certificates are due to drop to 64 days on 10 February 2027 and to 45 days on 16 February 2028. You can already choose 45-day certificates and short-lived 160-hour certificates there. Certificates from your own private CA are not covered by these rules.

Table: 200 days from 15 March 2026, 100 days from 15 March 2027, 47 days from 15 March 2029; domain validation is reusable for only 10 days at the end. — The CA/Browser Forum’s timetable to 2029.

Why lifetimes are getting shorter

Revocation works badly: a stolen key remains usable until the certificate expires if browsers never learn about the revocation; how certificate revocation works explains why. A short lifetime limits the damage automatically.
Information goes stale: domains change hands and companies change names. The shorter a certificate lasts, the more current the checked details are.
Faster change-overs: if an algorithm becomes unsafe, for example because of quantum computers, every certificate must be replaced. With 47-day certificates that happens by itself within weeks.
Automation becomes the norm: anyone who renews automatically can switch CAs quickly when a CA runs into trouble. When Chrome and Firefox stopped trusting Entrust in 2024, automated sites moved over with little effort.

Why 47 days?

The number looks odd, but it comes from a simple sum proposed by Apple, which put the ballot forward: the longest month of 31 days, plus half a 30-day month (15 days), plus 1 day of slack, gives 31 + 15 + 1 = 47. That way a site can renew monthly and still have a good two weeks in reserve if a renewal fails. By the same logic, 200 days is roughly six months plus slack and 100 days roughly three months plus slack.

What it means for site owners: a worked example

Dividing a year by the lifetime shows how often a certificate has to be replaced at the very least: 365 / 398 ≈ 0.9, 365 / 200 ≈ 1.8, 365 / 100 ≈ 3.7 and 365 / 47 ≈ 7.8. In practice you renew early, for example after two thirds of the lifetime; at 47 days that means renewing about every 30 days, or around 12 times a year.

An example with assumed figures: a business runs 50 certificates and needs 30 minutes to renew each one by hand (request, validation, installation, testing). With one renewal a year that is 50 × 0.5 h = 25 hours. With twelve renewals a year it is 50 × 12 × 0.5 h = 300 hours, almost two months of full-time work. At that point automation pays for itself, and a forgotten certificate shows up within weeks rather than after a year.

Bars: 365 divided by the lifetime gives 0.9, 1.8, 3.7 and 7.8 renewals a year; for 50 certificates the manual workload grows from 25 to 300 hours. — Minimum number of renewals and manual workload (assumed figures).

Automating with ACME

The answer is the ACME protocol, which Let’s Encrypt and now most commercial CAs use to issue certificates automatically. An ACME client on the server requests, validates and installs the certificate by itself:

certbot and acme.sh for traditional Linux servers,
web servers such as Caddy that manage certificates without any extra tool,
cert-manager for Kubernetes,
built-in ACME support in many routers, firewalls and hosting control panels.

Newer clients support ACME Renewal Information (ARI): the CA tells the client when to renew and can ask for an early renewal after an incident. Understanding the ACME protocol explains the process in detail. You still need monitoring that warns you when an automatic renewal fails.

Frequently asked questions

Do I need to do anything as an ordinary web user?

No. The change only affects people who run servers.

Will my existing certificates stop working?

No. A certificate stays valid until the expiry date written in it; the new limits apply to newly issued certificates.

Do the rules apply to certificates on a company network?

Only to publicly trusted certificates. A private internal CA can set longer lifetimes, even though shorter ones are a good idea.

Does a shorter certificate cost more?

Commercial CAs usually sell subscriptions of one or more years that include as many reissues as you need. Let’s Encrypt stays free.

Conclusion

The lifetime of public website certificates is falling from 398 days through 200 and 100 to 47 days in 2029. That limits the damage from stolen keys, keeps information current and makes it easier to switch to new algorithms. For anyone running servers, automating with ACME is no longer optional.