CA/Browser Forum and 47 Days: Everything you need to know

On April 11, 2025, the CA/Browser Forum officially passed Ballot SC-081v3. The headlines declared it unanimous. But behind that headline lies a more nuanced story of industry debate, practical concerns, and a collective bet on automation’s future.

Most coverage of this decision has focused on its implications for organizations and on how to prepare. That’s important. But understanding why the industry voted this way and what unresolved concerns remain offers something more valuable: insight into where PKI is heading and the trade-offs the ecosystem has accepted.

The Anatomy of a “Unanimous” Vote

Let’s start with the numbers everyone cites: 29 votes in favor, zero opposed. Technically accurate. But that framing obscures what actually happened in the official vote tally. There were a total of 34 active participants in vote.

 

Vote Category	Count	Noteable Organization
Yes (Certificate Issuers)	25	Amazon, DigiCert, GlobalSign, GoDaddy, Let’s Encrypt, Sectigo, SSL.com
Yes (Certificate Consumers)	4	Apple, Google, Microsoft, Mozilla
Abstain	5	HARICA, JPRS, SECOM Trust, TWCA, and one other
No	0	None
Total Voting Pool	34

Five certificate authorities abstained. That’s roughly 17% of voting CAs choosing not to endorse the measure, despite supporting shorter lifespans in principle. Their reasoning, documented in the public voting record, reveals concerns that will likely resurface as implementation proceeds.

What the Abstaining CAs Actually Said

TWCA, a Taiwanese certificate authority, articulated a concern that others likely share but didn’t voice as directly. In their official voting statement:

“We believe that reducing the validity period from 100 days to 47 days is too drastic. For some websites that already use certificates, if they ultimately fail to deploy automated certificate management, they might abandon HTTPS in favor of HTTP.” — TWCA, Ballot SC-081v3 Voting Statement.

This isn’t an abstract worry. TWCA identified a specific user experience issue. In current browser interfaces, an HTTP site displays a relatively subtle warning in the address bar. However, an HTTPS site with an expired certificate triggers a full-page warning that blocks access. For site operators struggling with automation, the path of least resistance might be removing HTTPS altogether.

SECOM Trust Systems, a Japanese CA, adopted a more measured stance in its abstention statement: it agreed with a shorter validity period in principle, sought to signal that automation is inevitable, but couldn’t fully endorse the final 47-day target. JPRS expressed similar sentiments in their vote.

HARICA, the Greek academic CA, went further in earlier discussion periods. They argued that 100-day certificates would provide sufficient security improvement without the operational strain of monthly renewals. They questioned whether the incremental security benefit of moving from 100 to 47 days justified the additional complexity.

Why 47? The Math Behind the Number

The 47-day figure wasn’t arbitrary, despite initial skepticism from some forum participants. Apple’s Clint Wilson, the ballot’s author, explained the reasoning in discussion threads.

A common practice in automated certificate management is to renew certificates at two-thirds of their remaining lifetime. For a 47-day certificate, renewal occurs around day 30. This creates a clean monthly renewal cycle that aligns well with existing automation patterns and monitoring intervals.

Wilson initially proposed 45 days. The adjustment to 47 accommodates CAs and software integrations that issue certificates with exactly 45-day validity, providing a buffer without technically exceeding the maximum.

Valadity Period	Renewal 2/3 Lifetime	Practical Cycle
398 days (current)	265 days	Annual, with buffer
200 days (March 2026)	133 days	Roughly every 4 months
100 days (March 2027)	66 days	Bi-monthly
47 days (March 2029)	30 days	Monthly

The progression follows a deliberate pattern: each step roughly halves the previous validity period. From 398 to 200 to 100 to 47. This isn’t coincidental. It mirrors the historical trajectory from 5-year certificates in the early 2010s down to today’s 398-day maximum.

The Real Controversy: 10-Day Domain Validation

Certificate validity reduction received the most attention, but forum participants debated DCV reuse periods more intensely. The ballot drops the domain validation reuse period from 398 days to 10 days by March 2028.

Organizations must prove domain ownership not annually or monthly, but every week-and-a-half. For certificate lifecycle automation systems, this requires near-continuous validation infrastructure. For organizations still relying on manual processes, it’s another layer of operational complexity.

  “Why 10 days? We should be clear about the problems DCV reuse reduction is solving. More detail would be helpful.” — Forum participant, February 2025 Server Certificate Working Group teleconference

The rationale connects to domain ownership changes. When a domain changes hands, the previous owner’s certificates remain valid until expiration. With 398-day validity and 398-day DCV reuse, a domain transfer could leave certificates in the last owner’s control for nearly two years. Shorter DCV windows ensure that only current domain controllers can request new certificates.

Critics argued that this threat model is limited. As HARICA noted in their discussion contribution, exploiting old certificates after a domain transfer requires an attacker who can manipulate DNS and intercept network traffic. Domains transfer ownership; the DNS immediately points elsewhere. The practical attack surface may be smaller than the ballot implies.

Browser Vendors: The United Front

While CAs debated details, browser vendors presented remarkable alignment. All four major browsers, which together account for over 95% of the desktop browser market, voted yes without qualification.

Google had been pushing for shorter certificates since 2019, when its initial 90-day proposal failed. Apple picked up the mantle in 2024 with SC-081, as detailed in coverage of Apple’s initial proposal. Microsoft and Mozilla followed immediately once voting opened.

This matters because browser root programs ultimately determine what certificates are trusted. CAs can issue whatever they want, but if browsers don’t trust those certificates, they’re worthless for public web traffic. The browser vendors’ unified support, as noted in industry recaps of the Tokyo Forum meeting, made the ballot’s passage effectively inevitable, regardless of CA sentiment.

Google’s vote statement was terse: “Google votes Yes on Ballot SC-081v3.” No elaboration needed. They’d been advocating this direction for six years.

The Revocation Problem Nobody Solved

One of the most interesting threads in the SC-081 discussions concerned certificate revocation. The ballot’s preamble argues that current revocation mechanisms don’t work reliably at web scale. Certificate Revocation Lists grow unwieldy. OCSP checking has privacy implications and isn’t enforced by most browsers

Shorter certificate lifespans sidestep this problem. If certificates only last 47 days, revocation becomes less critical. Compromised certificates naturally expire before revocation systems would have propagated anyway.

But as forum participant Dimitris Zacharopoulos asked during the February 2025 teleconference: if we’re admitting revocation doesn’t work, should we be developing better alternatives rather than just shortening validity periods?

The ballot doesn’t answer this. It accepts revocation limitations as given and uses shorter lifespans as the workaround. Whether this represents pragmatic engineering or technical debt remains an open question.

How Prepared Is Your Organization?

Discover all your public certificates and their expiration dates to prepare for March 2026 deadlines.
Get Your Free SSL/TLS Scan

What the Ballot Explicitly Does Not Cover

SC-081v3’s scope is narrower than many realize. The TLS Baseline Requirements only govern certificates “intended to be used for authenticating servers accessible through the Internet.” This leaves significant territory untouched:

Private PKI: Internal certificates used within corporate networks aren’t subject to CA/B Forum rules. Organizations can continue to issue one-year, two-year, or longer-term certificates for internal services. The 47-day mandate applies only to publicly trusted certificates.
Non-web TLS: Certificates used for email encryption (S/MIME), code signing, document signing, and other purposes operate under different baseline requirements and have different validity rules.

IoT and embedded devices: The ballot acknowledges that many devices can’t easily update certificates. While IoT device identity management is increasingly essential, the TLS Baseline Requirements don’t directly govern how manufacturers handle device certificates.

This scope limitation explains why the ballot passed. It applies to a well-defined set of certificates where automation is already standard (e.g., public websites) rather than attempting to govern every certificate use case.

The “Known Unknowns” Clause

Perhaps the most revealing passage in the ballot text addresses uncertainty directly:

“Because the reduction of certificate validity and data reuse periods requires changes far beyond the direct scope of the CA/Browser Forum, it is functionally impossible to determine all possible variables and factors impacted prior to adopting associated changes. Because we need to address known unknowns as well as unknown unknowns, it’s important to provide mechanisms for…” — Ballot SC-081v3 Preamble.

The ballot explicitly acknowledges “known unknowns” and “unknown unknowns.” It outlines multiple changes over an extended timeline, enabling course corrections if problems arise. The phased approach isn’t just about giving organizations time to adapt. It’s about giving the industry time to discover what breaks.

This acknowledgement of uncertainty is notable for a standards body. Rather than presenting the changes as settled science, the Forum has structured the ballot to accommodate learning along the way. The phased timeline creates natural checkpoints where the industry can assess real-world impact before the subsequent reduction takes effect. It’s a pragmatic approach that balances conviction in the direction with openness to refinement in the details.

What This Means for Organizations

The inside story of SC-081 reveals several insights for organizations preparing for the transition:

• The timeline is firm but not immutable. The ballot includes mechanisms for “altering course when necessary.” If widespread implementation problems emerge, expect discussion of timeline adjustments. That said, betting on delays would be unwise. Browser vendors are committed and experts have said there is a 100% chance the deadlines will stick.
• Automation isn’t just recommended; it’s the explicit intent. Multiple forum participants stated that the ballot’s purpose is to make automation “inevitable.” Organizations viewing this as merely a compliance exercise are missing the point. The industry has decided that manual certificate management is incompatible with modern web security. Automating certificate lifecycle management is now table stakes.
• The 10-day DCV window may cause more immediate pain than the 47-day validity. Organizations that focus solely on renewal frequency may be caught off guard by near-continuous domain validation requirements. Ensure your certificate lifecycle management platform supports automated domain verification via protocols such as ACME, not just renewal.
• Private PKI provides breathing room. If you have internal services that don’t require public trust, consider whether enterprise PKI modernization with longer-lived internal certificates makes sense. PKI as a Service solutions can help you maintain separate policies for public and private trust.

The Broader Pattern

Step back from the specifics of SC-081, and a larger pattern emerges. Certificate validity has been shrinking for fifteen years: from 5+ years pre-2011, to 3 years, to 2 years, to 1 year, and now toward 47 days. Each reduction prompted predictions of operational chaos. Each time, the industry adapted.

The abstaining CAs’ concerns about sites abandoning HTTPS echo similar warnings from previous validity reductions. Those predictions haven’t materialized at scale. HTTPS adoption has continued to grow, now exceeding 95% of Chrome page loads, according to Google’s transparency report. Organizations that invested in closed-loop automation during previous transitions found each subsequent change easier to handle.

This doesn’t mean current concerns are invalid. The jump from annual to monthly renewal is qualitatively different from previous reductions. But historical precedent suggests the industry tends to underestimate its capacity to adapt when the alternative is broken security infrastructure.

Looking Forward: What Comes After 47 Days?

The ballot text hints at future possibilities. If 47 days succeeds, what prevents further reduction? Let’s Encrypt has already tested 6 day certificates. Apple’s ballot preamble discusses validity periods in abstract terms, suggesting that 47 days isn’t necessarily the endpoint.

More immediately, the industry is preparing for the transition to post-quantum cryptography. NIST standards finalised in 2024 set a trajectory toward deprecating RSA and current elliptic curve algorithms by 2030. The EU’s recent PQC roadmap adds regulatory pressure to this timeline. Organizations that build crypto-agility for 47 day certificates will find those same capabilities essential for algorithm migration.

The CA/Browser forum change in SC-081 isn’t just about shorter certificates. It’s about transforming PKI from a set-and-forget infrastructure component into a continuously managed, highly automated system. That transformation serves multiple purposes: tighter security windows, faster response to compromises, and foundational capability for future cryptographic changes. Understanding the core principles of certificate lifecycle management becomes essential for navigating this evolution.