On April 11, 2025 the CA/Browser Forum passed ballot SC-081v3 with unanimous support from every browser vendor and every voting Certificate Authority. The ballot compresses the maximum validity of publicly-trusted TLS certificates from today's 398 days to 47 days in four phases, ending March 15, 2029. This page is the live countdown — and the operational read on what actually changes between now and then.
The timer above ticks toward Phase 4 — the day publicly-trusted TLS certs cap at 47 days and Domain Control Validation (DCV) reuse drops to 10 days. Phase 1 is already in effect. Phase 2 and Phase 3 land in the middle of most enterprises' PKI roadmap horizons. If your renewal is still ticket-driven, this is the deadline you plan against.
What SC-081v3 actually voted
SC-081v3 amends the CA/Browser Forum Baseline Requirements — the document every publicly-trusted CA is contractually bound to follow. Two knobs move in lockstep:
- Maximum certificate validity. The upper bound on how long a newly-issued publicly-trusted TLS cert can be valid.
- DCV data reuse period. How long a CA is allowed to trust a prior successful domain control validation before it must be redone. Historically 398 days. Dropping to 10 days by Phase 4.
Both numbers step down on the same dates. The DCV change is the one most teams miss, and it is the change that forces automation regardless of whether you renew every 47 days or every 10. Manual DCV every 10 days is not a workflow — it is a full-time job.
The four phase dates
The exact ballot text splits the transition into four stages. Numbers below are the ceilings — CAs are free to issue shorter certs at any point:
- March 15, 2026 — Phase 1. Max validity 200 days. DCV reuse 200 days.
- March 15, 2027 — Phase 2. Max validity 100 days. DCV reuse 100 days.
- March 15, 2028 — Phase 3. Interim step aligning DCV reuse ahead of the final lifetime cut.
- March 15, 2029 — Phase 4. Max validity 47 days. DCV reuse 10 days.
Each phase applies to newly-issued certificates on or after that date. Certs issued the day before a phase transition keep their original validity. There is no forced early rotation — but there is no way to buy a longer cert once the ceiling drops. Any team assuming a 398-day renewal cycle after March 2026 will discover on their next issuance that the CA now stamps out 200-day certs regardless of what the CSR asked for.
Why 47 days specifically
47 days is 45 days plus a 2-day operational grace window. 45 days is the shortest lifetime that still allows a monthly renewal cadence with an on-call rotation and a weekend buffer. Any shorter and the renewal window bumps into standard change-freeze calendars. Any longer and the browser distrust window — the time between a private-key compromise and every relying party rotating — stays uncomfortably wide.
The 47-day number was not invented for the ballot. Let's Encrypt has issued 90-day certs since 2015 and roughly 62% of the public web now runs on those certs (retrieved 2026-09-21). Automating a 47-day cert is the same problem as automating a 90-day cert with a slightly tighter alarm. The problem the ballot forces onto every enterprise is not can this be automated — it is have you automated it yet.
The 8× renewal math
A 398-day cert renews roughly once a year. A 47-day cert renews 7.8× per year — call it eight. The numbers that come with that multiplier:
- Renewal events per cert: 1/year → 8/year.
- DCV events per cert: ~1/year at 398-day reuse → ~36/year at 10-day reuse. (Every renewal plus each intermediate DCV refresh.)
- Alert volume from a naïve monitor: 8× more expiry warnings, 8× more OCSP transients, 8× more renewal-not-yet-propagated windows to filter out.
Set that against Keyfactor's 2024 finding that 86% of enterprises had a certificate-related outage in the past 12 months and only 32% use a formal certificate lifecycle management (CLM) tool. Full breakdown in the 2024 PKI outage report analysis. The gap between those two numbers is the whole problem: 86% outage rate at today's once-a-year cadence, multiplied by eight.
What breaks first
The 47-day cadence exposes four failure modes that most teams currently mask with margin:
- Manual DCV. Any DCV step that requires an operator — file upload, TXT record published by ticket, email-based validation — dies at 10-day reuse. This must move to ACME or a CA-native DCV automation before Phase 4.
- Cert pinning. HPKP is deprecated but pins live on in mobile apps and legacy SDKs. Any pin tied to an end-entity cert breaks on every renewal — 8× per year is fatal. Move to intermediate or root pinning, or remove.
- Service-mesh reload. Envoy, NGINX, HAProxy, and every ingress controller has a reload path that sometimes drops connections or fails silently on config error. Un-noticed at once/year cadence; a weekly incident at once/47-days.
- Vendor-managed certs on customer domains. The CNAME-flattening trick most CDNs use to serve a customer domain's TLS via the CDN's own cert breaks the moment the CDN's DCV reuse expires and the customer's DNS was set up once, three years ago, by someone who left. Every vendor SaaS with a custom-domain feature has this problem.
Phase-by-phase playbook
The lazy, minimum path that keeps you ahead of each phase:
- Before March 2026 (Phase 1 — already live). Inventory every publicly-trusted certificate you have. Not the ones you know about — the ones you have. Include vendor subdomains, CDN-fronted apex records, marketing microsites, and every customer-facing subdomain your CMS ever spun up. If you cannot list them all in one CSV, you are already behind.
- Before March 2027 (Phase 2 — 100-day validity). Every cert on that inventory is on ACME or an equivalent auto-renew path. Pick one non-critical property this quarter and run 90-day auto-renewals on it now. Every failure you learn about is a Phase 4 failure you skip.
- Before March 2028 (Phase 3 — DCV alignment). DCV method is DNS-01 or HTTP-01 automation — no email, no manual file upload. Delegated DNS (
_acme-challengeCNAME to a managed DNS zone) if the primary zone is controlled by a team that cannot grant API access. - Before March 2029 (Phase 4 — 47-day validity, 10-day DCV). A monitor watches every cert on every public host — apex, www, every subdomain, every vendor-mapped custom domain. Renewal failures page someone within one renewal cycle, not one calendar cycle.
- After Phase 4. The 47-day cadence becomes background noise. The next ballot is already being drafted. Assume the endpoint keeps moving.
What to monitor now
Two things every organisation should have visibility on today, independent of when they plan to automate:
- A live inventory. Every hostname that terminates TLS, the cert chain served, the issuer, the expiry date, and the last time it was renewed. Not a spreadsheet. Not a quarterly export. A pull that runs today.
- An automation-gap flag. For each cert: is renewal automated (ACME, CLM, vendor-managed) or manual? The manual bucket is the Phase 4 risk register.
FAQ
When exactly does the 47-day rule take effect?
March 15, 2029 (UTC). That is Phase 4 of ballot SC-081v3. The interim phases are March 15, 2026 (200 days), March 15, 2027 (100 days), and March 15, 2028 (DCV alignment). Each phase applies to certificates issued on or after that date.
Does this affect internal PKI or private CAs?
No. SC-081v3 binds the CA/Browser Forum members — the CAs whose roots ship in Apple, Google, Microsoft, and Mozilla root stores. Private / internal roots you run yourself for service-mesh mTLS, internal APIs, or device identity are unaffected. That said, most modern internal-CA guidance already recommends short lifetimes for the same operational reasons.
Can we opt out or buy a longer cert?
No. Publicly-trusted CAs are contractually bound to the Baseline Requirements. Issuing a cert longer than the ceiling is grounds for browser distrust of the CA's entire root. No CA will accept that risk for a single customer.
Is 47 days final, or will it move again?
Final within SC-081v3. But the direction of travel is one-way. Google's stated position is 90-day certs at most; Apple has floated 45. The ballot passed unanimously, which means the next ballot faces no political opposition. Plan the automation once, then run it.
What is DCV reuse and why does the 10-day number matter?
DCV is the check the CA runs to prove you control the domain — a DNS TXT record, a well-known HTTP path, or an email challenge. "Reuse" means: how long can the CA trust a previous successful check before it must be redone? At 398-day reuse a manual DCV once a year is fine. At 10-day reuse it is impossible without automation.
What is the fastest way to check whether we are on ACME?
Look at your certs' issuer and validity length. Let's Encrypt, ZeroSSL, Google Trust Services, and Amazon Certificate Manager (public) all issue via automation by default. DigiCert, Sectigo, and GlobalSign issue via automation only if you have opted in. Run the DomainScan SSL check against your apex and inspect the issuer field.
Sources
- CA/Browser Forum. Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods. Passed April 11, 2025 (retrieved 2026-09-21).
- DigiCert. TLS Certificate Lifetimes Will Officially Reduce to 47 Days. digicert.com/blog (retrieved 2026-09-21).
- Sectigo. The 47-Day TLS Certificate Countdown Begins. sectigo.com (retrieved 2026-09-21).
- Keyfactor. 2024 PKI & Digital Trust Report. keyfactor.com (retrieved 2026-09-21).
- IETF. RFC 8555: Automatic Certificate Management Environment (ACME). datatracker.ietf.org (retrieved 2026-09-21).
- Related DomainScan analysis: 86% of enterprises hit a certificate outage in 2024 · Ericsson-O2 SSL outage — one expired cert, 32M users, £100M in damages.