If the last SSL certificate you dealt with was valid for a year, you're not out of date — you're just looking at a number that's already gone. Certificate lifespans have been shrinking for years, and there's a published, industry-agreed schedule that takes them a lot further, a lot faster, than most site owners realise.
This isn't a rumour or a "some browsers might start doing this" situation. It's a settled timeline from the body that effectively sets the rules for every publicly trusted certificate on the internet. Here's what's actually changing, why it's happening, and — the part that actually matters — what to do about it before it catches you out.
What's actually changing
The maximum lifespan of a publicly trusted SSL/TLS certificate is set by the CA/Browser Forum — a body made up of certificate authorities and browser vendors (Google, Apple, Mozilla, Microsoft, and others) that jointly decides the baseline rules everyone has to follow for a certificate to be trusted by default in a browser. When they change the maximum validity period, every certificate authority has to comply, and every browser enforces it.
Until March 2026, that maximum sat at 398 days — a little over a year, and the number most people still have in their head. But that milestone has already passed. As of 15 March 2026, the maximum dropped to 200 days, and the schedule doesn't stop there:
| Effective from | Maximum certificate validity |
|---|---|
| Until 15 March 2026 | 398 days (~13 months) |
| 15 March 2026 — today | 200 days (~6.5 months) |
| 15 March 2027 | 100 days |
| 15 March 2029 | 47 days |
We're already past the first cutover. As of 15 March 2026, any newly issued publicly trusted certificate is capped at 200 days — if you've renewed anything since then, it came in under this new limit whether you noticed or not. The next milestone, 100 days, lands in March 2027. The final step to 47 days lands in March 2029.
Each step applies to certificates issued after that date — existing certificates keep running to their original expiry, but every renewal after the cutover gets the new, shorter maximum. By 2029, the longest a publicly trusted certificate will be allowed to live is 47 days. That's under seven weeks.
Why the industry is doing this
This isn't change for its own sake. A few real problems drove it:
- Shrinking the blast radius of compromise. If a certificate's private key is ever exposed, or a certificate authority mis-issues a certificate it shouldn't have, a shorter lifespan limits how long that mistake can be exploited before it naturally expires.
- Forcing more frequent domain validation. Every renewal re-confirms you still control the domain. More frequent renewal means stale ownership records get caught and corrected faster — a domain that's changed hands or expired doesn't keep riding on someone else's old certificate for a year.
- Reducing reliance on revocation. Certificate revocation — telling the world a certificate should no longer be trusted before its expiry — has always been unreliable in practice; not every browser checks it consistently. Short lifespans reduce how much the ecosystem needs to depend on revocation working properly, because problems age out quickly regardless.
None of this is controversial among the people who build browsers and issue certificates. The direction has been well signposted for years — it's the pace, now that it's actually landing, that catches people off guard.
The part worth being honest about: at 47 days, you are not going to be renewing certificates by hand. Not sustainably, and not safely. If your current process for SSL renewal is "someone remembers, logs in, and clicks renew," this timeline turns that from an annual chore into something that will fail — not might fail, will fail — given enough certificates and enough time.
The good news: this problem is already solved
Here's the part that should be reassuring rather than alarming. Let's Encrypt, the free certificate authority that now issues a huge proportion of the web's certificates, has operated on a 90-day cycle since it launched — already shorter than even today's 200-day maximum, and built from day one around the assumption that certificates would be renewed automatically, not by hand.
The mechanism behind that is the ACME protocol (Automated Certificate Management Environment) — a standard way for a server to prove domain ownership and request a new certificate without a human clicking anything. If you're running Let's Encrypt through a tool like certbot, or through a reverse proxy that handles ACME for you (Nginx Proxy Manager, Caddy, Traefik, and most modern hosting control panels all do this), you are almost certainly already inside the world this schedule assumes. Your certificates already renew every 90 days without anyone touching them. A drop to 47 days is a smaller step for you than it is for someone still on a manually-issued, year-long commercial certificate.
The people this schedule genuinely disrupts are the ones still buying commercial certificates through a manual process — a yearly reminder email, a login to a certificate authority's portal, a manual CSR generation, a manual install. That process was already fragile at 398 days, and it's fragile now at 200. At 47, it's not viable at all.
The practical checklist
Regardless of which situation you're in, this is worth checking now — before the shorter cycles start landing on your actual certificates.
- Confirm auto-renewal is actually configured — not assumed. If you're on Let's Encrypt via certbot, run
certbot renew --dry-runand confirm it succeeds cleanly. If you're using a reverse proxy or control panel, check its SSL/certificate section shows an active auto-renew status, not just an installed certificate. - Test that renewal actually completes end-to-end, including any reload step. A certificate can renew successfully on disk while the web server keeps serving the old one until it's reloaded — confirm your renewal hook actually reloads Nginx/Apache/whatever's serving the site.
- Set up expiry monitoring independent of the renewal process itself. A cron job or uptime monitor that alerts you if a certificate is within, say, 14 days of expiry gives you a safety net if automation silently fails for any reason — DNS changes, a firewall rule blocking the ACME challenge, an expired API key with your certificate authority.
- Know your current certificate authority's automation story. If you're on a commercial certificate that isn't part of an automated renewal flow, this is the moment to either move it onto one, or move to a certificate authority (Let's Encrypt, ZeroSSL, or others supporting ACME) that will handle it for you.
- Check every domain, not just the obvious ones. Internal tools, staging environments, and API endpoints often get certificates set up once, manually, and then forgotten. Those are exactly the ones a shrinking lifespan will quietly take offline first.
If you're already running Let's Encrypt with tested, working auto-renewal: this entire industry shift will land on your infrastructure as a non-event. You're already renewing faster than the schedule requires, and the automation that makes 90 days painless makes 47 days equally painless. The work here is mostly about verifying that automation is genuinely solid, not building it from scratch.
Frequently asked questions
Why are SSL certificate lifespans getting shorter?
The CA/Browser Forum adopted a phased reduction to limit how long a compromised, misissued, or outdated certificate can remain trusted, and to force more frequent revalidation of domain ownership.
What will the maximum lifespan be by 2029?
47 days by March 2029, down from 398 days before March 2026. The maximum is currently 200 days (in force since 15 March 2026), with a further step down to 100 days from March 2027 before the final drop to 47 days. Each step applies to certificates issued after that date.
Can I still manually renew certificates once lifespans drop to 47 days?
Technically, but not sustainably — that's more than seven renewals a year per domain. Automation becomes effectively mandatory at that frequency.
What happens if a certificate expires?
Browsers block access with a prominent warning, and most visitors won't click through. Any other service relying on the same certificate — email, APIs — fails its TLS handshake too. The outage is immediate and highly visible, which is why monitoring matters as much as the fix itself.
Is free Let's Encrypt SSL affected by this?
Sites already running Let's Encrypt with working automation are largely unaffected — it already operates on a 90-day cycle built around automated renewal, which is already shorter than even today's 200-day maximum for other certificate authorities.
Not sure your renewal automation would actually survive the next deadline? Reviewing SSL automation, monitoring, and Linux server hardening is core to what we do. Get a straight answer on where your setup stands.
Get in touch →