SC-081v3 and the End of the One-Year Certificate: A Field Guide to the 2026-2029 Lifetime Reductions

SC-081v3 is the CA/Browser Forum ballot that staged a phased reduction of public TLS certificate lifetimes from 398 days down to 47 days between March 2026 and March 2029. Apple proposed it. The CAs voted against it. It passed anyway, and it's already changing how every team running more than a handful of certs thinks about renewal automation.

If you've only seen the headlines, you've seen the 47-day number. That's the wrong thing to fixate on. SC-081v3 also collapses the Domain Control Validation reuse period from 398 days to 10 days on the same schedule, and the DCV change is what breaks automation that worked fine for years. When the cache window shrinks, every renewal becomes a fresh challenge. Teams rate-limited at their DNS providers or throttled at their CA will feel the DCV cliff before the validity cliff hits.

What SC-081v3 actually says (and why Apple wrote it)

SC-081v3 is a CA/Browser Forum Baseline Requirements ballot that mandates staged reductions of public TLS certificate validity and DCV reuse over three years. It starts March 15, 2026 and finishes March 15, 2029. Apple proposed it. Google, Mozilla, and Microsoft backed it. The bulk of CAs opposed it and lost the vote.

The ballot text sets four hard dates. The validity reductions get the press, but the DCV reuse collapse is the harder operational change for anyone running automation today.

Effective date	Max validity (days)	DCV reuse (days)
Before March 15, 2026	398	398
March 15, 2026	200	200
March 15, 2027	100	100
March 15, 2029	47	10

Apple's stated rationale: revocation has never worked at internet scale. CRLs are too large to ship to clients reliably. OCSP soft-fails by default in every major browser, which means a revoked cert keeps working when the OCSP responder is unreachable. Shorter validity is the only revocation mechanism that doesn't depend on something else working. If a key compromises in 2030, the worst-case exposure window is 47 days, not 13 months.

Read the ballot. The full text is on the CA/Browser Forum public archive. Don't trust the secondhand summaries; the DCV math is in the appendix and most blog posts skip it.

The real timeline: four cliffs, not one

SC-081v3 isn't a single 2029 deadline. It's four separate operational events spread across three years, and the first one is less than a year out. Treating it as one big migration in 2029 means missing three forcing functions, each of which kills a different class of workflow. The first cliff is March 15, 2026.

There's also a soft deadline most teams forget. A 398-day cert issued on March 14, 2026 is still valid until April 2027, well past the 200-day cliff. So in mid-2026 you'll have a mixed fleet: some certs issued under the old rules with long validity, some new certs capped at 200 days. This isn't a clean cutover. It's a gradient that runs through your inventory for years.

If you're tracking what already exists today, see the 47-day certificate timeline for a cleaner per-quarter view. The short version: every cert you issue after March 2026 has a shorter expiry than the one before it, and your renewal cadence steps up at each cliff.

A useful framing: count the renewals per cert per year at each stage.

Stage	Validity	Renewals per cert per year
Today	398 days	~1
March 2026	200 days	~1.8
March 2027	100 days	~3.7
March 2029	47 days	~7.8

Multiply by your fleet size. A 1,500-cert fleet goes from ~1,500 renewal events per year to ~11,700 by 2029. If a single cert in that fleet still touches a human, the math doesn't close.

What actually breaks at each stage

Each cliff kills a specific class of automation. The 200-day stage kills calendar-based renewal. The 100-day stage kills any workflow that requires a human in the loop. The 47/10-day stage breaks DNS-01 setups that aren't tuned for fast propagation. None of these failures are theoretical; teams will find them in production the week after each cliff.

At 200 days, a renewal you do "every six months" stops working because your six-month reminder lands after expiry. Calendar reminders, ticket-based workflows, and quarterly ops reviews all become liabilities. A 30-day buffer for human action shrinks to a 14-day buffer at best, and that's before holidays and PTO eat into it.

At 100 days, EV and OV certs with manual extended validation become operationally untenable. Industry data indicates EV validation paperwork takes 2-3 weeks for a new org and 3-5 days for a re-issue. Doing that quarterly is a half-time job. Most teams will move EV-protected hostnames to DV ACME and accept the loss of the green-bar legacy that nobody sees anyway.

At 47 days with 10-day DCV reuse, the failure modes get specific. DNS-01 propagation that took 60 seconds in 2024 now happens 8 times a year per cert. If your DNS provider has a 5-minute TTL and you're using a dumb polling client, you lose minutes per renewal. Multiply by fleet size and you've got a real concurrency problem. Production ACME setups need DNS providers with API-based instant propagation (Route 53, Cloudflare, NS1) and clients that cache nothing.

The honest survival list:

• survives all three cliffs: cert-manager + DNS-01 with a fast DNS provider, well-staggered
• dies at 200 days: any workflow with a human approval step
• dies at 100 days: manual EV renewals, hardware appliance certs touched by a network team
• dies at 47/10 days: ACME setups with slow DNS, no jitter, single CA, no retry logic

The long tail: devices that can't do ACME

Most coverage assumes your fleet is Kubernetes ingresses with cert-manager. The real long tail looks nothing like that. It includes F5 LTMs from 2018, Cisco ASAs your security team won't let you touch, IoT gateways with web-form PEM upload, vendor SaaS where the only renewal interface is emailing support a new cert, and AD CS-issued internal certs that someone published externally because it was faster than filing a ticket. A 47-day cycle on any of these is operationally hostile.

In my experience watching teams plan for this, four patterns show up for the long tail. None are perfect; pick based on how much political capital you have.

• vendor pressure: file feature requests, escalate, threaten to migrate. Works for vendors who know the writing's on the wall. Doesn't work for the F5 your team renewed in 2019 and hasn't touched since.
• sidecar proxy: terminate TLS on something you control (HAProxy, NGINX, Envoy) and pass cleartext or a long-lived internal cert to the appliance. Adds a hop. Adds a thing to monitor. Survives the cliffs.
• private CA with longer internal validity: SC-081v3 only applies to publicly trusted certs. An internal PKI can issue 10-year certs to your AD CS-trusting clients with no ballot drama. The catch: every external client needs your root, which is fine for internal apps and useless for anything customer-facing.
• accept manual renewal until the device dies: a 47-day cycle on three appliances is 24 renewals a year. Painful but finite. Pair with renewal monitoring so you catch the silent failures.

The trap most teams fall into is assuming the legacy fleet will be retired before 2029. It won't. Plan for it.

Rate limits and CA capacity: the math nobody's doing

According to Let's Encrypt's published rate limits, accounts are capped at 300 new orders per 3 hours and 50 certificates per registered domain per week. Most teams don't hit either today. At 47-day validity with naive batch renewal, mid-size fleets absolutely will. The math depends on staggering, multi-CA distribution, and how many distinct registered domains you actually have.

After working through this for a 1,500-cert fleet across roughly 40 registered domains, here's what falls out. Cycling every 47 days with a 2/3 renewal trigger gives 11,700 renewals per year, or 32 per day average. Spread across 40 domains, that's well under the 50-per-domain-per-week ceiling. But those 1,500 certs aren't evenly distributed. One domain has 600 certs on it (subdomains for tenants), and that domain alone hits 132 renewals per week. That's a hard fail at the Let's Encrypt limit.

The fix is a mix:

• jitter renewals: don't renew at "30 days remaining"; randomize between 25 and 35 days, so you don't batch-deploy after an outage
• multi-CA: split issuance between Let's Encrypt, ZeroSSL, and Google Trust Services. Each has its own quota. Cert-manager supports multiple ClusterIssuers cleanly.
• account-per-environment: prod, staging, and dev on separate ACME accounts means a runaway test loop in dev doesn't burn the prod 3-hour quota
• subdomain awareness: if one registered domain hosts most of your certs, that's where the per-domain limit bites. Consider splitting into multiple registered domains, or wildcarding where it makes sense (with the wildcard tradeoffs in mind)

ZeroSSL and Google Trust Services have similar but not identical limits. Treating them as identical to Let's Encrypt will burn you. Read each CA's published limits before you split traffic.

Why this is actually good (and why CAs hate it)

Shorter certificate lifetimes are net good for the web. The CAs opposing SC-081v3 did so because their margins depend on selling humans expensive certs they touch twice. Revocation has been broken for fifteen years; 47 days is the new revocation. Forced automation eliminates the largest single class of TLS outages, which is humans forgetting to renew.

The OCSP and CRL story has been ugly for a long time. OCSP stapling silently fails on huge swaths of production infra and most operators don't notice. With 47-day max validity, the worst-case exposure from a key compromise drops from over a year to under two months without any client-side mechanism working at all.

The CA business model loss is real but not sympathetic. EV certificate sales ran ~$200/year per cert for a UI affordance most browsers stopped showing in 2019. OV certs have similar economics. ACME-issued DV certs are commoditized at zero. SC-081v3 doesn't change DV economics; it forces the high-margin manual-validation business to either automate or die. Those CAs had a decade to build automation and chose not to.

Apple was right. The web is better off. Engineers are better off because the human-error class of cert outages goes away.

What to do between now and March 2026

You have less than a year before the first cliff. Inventory every public cert with validity over 200 days that won't naturally renew before March 15, 2026. Audit every renewal path for human steps and remove them. Identify legacy devices and start the vendor conversation now, not in February. Test ACME setups against staging environments, not just production.

A literal punch list with timing:

• this month: complete cert inventory, flag any cert that will still be valid past March 15, 2026 with original validity > 200 days. The inheritance problem post has a tested approach if you're starting from a spreadsheet.
• within 60 days: identify every renewal path that touches a human; either automate it or document it for retirement
• within 90 days: stand up Let's Encrypt staging in your renewal automation, run a forced renewal of every cert against staging
• by January 2026: audit per-domain and per-account rate limit headroom against your projected 2027 renewal volume
• by February 2026: file vendor tickets for any non-ACME appliance still in production, document the response, escalate
• March 2026: monitor renewal failures, not just expiry. The cliff doesn't break things on day one; it breaks them on day 178 of certs that no longer renew cleanly.

This is also the right window to evaluate whether your monitoring catches renewal-without-deploy failures, the silent class where the cert renews but never lands on the load balancer. CertPulse exists because that gap kept paging me at 2am.

FAQ

When does SC-081v3 first take effect? March 15, 2026. After that date, no publicly trusted CA can issue a TLS cert with validity over 200 days, and DCV reuse is capped at 200 days. The 47-day final cliff arrives March 15, 2029, but the operational change starts in 10 months.

Does SC-081v3 affect internal/private CAs? No. The ballot only binds publicly trusted CAs in the CA/Browser Forum Baseline Requirements. Internal PKI (AD CS, HashiCorp Vault, smallstep, private intermediates) can still issue certs with whatever validity you want. This is part of why private CAs are getting more attention for internal mTLS workloads.

What changes for me if I'm already on cert-manager with Let's Encrypt? Probably very little for the first two cliffs, assuming your renewals are running cleanly. The 2029 cliff with 10-day DCV reuse will stress fast DNS providers and rate limits. Audit your renewal staggering and verify you're not concentrating issuance windows.

Is there any way to keep getting longer-validity certs? For publicly trusted certs, no. For internal-only use cases, run a private CA. For specific edge cases where automation is genuinely impossible (some hardware appliances, regulated environments), the answer is "renew more often" or "put a sidecar in front of it." There is no legal path back to 398-day public certs after March 2026.

Why did most CAs oppose SC-081v3? Margins. The high-margin EV and OV certificate business depends on humans paying annually for manual validation. Shorter lifetimes either force CAs to automate at scale (commoditizing their product) or shrink the addressable market for manual validation. The ballot still passed because browsers, not CAs, control the trust stores.