ComplianceTimelineNEW

The 47-Day Certificate Timeline

By 2029, every publicly-trusted TLS certificate your organization uses will be on a ~monthly renewal cycle, with domain validation happening roughly 35 times per year per cert. If you own PKI, certificates, or TLS standards internally, this ballot is now on your roadmap whether you like it or not.

15 min readJanuary 2026PASSED

ShareLinkedIn X

The 47-Day Certificate Timeline - SC-081v3 phased reduction from 398 to 47 days by 2029

Watch the Video

A visual walkthrough of the SC-081v3 timeline and what it means for your certificate management strategy.

SC-081v3 at a Glance

398

Current max (days)

2029 max (days)

29-0

Vote (5 abstain)

May 21

2025 effective

Private PKI is NOT affected. This only applies to publicly-trusted TLS certificates from CAs in browser root programs.

Phase 1 (200 days / 199 effective)

March 15, 2026

NOW IN EFFECT

Phase 2 (100 days / 99 effective)

March 15, 2027

150

days

hrs

min

Phase 3 (47 days / 46 effective)

March 15, 2029

881

days

hrs

min

What Actually Passed

Ballot Details

Ballot:SC-081v3
Author:Clint Wilson (Apple)
Sponsor:Sectigo
Vote Period:April 4-11, 2025
Effective:May 21, 2025 (after IPR review)

Voting Results

Certificate Issuers

25 YES, 0 NO, 5 ABSTAIN

Browser Vendors

4 YES (Apple, Google, Microsoft, Mozilla)

Key Point

This passed with zero opposition. The browsers are aligned. All major browser vendors (Apple, Google, Microsoft, Mozilla) voted YES. This is happening.

The Full Timeline

Phase	Effective Date	Max Validity	DCV Reuse	SII Reuse
Current	Now	398 days	398 days	825 days
Phase 1active now	March 15, 2026	200 days(199 effective)	200 days(198 effective)	398 days
Phase 2	March 15, 2027	100 days(99 effective)	100 days(98 effective)	398 days
Phase 3	March 15, 2029	47 days(46 effective)	10 days(8 effective)	398 days

SII = Subject Identity Information (organizational data for OV/EV certificates)

What This Means for PKI Engineering

SC-081v3 fundamentally changes how you architect public TLS certificate management. Here's what changes in your stack:

Treat public TLS issuance as a high-throughput service — requests, queues, retries, rate limits — not a ticket workflow.
Standardize on ACME (or your CLM's equivalent) as the default issuance API for all public endpoints.
Design DNS-01 automation: delegated zones, API-driven record management, and non-interactive validation flows.
Eliminate manual DCV (email, one-off HTTP file placement) from any production path by Phase 2.

Bottom line: If your renewal process involves a human clicking "renew" or placing a file via FTP, that process will break at scale by 2027.

The Real-World Numbers: Why 200 Doesn't Mean 200

The ballot says 200 days. CAs are issuing 199. DCV reuse drops to 198. Here's why — and why it matters.

Heads Up: The Numbers Everyone Quotes Are Wrong

Every blog post, vendor page, and LinkedIn hot take says "200 days, 100 days, 47 days." Those are the ballot numbers. They're not what CAs will actually issue. Here's what the real numbers are and why.

Source: Tim Callan & Jason Soroko, Root Causes Episode 575 (YouTube) — Sectigo | Watch: 200-Day Certs Are Actually 199 Days (Here's Why)

Midnight Plus One Second Is a Violation

CA/Browser Forum validity limits are precise down to the second. Exceeding the limit by even 1 second constitutes misissuance and triggers mandatory revocation. This is not theoretical — it has caused large revocation events in recent years.

Most CA software measures certificate terms midnight to midnight. But midnight to midnight = 24 hours + 1 second = over the limit. Therefore, CAs that know what they're doing will round down by at least 1 day.

Phase	Ballot Says	CAs Will Issue	Why
Phase 1 (Mar 15, 2026)active	200 days	199 days	Midnight-to-midnight off-by-one
Phase 2 (Mar 15, 2027)	100 days	99 days	Same reason
Phase 3 (Mar 15, 2029)	47 days	46 days	Same reason

Sectigo confirmation: Sectigo explicitly states "199 days" maximum and enforcement starts March 12, 2026 — 3 days before the CA/B Forum deadline, for safety margin. Their knowledge base confirms: "All (re-)issued TLS certificates will be valid for no longer than 199 days."

Why DCV Reuse Drops by TWO Days, Not One

Before issuing a public TLS certificate, CAs must first create a pre-certificate and log it with a Certificate Transparency (CT) log. The pre-certificate announces the CA's intent to issue.

The actual certificate can follow the pre-certificate anywhere from 1 second to 24 hours later. The actual certificate must be issued within the DCV reuse window — but the pre-certificate could lead it by up to 24 hours. Therefore, DCV reuse must account for both the off-by-one AND the pre-certificate gap.

This costs DCV reuse two days, not one.

Phase	Ballot Says	Actual DCV Reuse	Why
Phase 1 (Mar 15, 2026)active	200 days	198 days	Off-by-one + pre-cert window
Phase 2 (Mar 15, 2027)	100 days	98 days	Same reason
Phase 3 (Mar 15, 2029)	10 days	8 days	Same reason

Sectigo confirmation: Sectigo Compliance Hub explicitly states "DCV reuse will be limited to approximately 6 months (198 days)" and their KB article confirms: "No new certificate may be issued after March 12th relying on the DCV that was completed more than 198 days ago."

Even the Experts Get This Wrong

Tim Callan — Sectigo's Chief Compliance Officer and a founding member of the CA/Browser Forum — corrected a previous episode's numbers live on air during Root Causes 575. Jason Soroko initially said 9 days for Phase 3 DCV reuse and corrected himself to 8 days during the episode.

If the people who wrote the ballot can get tripped up by these edge cases, so can you. This is why precision matters in PKI — time is a security primitive.

Follow the Cadences and Forget the Edge Cases

This is the most important takeaway. The numbers were designed to align with standard operational cycles:

199-day cert

Renew on a 6-month cadence → well within limits

99-day cert

Renew on a 3-month cadence → well within limits

46-day cert

Renew on a monthly cadence → well within limits

8-day DCV reuse

Revalidate on a weekly cadence → well within limits

Bottom Line

If you're trying to milk every last day out of a certificate, you're doing it wrong. Renew 1-2 weeks early, and these pedantic edge cases become completely irrelevant. The only people who need to worry about 199 vs 200 are CAs and CLM vendors — and they already know.

What About Subscription Pricing?

Renewing early does NOT cost you extra. Most CAs now offer subscription-based pricing (annual or multi-year). You get certificates as needed within your subscription window.

Renewing a cert 2 weeks early doesn't "waste" 2 weeks of value
The old "squeeze every day out of your cert" mentality is legacy thinking from 20+ years ago
By the time we hit monthly renewals, everything will be time-based, not per-certificate

Source: Root Causes Podcast Episode 575 — Tim Callan (Sectigo CCO) & Jason Soroko; Sectigo Compliance Update Hub; Sectigo FAQ

Phase-by-Phase Breakdown

Phase 1: 200 Days (199 Effective)NOW IN EFFECT

March 14, 2026 (passed)

First reduction in 5 years (since 398-day limit in 2020)
~2 renewals per year instead of 1
DCV reuse drops from 398 to 200 days (198 effective)
SII reuse drops from 825 to 398 days

Impact: Moderate — most organizations can handle with existing processes

Phase 2: 100 Days (99 Effective)

March 14, 2027 (150d)

~4 renewals per year (quarterly cadence)
Manual processes become unsustainable
This is where most organizations will need automation

Impact: Significant — automation becomes essential, not optional

Phase 3: 47 Days (46 Effective) + 10-Day DCV (8 Effective)

March 14, 2029 (881d)

~8 renewals per year per certificate (monthly cadence)
Critical: DCV reuse drops to just 10 days (8 effective)
This means ~35 domain validations per cert per year

Impact: Transformational — automation is mandatory, not optional

Why 47 Days Specifically?

The number isn't arbitrary. From the CA/Browser Forum discussions:

47 days = 1 maximal month (31 days) + ½ 30-day month (15 days) + 1 day wiggle room

A common practice is renewing certificates at two-thirds of their remaining lifetime. For a 47-day certificate, renewal occurs around day 30 — creating a clean monthly renewal cycle aligned with existing automation patterns. Clint Wilson (Apple) initially proposed 45 days; 47 provides a buffer for CAs issuing exactly 45-day certificates.

The DCV Reuse Problem Nobody's Talking About

Everyone's focused on the 47-day certificate headline. But the 10-day DCV reuse limit is potentially more disruptive.

Current State

Validate domain once, reuse for 398 days

Phase 3 State

Validate domain every 10 days for new issuances

What This Means in Practice

If you're renewing a cert, you must re-validate domain ownership
With 47-day certs renewed at 2/3 lifetime (day 30), you'll validate approximately every month
The 10-day reuse means you CAN'T batch validations far in advance
Organizations managing multiple domains face continuous validation cycles

Why This Matters More Than the 47-Day Headline

8x more certificate renewals is manageable with automation

35x more DCV validations requires infrastructure redesign

DNS-based validation (DNS-01) becomes essential for scale

Email-based validation methods are being sunset anyway (SC-090)

Who's Affected (and Who Isn't)

Affected

Public websites using certificates from trusted CAs
APIs and services using publicly-trusted TLS
Load balancers, CDNs, reverse proxies with public endpoints
Any system presenting certificates to browsers

NOT Affected

Private/Internal PKI (enterprise CAs)
Self-signed certificates
S/MIME, code signing, document signing (different BRs)
IoT device certificates (not in TLS BR scope)

Important clarification: The TLS Baseline Requirements only govern certificates "intended to be used for authenticating servers accessible through the Internet." Internal systems using enterprise PKI are exempt.

The Security Rationale

From Apple's ballot preamble and CA/Browser Forum discussions, here's why browsers pushed for this:

Revocation is Broken

CRLs are too big, OCSP has privacy issues, browsers often soft-fail. Shorter validity is the only reliable "revocation."

Domain Ownership Changes

When domains are sold/transferred, old certificates stay valid. Currently up to 13 months of risk. At 47 days, max exposure is 6 weeks.

Compromised Keys

If a private key leaks, damage window shrinks from 13 months to 47 days.

Crypto Agility

When SHA-1 was deprecated, long-lived certs slowed migration. Shorter validity enables faster algorithm transitions (relevant for post-quantum).

Automation Normalizes Security

Manual processes introduce human error. Forcing automation actually improves security posture.

"A reduction to both certificate lifetimes and data reuse periods decreases the likelihood of a certificate remaining valid after the information contained therein is no longer accurate."
— SC-081v3 Ballot Text

Before/After Comparison

Metric	Today (398 days)	2029 (47 days)	Change
Renewals/cert/year	~1	~8	8x increase
DCV validations/cert/year	~1	~35	35x increase
Max exposure (key compromise)	398 days	47 days	88% reduction
Manual management	Painful	Impossible	—
Automation requirement	Recommended	Mandatory	—

What You Need to Do

Now (Phase 1 Active — Before Phase 2)

Inventory all publicly-trusted certificates
Identify certificates currently managed manually
Evaluate CLM/automation solutions
Test ACME implementation in staging

Phase 1 Ready (200 days)

Automate renewal for all public certificates
Implement monitoring and alerting
Document renewal processes
Train team on new procedures

Phase 2 Ready (100 days)

Verify automation handles quarterly renewals
Stress test with increased renewal volume
Review DCV methods (prepare for DNS-01)

Phase 3 Ready (47 days + 10-day DCV)

Full automation with no manual intervention
DNS-based validation infrastructure
Continuous compliance monitoring

For PKI / Security Managers

Translating SC-081v3 into projects, owners, and timelines for your organization:

Assign clear ownership: who owns public TLS issuance, DNS automation, and exception handling?
Align certificate inventory with CMDB/asset inventory so you can prove coverage to auditors and leadership.
Set a policy deadline (e.g., "no manual renewals after March 2027") and track it like any other risk reduction goal.
Budget now for CLM, ACME, and DNS automation work — this is not just "PKI toil" but a multi-team project.

Key message to leadership: This isn't a PKI team project — it's an infrastructure modernization initiative that touches networking, DevOps, security, and application teams.