SC081v3 and the 47‑Day Certificate Era: What the CA/B Forum Just Set in Motion

13 Apr 2025 – On April 11, 2025, the CA/Browser Forum published Ballot SC081v3, “Introduce Schedule of Reducing Validity and Data Reuse Periods,” alongside a draft of the TLS Baseline Requirements updated for IPR review.  The ballot sets a phased schedule that shrinks maximum publicly trusted TLS server certificate validity from 398 days to 200 days (March 15, 2026), then 100 days (March 15, 2027), and ultimately 47 days (March 15, 2029).  In parallel, it tightens how long CAs may reuse validation evidence – most dramatically, dropping domain/IP validation reuse to just 10 days by March 15, 2029. 

The ballot’s rationale is not “post-quantum compliance” per se. It is a Web PKI risk‑management play: certificates are described as “point‑in‑time” assertions that become stale; misissuance and key compromise happen; and revocation mechanisms (CRLs/OCSP) are framed as insufficiently reliable at Internet scale. Shorter lifetimes and shorter validation reuse windows are positioned as proactive containment – shrinking the time that stale or improperly issued assertions can remain usable and improving the ecosystem’s ability to respond quickly to cryptographic deprecations. 

Procedurally, “days after publication,” what can be said with confidence is narrow but important: the ballot shows 0 NO votes among both issuers and consumers, passed the Forum’s bylaw thresholds, and entered a 30‑day IPR Review Period (April 13 → May 13, 2025).  The accompanying BR draft is explicitly labeled “for Review Notice purposes only (not yet in effect).”  Practical enforcement timing beyond the schedule table – particularly how and when browser/root programs will implement it in their own policies – should be treated as unspecified unless separately confirmed. 

For post‑quantum risk, SC081v3’s direct security contribution is best understood through the “Trust Now, Forge Later” (TNFL) lens: TNFL warns that signatures and certificates trusted today (often RSA/ECDSA‑based) can become forgeable once cryptographically relevant quantum computers arrive.  Shorter certificate validity compresses the window in which a compromised (or later‑derived) server private key can be used with a still‑valid certificate without depending on revocation. But SC081v3 does not make TLS certificates post‑quantum‑safe on its own; it mainly forces operational crypto agility – the ability to rotate keys, certificates, and ultimately algorithms faster – which aligns with both NIST’s definition of crypto agility and the operational demands of a PQ migration. 

What SC081v3 changes

Two clocks get shortened: certificate lifetime and “validation evidence reuse”

SC081v3 is easiest to read as a policy that tightens two separate but coupled time bounds:

1. Maximum certificate validity (how long the certificate can remain cryptographically “acceptable” to clients based solely on notBefore/notAfter). 
2. Maximum validation data reuse (how long a CA can reuse prior validation evidence – e.g., domain control or organization identity – when issuing a new certificate). 

The TLS Baseline Requirements (as circulated for review) are explicit that these requirements apply to publicly trusted TLS server certificates and are “not mandatory for Certification Authorities unless and until they become adopted and enforced by relying‑party Application Software Suppliers.”  In other words: the ballot sets the baseline standard, but browsers/root programs ultimately operationalize it.

Maximum certificate validity schedule

The updated BR text adds a schedule in Section 6.3.2. The operative language is “MUST NOT have a Validity Period greater than …” for each phase; the “SHOULD NOT” line is guidance to avoid boundary conditions. 

• Issued before March 15, 2026: MUST NOT exceed 398 days. 
• Issued on/after March 15, 2026 and before March 15, 2027: MUST NOT exceed 200 days. 
• Issued on/after March 15, 2027 and before March 15, 2029: MUST NOT exceed 100 days. 
• Issued on/after March 15, 2029: MUST NOT exceed 47 days. 

The BR draft also clarifies a “day” as 86,400 seconds and advises that certificates “SHOULD NOT be issued for the maximum permissible time by default” to avoid edge/rounding issues. 

Validation data reuse schedule

SC081v3 also expands Section 4.2.1 to specify how long prior validation data may be reused, split into two buckets:

• Subject Identity Information (SII) validation reuse (OV/EV identity details – i.e., “everything but the domain/IP”).
• Domain name and IP address validation reuse (SAN‑related validation).

The BR draft shows:

SII reuse (OV/EV‑style identity evidence):

• Issued before March 15, 2026: 825 days
• Issued on/after March 15, 2026: 398 days 

Domain/IP reuse (DCV evidence):

• Issued before March 15, 2026: 398 days
• Issued March 15, 2026 → before March 15, 2027: 200 days
• Issued March 15, 2027 → before March 15, 2029: 100 days
• Issued on/after March 15, 2029: 10 days 

A key tightening clause follows the table: “In no case may a prior validation be reused” if the underlying data/documents are older than the maximum permitted reuse window at issuance time. 

Table: current vs proposed validity and reuse periods

The schedule below is taken from the BR draft tables and the 6.3.2 schedule text circulated for review notice. 

Why the Forum proposed these changes

SC081v3’s “why” section is unusually expansive for a ballot. It reads like a systems argument: certificate lifecycle policy is not a narrow CA rule – it is a lever that shapes how the entire Web PKI behaves under stress.

The “point‑in‑time truth” problem and stale assertions

The ballot explicitly frames certificates as snapshots: at issuance time, certified data is correct; over time, it diverges. Therefore, reducing both certificate lifetimes and validation data reuse “increases the average net reliability of certificates.”  The key nuance here is that the ballot targets both the artifact (the certificate) and the pipeline (how often the system must re‑prove real‑world control/identity to keep issuing new artifacts).

Curtailing “formerly‑correct” certificates and misissuance blast radius

The ballot argues that certificates with formerly‑correct contents create risk when domains expire/change hands, or when key control is lost; shorter lifetimes reduce how long such certificates remain valid without any action by other parties.  It also argues that more frequent validation and shorter maximum validity reduce the impact of CA process failures – limiting how long bad validation practices can “perpetuate” by reissuing certificates from stale evidence. 

A deep skepticism of revocation as the primary safety net

One of SC081v3’s most consequential claims is operational: certificate validity enforcement by relying parties is “incredibly reliable,” while certificate status services (CRLs/OCSP) are described as inadequate at Internet scale due to privacy, performance, timeliness, and multi‑party dependency.  SC081v3 positions lifetime reduction as a proactive control that does not require perfect revocation behavior to be effective.

Crypto agility as an explicit “secondary” benefit

The ballot states that deprecating cryptographic algorithms is complex and can require rapid response, sometimes without warning; therefore, shorter maximum validity “provides substantial support” for transitioning between deployed and supported cryptography.  This line is where SC081v3 crosses into post‑quantum relevance: even if PQ algorithms are not in the BR today, the ballot is trying to make the Web PKI more migratable.

Procedural status days after publication

What is known from the publication itself

The April 11, 2025 publication includes (a) voting results, (b) bylaw checks, and (c) a formal IPR review notice.

Days after publication, the defensible procedural summary is:

• Vote outcome: No NO votes. Certificate issuers: 25 YES, 5 ABSTAIN. Certificate consumers: 4 YES, 0 ABSTAIN. 
• Ballot thresholds: The post states the bylaw requirements and quorum were “MET.” 
• IPR Review Period: start April 13, 2025; end May 13, 2025 (30 days). 
• Text status: The BR document circulated is “for Review Notice purposes only (not yet in effect).” 

What remains unspecified at “days after”

Several items matter operationally but are still unspecified:

• Exact “effective enforcement” in browsers/root programs: The BR itself notes requirements become mandatory only when adopted/enforced by relying‑party application software suppliers; the ballot does not embed each browser’s implementation plan. 
• Grandfathering mechanics beyond “issuance date”: The schedule rules are unambiguous that limits apply based on issuance date. Whether any relying party introduces additional constraints or earlier enforcement is outside the ballot text and should be validated separately. 

Early ecosystem reactions surfaced in the mailing list

The ABSTAIN votes weren’t silent. They provide an early read on where practical pain is expected.

• SECOM Trust Systems explicitly supported the direction but said they could not justify 47 days instead of 90 days given preparation time and cost tradeoffs. 
• Japan Registry Services abstained citing uncertainty about whether the WebPKI ecosystem can realistically achieve the timeline, and requested continued discussion based on real migration progress. 
• IdenTrust abstained, supporting DV automation proposals but remaining unconvinced about security benefits from reducing OV/EV validity further. 
• A representative from TWCA warned of UX‑driven perverse incentives: sites that fail to automate could abandon HTTPS for HTTP because certificate-expired interstitials are more disruptive than typical HTTP warnings. 

These comments matter because SC081v3 is, implicitly, a bet on automation maturity across the long tail of operators.

Post-quantum security analysis through the Trust Now, Forge Later lens

Definitions used in this analysis

Validity period. In X.509, the validity period is the interval bounded by notBefore and notAfter.  In Web PKI operations, this is the time in which browsers will accept the certificate as time‑valid (subject to other checks).

Data reuse period. In the TLS Baseline Requirements context, this is the maximum age of prior validation data/documents/completed validations that a CA may reuse when issuing a certificate. SC081v3 sets explicit tables for SII reuse and for domain/IP reuse. 

Key reuse. Reusing the same subject key pair across multiple certificate issuances or renewals. SC081v3 is primarily about certificate validity and validation freshness; it does not, by itself, guarantee that new certificates come with new keys. 

Cryptographic agility (crypto agility). NIST defines crypto agility as the capabilities needed to replace/adapt cryptographic algorithms across systems “without interrupting the flow of a running system,” explicitly noting PQC migration as a motivating example. 

Post‑quantum‑safe signatures. A digital signature scheme designed to remain secure against adversaries with large‑scale quantum computers. NIST’s FIPS 204 specifies ML‑DSA and states it is believed secure even against adversaries with a large‑scale quantum computer. 

TNFL recap and its Web PKI meaning

My TNFL framing is blunt: we may trust signatures/certificates today, but once quantum machines can break RSA/ECDSA (e.g., via Shor’s algorithm), attackers can forge signatures and make malicious artifacts appear authentic – an integrity collapse, not just a confidentiality leak. 

In Web PKI, TNFL risk can materialize along (at least) two paths:

1. “Derive the server private key” (quantum breaks RSA/ECC keypairs): an attacker who can compute a server’s private key can impersonate the server during TLS handshakes as long as they can present a certificate that chains to trust. 
2. “Forge CA signatures” (quantum breaks CA signing keys): an attacker could mint fraudulent certificates that validate as if issued by real CAs – far more systemic. 

SC081v3 is not a PQ signature transition plan. But it does shrink time windows and pressure the ecosystem toward rapid rotation – capabilities you need in either scenario.

What SC081v3 improves for PQ/TNFL—realistically

Shorter “free ride” for private‑key compromise when revocation isn’t perfect.

SC081v3’s core security mechanism is to make certificate validity a hard upper bound on damage even when revocation is delayed or unreliable – explicitly one of the ballot’s motivations. 

For TNFL‑style future key compromise, the logic is the same: if (someday) a TLS server key can be computed from its public key, the attacker’s usefulness window is limited by certificate lifetime if the operator rotates keys and certificates. The jump from 398 days to 47 days is a ~8.5× reduction in the maximum window per certificate. 

Forcing function for crypto agility and algorithm transitions.

The ballot explicitly links reduced validity to faster responses to cryptographic deprecations, calling out “transitioning between deployed and supported cryptography” as a key benefit.  This aligns with NIST’s crypto agility framing that PQC migration demands algorithm‑switch capability across protocols and infrastructure. 

This is also echoed in CA vendor messaging close to the ballot’s approval. In its April 14, 2025 press release, Sectigo positioned the change as improving “crypto agility” and preparing for “quantum computing challenges.”  And DigiCert highlighted the “much tighter window” created by 10‑day DNS/IP validation reuse, using it as evidence that automation (and therefore rapid lifecycle motion) must become the norm. 

Reduced stale‑authorization risk via shorter validation reuse.

The domain/IP reuse schedule is arguably the most under‑appreciated security change: by 2029, a CA cannot “coast” on domain validation older than 10 days when issuing a new certificate.  This directly targets real‑world control drift: domains change owners, DNS operators change, cloud accounts get seized or repurposed – problems the ballot flags as “security‑relevant events” where third parties can impersonate domains. 

Where SC081v3 falls short for PQ/TNFL

Short lifetimes do not equal post‑quantum trust.

TNFL is fundamentally about signature algorithm failure. SC081v3 does not replace RSA/ECDSA with PQ‑safe signatures in TLS certificates; it only makes the ecosystem cycle faster. For actual “post‑quantum‑safe signatures,” you need adoption of PQ standards such as ML‑DSA (FIPS 204) and ecosystem support for those signatures in certificate profiles, libraries, and clients. 

If keys are reused, lifetime reduction can underperform.

If an operator renews certificates every 47 days but keeps the same RSA/ECDSA key pair for years, then a one‑time private‑key compromise (or future quantum computation) remains valuable across renewals. SC081v3 does not guarantee key rotation; the policy benefit depends on operators pairing short‑lived certs with modern key management practices. 

CA‑level TNFL (forged issuer signatures) is bigger than leaf lifetime.

If a quantum attacker can forge CA signatures, the problem becomes trust anchor and intermediate agility, not just leaf rotation. SC081v3’s value here is indirect: it incentivizes operational agility and makes “fast change” culturally and technically mandatory – but it does not, on its own, solve a compromised trust anchor. 

Costs, friction, and second‑order ecosystem effects

Operational burden: renewal becomes continuous, not periodic

Under SC081v3’s end state, a public TLS cert is effectively on a ~monthly cadence (47 days). Vendors immediately framed this as automation‑or‑outage territory. 

The ballot itself anticipates this transformation, arguing that increased deployment of “robust, bi‑directional automation” improves lifecycle management quality and availability across the ecosystem.  But the mailing list abstentions are the warning: not everyone believes the operational cost curve is justified by the incremental security gain of 47 days versus (say) 90. 

CA/PKI ecosystem impacts: more issuance events, more validation churn

By 2029, even if certificate issuance is automated, the 10‑day domain/IP reuse cap means domain validations must be refreshed frequently if you are issuing on a 47‑day rhythm – unless you cluster issuances into tight windows. 

That implies increased load and complexity for:

• CA validation infrastructure and customer support escalation paths. 
• Enterprise certificate inventory, deployment pipelines, and incident response (because expiry is no longer “next year’s problem”). 

Compatibility and “enterprise friction” risk

Even if browsers accept the new regime cleanly, enterprises often have hidden dependencies: legacy appliances, brittle change‑management processes, audit cycles, and procurement workflows that assume annual validity. SC081v3 deliberately breaks that assumption.

The TWCA mailing list comment captures a non‑obvious risk: if parts of the ecosystem fail to evolve, some operators might choose the wrong adaptation – opting out of HTTPS rather than coping with frequent and highly visible certificate expiration failures. 

Cost: not necessarily more certificate fees, but more lifecycle engineering

Vendor communications tend to emphasize that the real cost is operational: inventory, automation, and governance.  The ballot’s success depends on the premise that this cost is worth paying because the alternative—year‑long windows for stale assertions, misissuance persistence, and slow cryptographic response—is worse. 

Concrete examples, compressed attack windows, and lifecycle timeline

Example: key compromise window (classical today; quantum tomorrow)

Assume a TLS server private key is compromised at day 30 after issuance, and revocation is delayed or unreliable (a risk the ballot explicitly emphasizes when critiquing CRL/OCSP dependence). 

• Under the 398‑day maximum, the attacker potentially gets ~368 more days of clean impersonation with a valid cert. 
• Under the 47‑day maximum, the attacker gets ~17 more days—if the operator replaces the cert/key promptly at expiry and does not reuse the compromised key. 

This is the most defensible “short lifetime” argument in a TNFL‑aware world: shorter validity reduces the maximum time an attacker can exploit a compromised trust assertion without relying on revocation working perfectly. 

Example: stale domain control and “validation replay”

Consider a domain validated on Day 0. Control of the domain changes on Day 120 (sale, expiration, takeover). With long reuse windows, a CA might still issue certificates to the wrong party based on stale validation evidence.

• With 398‑day domain validation reuse, stale validations could be reused for many months after the control change. 
• With 10‑day domain validation reuse (2029+), stale validation replay becomes far harder: the CA must obtain fresh proof within 10 days of issuance, and must not reuse a prior validation if the underlying data/documents exceed the reuse window. 

This is not a PQ‑specific benefit, but it’s highly relevant to the broader trust‑fabric fragility TNFL warns about: when trust foundations change hands faster than the PKI refreshes, attackers exploit the gap. 

Related Content

Pinnacle Architecture: 100,000 Qubits to Break RSA-2048, but at What Cost?

Quantum Low-Density Parity-Check (qLDPC) Codes

Batch Exploration Attacks on Streamed Data Models

The $160M Wintermute Hack: Inside Job or Profanity Bug?