47-day certificates: what changes and when
The industry agreed to shorten the life of publicly trusted certificates. This is not a proposal or a rumour: it is an approved schedule with fixed dates, and it is worth understanding before it arrives.
The schedule
| From | Maximum life |
|---|---|
| 15 March 2026 | 200 days |
| 15 March 2027 | 100 days |
| 15 March 2029 | 47 days |
Until 2026 a certificate could last 398 days, a little over a year. Today the cap is 200. In March 2027 it drops to 100, and in March 2029 to 47.
The number that matters is not the days but the renewals:
- at 398 days: one a year
- at 200 days: two a year
- at 100 days: four a year
- at 47 days: eight a year
And that is per certificate. If you look after ten domains, in 2029 that is eighty renewals a year, one every four or five working days.
The two clocks
This is the part most often misunderstood, so it is worth separating.
The term you buy is one thing. The life of the certificate is another.
You can buy a three-year order. That order runs for three years. What does not run for three years is the certificate inside it: that is issued for the maximum in force — 200 days today — and when it expires you reissue it at no cost and without buying again, as many times as it takes until the term you paid for runs out.
So buying three years is not buying a three-year certificate. It is buying three years of the right to hold a valid certificate. Reissuing is free and unlimited, and we tell you before each expiry.
That is why a long order still makes sense: it saves you buying again, even if it does not save you the reissues.
What to do
If you hold one or two certificates, watching for the notices and reissuing when they arrive is probably enough. That is two or three times a year today; in 2027 it will be four.
If you hold more than a handful, the question is no longer whether to automate but when. Eight renewals a year per certificate turn a minor chore into standing work, and the dangerous part is not the work: it is that one lapse takes the site down, and with eight chances a year the odds of a lapse stop being small.
If you run infrastructure that moves — containers, servers created and destroyed, environments rebuilt — manual renewal already does not fit today, let alone at 47 days.
The way out is the same in all three cases: let the server ask for and renew the certificate on its own. How that works is in What ACME is and how to automate your certificates.
Why they are shortening it
Two reasons, and both are good for whoever uses the certificate, even if they inconvenience whoever administers it.
The first is revocation. When a certificate is mis-issued or a key leaks, revoking it only half works: browsers do not always check the status, and a revoked certificate can still be accepted. A short-lived certificate revokes itself, by expiring.
The second is crypto agility. When the algorithms have to change — and they will, with post-quantum cryptography on the way — an estate of 47-day certificates turns over completely in under two months. One with year-long certificates takes a year.
What does not change
- The price. A certificate that lasts less does not cost less: you pay for the term of the order, not the life of the file.
- The validation. A DV is still validated against the domain; an OV still validates the organisation. What does shorten is how long a validation already done can be reused, so revalidation will come round more often too.
- The trust. The certificate your authority issues is the same one; it simply lasts less.
Next step
If you would rather stop watching the calendar, look at the automated certificates or the automation page, where the full comparison between doing it by hand and having it done already lives.
