47-Day Certificates Are Coming — What SC-081 Means for Your Renewal Process

The CA/Browser Forum — the industry body where certificate authorities and browser vendors set the rules for public TLS — has just passed ballot SC-081, and it's the biggest change to certificate lifetimes in years. Today you can buy a certificate valid for 398 days. Over the next four years, that ceiling steps down to 47 days. If your renewal process involves a calendar reminder and a human clicking through a CA portal, this ballot just scheduled its funeral.

What SC-081 actually says

The new maximum certificate lifetimes phase in on a fixed timetable:

• Today: 398 days — roughly 13 months, the limit in place since 2020.
• March 2026: maximum drops to 200 days — you'll renew at least twice a year.
• March 2027: maximum drops to 100 days — roughly quarterly renewals.
• March 2029: maximum drops to 47 days — a renewal every month and a half, forever.

The ballot also shortens how long domain-control validation can be reused, stepping down over the same period until validation is only good for about 10 days by 2029 — meaning even the proof that you own the domain has to be re-established almost every issuance. This isn't a proposal to watch; the ballot has passed. Barring the unexpected, these dates are now the rules of the public web.

Why the industry is doing this

Shorter lifetimes aren't bureaucratic sadism — they attack a real weakness:

• Revocation doesn't really work. When a private key is compromised or a certificate is mis-issued, revoking it should protect users. In practice, browsers' handling of revocation checks is patchy at best — a revoked certificate often keeps working. The pragmatic fix: make certificates expire so fast that a bad one has a short shelf life no matter what.
• Stale validation is a risk. A domain you validated 13 months ago may have changed hands since. Shorter validation reuse shrinks that window.
• Agility. When the ecosystem needs to migrate — new key types, deprecated algorithms, a distrusted CA — short-lived certificates turn a multi-year slog into a few renewal cycles.

You can debate the trade-offs, but the direction has been consistent for a decade: five-year certificates became three, then two, then 398 days. 47 is the same trend, accelerated.

Manual renewal is dead — it just doesn't know it yet

Do the arithmetic on human-driven renewal at 47 days. Eight renewals a year, per certificate. Ten certificates — a modest estate once you count the API, the staging wildcard, the mail server, that marketing microsite — is 80+ renewal events a year, each one a chance for a missed email, a person on holiday, a CA portal password nobody remembers. At 398 days, manual renewal was a bad-but-survivable habit. At 47, it's structurally impossible.

The destination is automation — almost certainly ACME, the protocol behind Let's Encrypt and now supported by a growing list of commercial CAs:

# certbot: issue and install, then renewals happen automatically
certbot --nginx -d example.com -d www.example.com

# the renewal timer does the rest — verify it's active:
systemctl list-timers | grep certbot

If some of your certificates come from a commercial CA that doesn't yet offer ACME or an equivalent API, that's now a real procurement question — over the next couple of years, "can we automate issuance?" stops being nice-to-have and becomes a hard requirement.

Automation fails silently — which is why monitoring matters more, not less

Here's the counterintuitive part. Teams hear "automate renewals" and conclude expiry monitoring becomes obsolete. The opposite is true: every renewal is a chance for silent failure, and you're about to have eight times as many renewals. The ways automated renewal quietly breaks are well-worn:

• The DNS or HTTP challenge stops working. A firewall change blocks /.well-known/acme-challenge/, a CDN starts intercepting the path, a DNS API token expires.
• The renewal runs but deployment doesn't. The new certificate lands on disk, but the reload hook fails — nginx keeps serving the old certificate until it expires in production.
• The timer itself dies. The cron entry was lost in a server migration; the systemd timer was disabled during debugging and never re-enabled.
• Rate limits and CA outages hit at exactly the wrong moment, and your retry logic turns out to be theoretical.

At 398 days, a broken renewal pipeline gives you months of margin. At 47 days, the gap between "renewal silently broke" and "customers see browser warnings" can be a couple of weeks. The safety net is independent expiry monitoring — a check outside your renewal pipeline that connects to the live endpoint, reads the certificate actually being served, and alerts on a schedule that gives you time to act. At 47-day lifetimes, sensible thresholds tighten too: alerts at 14, 7 and 3 days out rather than the leisurely 30 that made sense in the annual era.

Your prep roadmap

None of the deadlines bite until March 2026, which makes right now the cheap time to prepare:

• Inventory every certificate. Every domain, subdomain, load balancer, mail server, internal tool with a public cert. You can't automate what you don't know exists — and by some estimates most organizations discover certificates during this exercise that nobody owned.
• Automate the easy 80% now. Anything on a standard web server can move to ACME this quarter. Don't wait for the deadline to force it.
• Flag the hard cases early. Certificates pinned in mobile apps, appliances with manual upload flows, that legacy device requiring a cert installed by hand — these need engineering time or replacement, and 2029 arrives faster than procurement cycles move.
• Add independent expiry monitoring on every endpoint, with thresholds sized for short lifetimes — so when (not if) a renewal silently fails, you hear about it with days in hand rather than from a customer screenshot.
• Rehearse a renewal failure. Break it on purpose in staging: block the challenge path, watch what alerts. If the answer is "nothing," fix that before the stakes rise.

Where CompleteStatus fits

CompleteStatus checks the certificate your servers are actually serving — expiry date, chain validity, the works — independently of whatever renews it, and alerts you by email, Slack, Discord, Telegram or webhook at thresholds you choose. It's the safety net under your automation: certbot does the renewing, and an outside observer confirms it worked, every day, on every endpoint you monitor.

The 47-day era rewards teams that automated early and verified independently. Create a free account, add SSL monitoring to your domains this week, and be one of them — years before the deadline makes it mandatory.