IT Infrastructure

SSL Certificate Lifespans Are Shrinking: The Road to 47 Days

Illustration of ssl certificate lifespans shrinking across a row of progressively smaller certificate shields

For most of the web’s history, an SSL/TLS certificate was a once-a-year chore. You bought a certificate, installed it, set a calendar reminder, and forgot about it until the reminder fired thirteen months later. That era is ending. SSL certificate lifespans are being cut sharply over the next few years, from a maximum of roughly 398 days today down to just 47 days by March 2029. If your renewal process still involves a human and a calendar, this change is going to find you.

This is the first of a two-part series on what is happening to public TLS certificates and why it matters for anyone who runs a website. Part one covers the shrinking validity window and what to do about it. If you want a refresher on what these certificates actually are and what they protect, our plain-English guide to HTTPS and SSL/TLS is the place to start.

What actually changed

In April 2025 the CA/Browser Forum, the industry body that sets the ground rules Certificate Authorities and browsers agree to follow, passed a measure called Ballot SC-081 (formally SC-081v3). It amends the TLS Baseline Requirements to phase down the maximum lifetime of a publicly trusted certificate on a fixed schedule. The vote was 29 in favour and none against, and the original proposal came from Apple. When the browser makers and the CAs agree unanimously, the schedule is effectively locked in.

Here is the timeline for the maximum certificate lifetime:

  • Before March 15, 2026: up to 398 days.
  • March 15, 2026: maximum drops to 200 days.
  • March 15, 2027: maximum drops to 100 days.
  • March 15, 2029: maximum drops to 47 days.

Note that these are ceilings, not targets. A Certificate Authority can (and increasingly will) issue certificates shorter than the maximum, and many already moved ahead of the deadline. DigiCert began issuing 199-day certificates on February 24, 2026, and Sectigo followed on March 12, both acting early to leave no room for misissuance. So the practical shift toward shorter SSL certificate lifespans is already underway, not something that starts in 2029.

The domain validation clock is shrinking too

The certificate lifetime is only half of SC-081. The ballot also cuts the period during which a Certificate Authority can reuse your domain validation data. Domain Control Validation (DCV) is the step where the CA confirms you actually control the domain before it issues a certificate, usually by checking a DNS record, a file on your server, or a response to an email. Until now, a CA could reuse a successful validation for up to about 398 days, so you proved control once and coasted for a year.

That reuse window is closing on a parallel track: 200 days from March 15, 2026, then 100 days in 2027, then just 10 days by March 15, 2029. The effect compounds with the shorter certificate lifetime. By 2029, a certificate lasts 47 days and the underlying proof of domain control has to be refreshed roughly every 10 days. In practical terms, you will be re-proving ownership of each domain dozens of times per year rather than once. Manual validation at that cadence is not realistic for anyone.

Why the industry is doing this

Shorter SSL certificate lifespans are not change for its own sake. There are a few solid reasons behind the schedule.

Revocation does not work well. When a certificate’s private key is compromised, the theory is that the CA revokes it and browsers stop trusting it. In practice the revocation systems (CRL and OCSP) are slow, inconsistently checked, and easy to bypass. A shorter lifetime is a blunt but reliable fix: even if revocation fails, a compromised certificate expires on its own within weeks instead of lingering for over a year.

It shrinks the exposure window. If an attacker gets hold of a private key, they can impersonate your site until that certificate expires. Cutting the maximum from 398 days to 47 days shrinks the worst-case exposure by nearly an order of magnitude.

It retires weak cryptography faster. When certificates turn over quickly, the whole ecosystem can move off deprecated algorithms and key sizes in months rather than years. This matters more as post-quantum cryptography moves from theory toward deployment.

It forces automation. This is the real goal, stated openly by the people who wrote the ballot. Annual manual renewal has always been fragile, and the single most common cause of unexpected outages on otherwise healthy sites is an expired certificate nobody noticed. Making manual renewal impossible pushes the entire web toward automated issuance, which is more reliable once it is set up.

What this means for site owners

If your certificates are already managed automatically, this whole change is close to a non-event. You may not even notice the numbers tick down, and that describes most people on modern hosting. It is the outcome the CA/Browser Forum is steering everyone toward.

If you renew by hand, the math gets uncomfortable. A certificate you touched once a year in 2025 needs attention roughly eight times a year by 2029, and the domain validation behind it refreshes even more often. Multiply that across every domain and subdomain and manual management stops being a chore and becomes a standing risk of downtime. Every hand renewal is another chance to forget one, fat-finger a config, or let a certificate lapse over a holiday weekend.

The good news is that the tooling to avoid all of this already exists and is mostly free.

How to get ahead of it

You do not need to overhaul anything this week, but the direction is clear. A few practical steps:

Automate issuance and renewal. The ACME protocol (the same standard behind Let’s Encrypt) lets a client request, validate, install, and renew certificates with no human in the loop. Most Certificate Authorities now support ACME, and clients like Certbot, acme.sh, and Caddy’s built-in automation handle it end to end. Set the renewal to run well before expiry and the shorter lifetimes simply stop mattering.

Lean on your host or CDN. Many platforms handle TLS entirely for you. Managed WordPress hosts, for example, typically provision and renew certificates automatically, which is one of the quieter reasons they are worth the money. If you are weighing providers, our guide on how to choose a managed WordPress host covers what to look for. A CDN like Cloudflare will also manage certificates at its edge on your behalf, so the shrinking lifetimes become the provider’s problem rather than yours.

Inventory your certificates. You cannot automate what you do not know about. Find every certificate you own, including the ones on internal tools, staging environments, mail servers, and that one legacy app someone set up years ago. The certificates most likely to lapse are the ones nobody remembers.

Shorten your monitoring windows. If you keep any manual certificates, expiry alerts set for a 30-day warning made sense in the 398-day era. With 47-day certificates that warning fires when the certificate is already more than half spent. Tighten the alerting to match the new cadence, and monitor for actual expiry, not just calendar dates.

Plan for the deadlines, not the panic. The March 2026, 2027, and 2029 dates are known years in advance. Treat each one as a checkpoint to confirm your automation still works rather than a fire drill.

There is one more piece of SC-081 worth flagging. Alongside the shorter lifetimes, the ballot also begins removing the clientAuth extended key usage from public TLS certificates, ending the long-standing practice of using a single certificate for both server and client authentication. That change has its own timeline and its own set of gotchas for anyone relying on so-called dual-use certificates, and it is the subject of part two in this series.

For now, the headline is simple. SSL certificate lifespans are getting shorter on a fixed, unavoidable schedule, and the answer is automation. Get your certificate management on autopilot and the countdown to 47 days becomes someone else’s problem.

Frequently Asked Questions

What is the new maximum SSL certificate lifespan?

It depends on the date. Under CA/Browser Forum Ballot SC-081, the maximum drops from about 398 days to 200 days on March 15, 2026, to 100 days in 2027, and to 47 days in 2029. Those are ceilings, so Certificate Authorities can issue shorter certificates, and several moved below 200 days ahead of the first deadline.

Why are SSL certificate lifespans being reduced?

Three main reasons. Certificate revocation systems are unreliable, so a short lifetime is a more dependable way to retire a compromised certificate. Shorter certificates shrink the window an attacker can exploit a stolen private key. And the whole schedule is designed to push site owners toward automated renewal, which is far less prone to the surprise outages that manual annual renewal causes.

Do I have to do anything if my host manages certificates for me?

Probably not. If your hosting provider or CDN issues and renews certificates automatically, the shrinking lifetimes are handled behind the scenes and you likely will not notice the change. This covers most people on modern managed hosting, which is exactly the outcome the new rules are encouraging.

What is ACME and why does it matter now?

ACME is the automated protocol that lets software request, validate, install, and renew certificates without a person involved. It is the same standard behind Let’s Encrypt and is now supported by most Certificate Authorities. With certificates renewing as often as every few weeks by 2029, ACME (via clients like Certbot, acme.sh, or Caddy) is the practical way to keep up without constant manual work.

What happens if my certificate expires under the new rules?

The same thing that always happens: browsers show a full-page security warning and visitors cannot reach your site safely. The difference is that with certificates lasting weeks instead of a year, there are far more expiry dates to miss, which is why automated renewal and tighter monitoring matter more than before.

Is the domain validation reuse period changing too?

Yes. Alongside the certificate lifetime, SC-081 shortens how long a Certificate Authority can reuse your domain control validation. It drops from about 398 days to 200 days in 2026, 100 days in 2027, and just 10 days by March 2029. By then you will be re-proving domain ownership many times a year, which is another reason manual processes stop being workable.

Does this affect free certificates like Let’s Encrypt?

Free certificates were already short. Let’s Encrypt has issued 90-day certificates for years and expects automated renewal, so its users already live in the world SC-081 is creating. The industry is moving toward the model Let’s Encrypt pioneered, not away from it.

When do the certificate lifespan changes take effect?

On a fixed schedule set by the CA/Browser Forum: 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. Some Certificate Authorities began issuing shorter certificates ahead of the first date, so the trend is already visible today rather than something that waits until 2029.

Digital Matters

IT Infrastructure Desk