SC-081v3 Explained: The 47-Day Certificate Timeline
The CA/Browser Forum ballot SC-081v3 cuts public TLS certificate validity from 398 days down to 47 days by 2029. Here's the phased timeline, why it's happening, and what DevOps teams need to do now.
In April 2025, the CA/Browser Forum passed ballot SC-081v3, a rule change that will fundamentally reshape how every engineering team manages public TLS certificates. If you’re still treating certificate renewal as an annual chore, 2026 is the year that stops working.
What SC-081v3 actually says
SC-081v3 is an amendment to the CA/Browser Forum Baseline Requirements — the rule set that every publicly trusted Certificate Authority must follow to have its root certificates shipped with Chrome, Firefox, Safari, and the other mainstream browsers. The ballot shortens the maximum allowable validity period for public TLS server certificates in four phases:
| Effective date | Max validity | Max DCV reuse |
|---|---|---|
| Current baseline | 398 days | 398 days |
| March 15, 2026 | 200 days | 200 days |
| March 15, 2027 | 100 days | 100 days |
| March 15, 2029 | 47 days | 10 days |
“DCV reuse” is Domain Control Validation reuse — how long a CA can rely on a prior domain ownership proof before re-verifying. This is the number that really bites: once DCV reuse hits 10 days, every certificate issuance effectively requires a fresh domain-validation handshake. Check the CA/Browser Forum ballot text for the exact current baseline in effect as of your reading.
Why the CA/Browser Forum is doing this
Three reasons, in order of how often they get cited:
- Shrink the window of a compromised certificate. A stolen key or mis-issued cert should stop being useful sooner. CRL and OCSP-based revocation has historically been unreliable — clients often soft-fail when revocation data is unavailable — so shortening lifetimes is the pragmatic backstop.
- Force automation. Manual certificate management doesn’t scale to a 47-day lifetime. Google, Apple, and Mozilla have been nudging the industry toward ACME-based automation for years, and this is the nudge becoming a shove.
- Retire legacy key material faster. If a cryptographic algorithm or key size becomes weak, shorter lifetimes mean the ecosystem reaches the post-quantum future more quickly without waiting years for long-lived certs to naturally expire.
What this looks like in practice
At today’s 398-day lifetime, a team with 50 certificates renews roughly once a week. At 47 days, the same team renews more than once per day, every day, forever. Even at the March 2026 milestone of 200 days, you’re looking at a renewal every ~4 days across 50 certs. Spreadsheets, calendar reminders, and “Alice handles certs” don’t survive this.
Here’s what actually breaks at 47 days:
- Hand-managed certs on appliances. That load balancer, firewall, or IoT device without ACME support becomes a weekly operational burden.
- Imported certs in AWS ACM. ACM auto-renews certs it issues, but imported certs from other CAs do not auto-renew. You own those renewals.
- Cloudflare for non-proxied domains. Cloudflare only manages edge certs for traffic it proxies. Direct-to-origin certs are yours to rotate.
- Internal services using public trust. Staging environments, admin portals, and backoffice tools often use public certs for convenience. Every one of them now needs automation.
- Certificate pinning. If your mobile app or IoT device pins a specific cert, a 47-day rotation means pins are useless. Switch to SPKI pinning or remove pinning entirely.
What to do now
Inventory first. You cannot automate what you don’t know about. Discover every certificate your organization depends on — across cloud providers, on-prem infrastructure, third-party SaaS, and forgotten subdomains. Certificate Transparency logs are the source of truth here: every publicly trusted cert is logged, whether you know about it or not.
Prioritize by blast radius. Which certs, if they expire without warning, cause the worst outage? Customer-facing front doors, APIs, single-sign-on endpoints, payment flows. Start automation there.
Pick an ACME client you trust. certbot, acme.sh, lego, Caddy’s built-in TLS — all solid choices for standard deployments. For anything non-trivial (multi-region, wildcard via DNS-01, custom hooks), budget real engineering time to test the renewal path under failure conditions.
Monitor the outcome. Automation fails silently. A cron job that “ran successfully” but produced a broken cert chain is worse than a failed cron job. You need observability over the live certificate chain on every endpoint, not just the file on disk.
Establish a renewal runway. Always renew well before expiration. At 47-day validity, a 7-day renewal buffer is aggressive; a 14-day buffer is safer. Anything less and a single outage during renewal window causes a user-visible incident.
How CertShield helps
CertShield is purpose-built for the SC-081v3 world. We discover every certificate across your infrastructure — via TLS handshake inspection and Certificate Transparency log monitoring — and alert you before expiry, before chain changes break clients, and before an automation failure becomes an outage.
We don’t replace your ACME client. We give you the visibility layer on top of it, so when certbot silently fails at 3 AM, you know before your customers do.
Start monitoring your certificates →
Further reading: the CA/Browser Forum ballot text is the canonical source. Apple and Google have both published supporting statements in their respective root store policies.