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

The CA/Browser Forum, where certificate authorities and browser vendors set the rules for public TLS, has just passed ballot SC-081, 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, its days are numbered.

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 15, 2026: maximum drops to 200 days, so you renew at least twice a year.
• March 15, 2027: maximum drops to 100 days, roughly quarterly renewals.
• March 15, 2029: maximum drops to 47 days, a renewal every month and a half.

The ballot also shortens how long domain-control validation can be reused, stepping down over the same period until validation is only good for 10 days by 2029, so even the proof that you control the domain has to be re-established for almost every issuance. This isn't a proposal; the ballot has passed, and barring surprises these dates are now the rules.

Why the industry is doing this

Shorter lifetimes aren't bureaucracy for its own sake. They address real weaknesses:

• 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, and 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: multi-year certificates were capped at 39 months, then 825 days, then 398. 47 is the same trend, accelerated.

Manual renewal won't survive this

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 unworkable.

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 few years, "can we automate issuance?" becomes a hard requirement.

Automation fails silently, so monitoring matters more, not less

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. Automated renewal breaks quietly in familiar ways:

• 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 and 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 most organizations turn up a certificate or two 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 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 and see 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 and chain validity), independently of whatever renews it, and alerts you by email, Slack, Discord, Telegram or webhook at staged points before expiry. 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, and add SSL monitoring to your domains well before the first cut in March 2026.