SC-081: Why TLS Certificates Will Last Only 47 Days by 2029

In April 2025, the CA/Browser Forum passed ballot SC-081v3 by a unanimous 25-0 vote among Certificate Issuers — a proposal originally introduced by Apple. It rewrites the TLS Baseline Requirements to phase down the maximum lifetime of publicly trusted TLS certificates from 398 days to just 47 days by March 2029.

This is not a cosmetic adjustment. It is a structural change in how any team running TLS infrastructure — sysadmins, DevOps, SRE, security — needs to think about certificate lifecycle management.

The full timeline

SC-081v3 reduces two numbers in parallel: maximum certificate validity, and the window during which domain control validation (DCV) evidence can be reused across issuances.

The final number — 47 days — wasn't arbitrary. It maps to a 30-day renewal cycle plus a 17-day buffer to absorb failures before actual expiry.

For most operations, the DCV reuse cut is the more disruptive detail. Today it's common to validate a domain once and reissue certificates for up to 398 days without repeating validation. In Phase 3, every renewal will require fresh domain validation — which is only operationally viable with end-to-end automation, typically via ACME.

Why the CA/Browser Forum did this

Three concrete motivations underpin SC-081:

• A smaller exposure window when keys are compromised. A leaked private key paired with a 398-day certificate stays useful to an attacker for up to 398 days, even after revocation — because CRL/OCSP revocation is notoriously unreliable in practice (clients soft-fail, caches go stale). A 47-day certificate caps that damage by design, whether or not revocation works.
• Reduced dependence on revocation. If certificates expire quickly by default, the ecosystem leans less on real-time revocation checking — historically one of the weakest links in the TLS trust model.
• A precedent already proven at scale. Let's Encrypt demonstrated, with 90-day certificates issued via ACME, that full automation works in production across millions of domains. SC-081 extends that logic to the entire public ecosystem.

Scope: what's excluded

The TLS Baseline Requirements — and therefore SC-081 — govern only certificates used to authenticate servers reachable on the public internet. Private PKI (certificates issued by an internal CA for use strictly inside the corporate network) falls outside the formal scope.

That doesn't mean internal teams should ignore the trend. The same automation discipline SC-081 forces on public certificates is increasingly treated as best practice for internal PKI as well.

The operational impact is arithmetic

Compare renewal events per certificate, per year, across phases:

• Today (398 days): ~1 renewal/year
• Phase 1 (200 days): ~2 renewals/year
• Phase 2 (100 days): ~3–4 renewals/year
• Phase 3 (47 days): ~8 renewals/year

Now multiply that by the real number of certificates in production — including the ones nobody remembers exist, issued by a team that has since rotated, pointing at a load balancer nobody documented. Manual certificate management, already fragile at one renewal event per year, becomes statistically unsustainable at eight.

How to prepare before Phase 1 (2026-03-15)

1. Discovery first. You cannot automate renewal for a certificate you don't know exists. Map certificates across your entire infrastructure — cloud, on-premise, Certificate Transparency logs — before designing any automation flow.
2. Standardize on ACME wherever possible. It's the protocol most public CAs already support for automated issuance and renewal, and it's the only realistic path to sustaining 10-day DCV cycles in Phase 3.
3. Treat expiry as an incident, not a calendar task. "Certificate expires in 30 days" alerts make little sense when the certificate only lives 47 days. Monitoring needs to be continuous and wired into the deployment pipeline, not into a manual reminder.
4. Automate deployment, not just issuance. Renewing a certificate that isn't automatically redistributed to every endpoint consuming it — load balancers, CDNs, containers — solves only half the problem.

SC-081 isn't a threat. It's confirmation that the old model of an annual certificate tracked in a spreadsheet no longer has a place. Organizations that automate discovery, issuance, renewal, and deployment before 2029 simply won't notice the transition. Those that don't will learn the difference between 1 and 8 risk windows per year, one missed renewal at a time.