The takeaways, in brief
- The CA/Browser Forum voted 25-0 to reduce TLS certificate validity from 398 days to 47 days across three phases ending March 2029.
- At 47-day lifetimes, a portfolio of 1,000 certificates generates thousands of annual renewal operations — a major increase over today’s workload.
- Many organizations already experience certificate-related outages under the current 398-day cycle.
What Ballot SC-081v3 Mandates
Every publicly trusted TLS certificate issued after March 2026 carries a maximum validity of 200 days. That’s a requirement that the CA/Browser Forum’s Ballot SC-081v3 passed unanimously in April 2025.
The ballot outlines a three-phase rollout over three years wherein it compresses two independent timers: certificate validity (i.e., how long a certificate can remain active) and Domain Control Validation (DCV) reuse (i.e., how long a certification authority can rely on a previous domain ownership proof before requiring fresh validation).
Here’s a breakdown of each of the ballot’s three mandated phases:
| Phase | Effective Date | Max Certificate Validity | Max DCV Reuse Period |
|---|---|---|---|
| Phase 1 | March 15, 2026 | 200 days | 200 days |
| Phase 2 | March 15, 2027 | 100 days | 100 days |
| Phase 3 | March 15, 2029 | 47 days | 10 days |
No certificate type is exempt. OV and EV certificates follow the same schedule. Private and internal PKI operated outside the CA/Browser Forum’s trust stores is not directly affected, but many organizations will align internal policies to match.
The message from the industry’s certificate issuers and every browser vendor is unambiguous: Shorter certificate lifespans are coming, and no amount of operational objection will change the trajectory.
Industry Players Want Short-Lived Certificates
The vote on Ballot SC-081v3 didn’t arrive out of nowhere. It follows a years-long pattern of validity reductions that have consistently outpaced industry readiness.
In September 2020, Apple limited Safari to accept certificates with a maximum validity of 398 days (~13 months). Google and Mozilla followed, and the industry adjusted. That 398-day ceiling has been the status quo for more than five years.
Mozilla’s rationale for supporting the 398-day limit outlined three principles that still underpin SC-081v3: faster incident response when certificates need to be replaced after a compromise; a reduced key exposure window; and faster deprecation of outdated algorithms.
The historical evidence supports this: Phasing out MD5 certificate signatures took five years when certificates were valid for five years; phasing out the SHA-1 hashing algorithm after it was cryptographically broken took three years when certificates were valid for three years. Shorter lifetimes accelerate the industry’s ability to respond to cryptographic weaknesses.
SC-081v3 takes this logic to its conclusion. A 47-day certificate reduces the compromise window by 88%, compared to a 398-day certificate. If a future algorithm vulnerability is discovered, as SHA-1’s was, the entire web can rotate to new certificates in a matter of weeks rather than years.
Why Manual PKI Already Breaks at 398 Days
These operational impacts are alarming for many organizations. The industry already struggles with manual certificate management on the current 398-day validity period.
The Ponemon Institute’s 2026 PKI Modernization Report, surveying 1,833 IT and security practitioners, found that 56% of organizations report unplanned outages caused by certificate expiration or configuration errors. The top causes: misconfigurations (50%), expired certificates triggering unplanned outages (49%), and lack of visibility into certificate inventory (38%).
And the longer it takes for employees to resolve the issues, the more each failure costs.
There are four structural reasons manual processes fail at scale:
- Human throughput limits. A 47-day validity period means companies who currently handle roughly 1,000 renewals yearly will need 11.2 full-time employees to process renewals. Most IT teams don’t have 11 employees to spare just for certificate operations.
- Spreadsheet tracking fails. With roughly half of organizations relying on manual processes, most certificate tracking lives in spreadsheets or shared documents. Teams cannot manually track 21 daily renewal events without missing deadlines.
- Institutional knowledge dependency. Manual processes rely on individuals knowing which servers host which certificates, what the validation method is, and where renewal credentials are stored. When those individuals leave, take vacation, or are reassigned, their knowledge leaves, too.
- Weekend and holiday gaps. Certificate expiration doesn’t observe business hours. A 47-day cycle means renewals regularly fall on holidays and weekends. Manual processes that depend on business-hours staffing create predictable outage windows on non-work days.
It’s Not Just Short-Lived TLS Certificate Lifetimes: The Hidden Disruption of DCV Reuse
While much of the attention surrounding Ballot SC-081v3 focuses on the major operational impacts of certificate validity, the DCV reuse timeline requirements are just as pressing.
By 2029, organizations must re-prove domain ownership for nearly every renewal cycle. The ultimate 10-day DCV reuse window means that pre-validating domains and stockpiling certificates — a common strategy for simplifying manual workflows — stops working entirely.
Manual DNS or HTTP challenge validation at this frequency becomes a full-time job — separate from the certificate renewal work itself. And unlike certificate issuance, which can be queued, DCV challenges are time-sensitive. A DNS record that isn’t updated within the validation window means the renewal fails and the certificate expires.
The scale of the problem is immense. As of this article’s creation, approximately 100.83 million SSL certificates were detected across the internet. Each one will eventually cycle through the 47-day renewal cadence. Each renewal will require fresh domain validation within the 10-day reuse window. The aggregate DCV workload across the internet will increase by an order of magnitude.
Between the monumental increases in certificate renewals and domain validations, the real question many industries are facing now is how many outages organizations will absorb before they embrace automation.
A Defense Framework for the 47-Day World
Organizations have three years to prepare, and automated certificate management is the only feasible way forward. The following framework addresses the operational, technical, and strategic dimensions of the transition to these shorter lifetimes.
1. Inventory Every Certificate
You can’t automate what you can’t see. The Ponemon Institute found that 51% of financial services organizations don’t inventory every certificate in their environment. Certificate discovery — scanning networks, cloud environments, and container orchestration platforms for all active certificates — is the prerequisite for any automation initiative.
2. Automate Certificate Renewal End to End
Deploy ACME clients across all systems hosting public TLS certificates. ACME handles domain validation, certificate issuance, and installation without human intervention.
For organizations with heterogeneous infrastructure, certificate lifecycle management platforms provide a centralized control plane across multiple CAs, server types, and environments.
3. Eliminate DCV Bottlenecks
The 10-day DCV reuse window means domain validation must be automated alongside certificate issuance. DNS-01 challenges require API access to DNS providers. HTTP-01 challenges require automated file placement on web servers. Organizations should audit their DNS infrastructure for API support and migrate away from providers that require manual record updates.
4. Treat Legacy Systems as High-Risk
Embedded devices, older appliances, IoT gateways, and other systems that can’t support automated renewal face the greatest risk. These systems require manual certificate updates and operate with no safety net at 47-day lifetimes. Organizations should inventory legacy systems, evaluate replacement timelines, and consider reverse proxy architectures that offload TLS termination to automated infrastructure.
5. Build Monitoring That Catches Silent Failures
The 47-day validity creates a 30-day renewal cycle with a 17-day safety buffer. If an automation system fails silently — a common occurrence with misconfigured cron jobs, expired API credentials, or DNS provider outages — the organization has less than three weeks before services go dark. Certificate monitoring must move from periodic audits to continuous alerting that flags failed renewals within hours, not days.
6. Align Internal PKI Policies
Ballot SC-081v3 doesn’t govern private PKI. But organizations that run separate validity policies for public and internal certificates create operational complexity. Aligning internal certificate lifetimes with the public mandate simplifies tooling, training, and monitoring — and reduces the attack surface across the entire certificate estate.
How Cloud-Managed PKI Addresses the 47-Day Mandate
The 47-day mandate targets public TLS server certificates. But the operational model it requires — automated issuance, short-lived validity, continuous renewal — isn’t new. Modern enterprise PKI has operated this way for years.
SecureW2 PKI is built on this model. Certificates are issued dynamically through ACME, dynamic SCEP, and gateway APIs integrated with MDM platforms — Intune, Jamf, Google Workspace, and Kandji — and identity providers like Entra ID and Okta. Certificate issuance, renewal, and revocation are automated from the moment a device enrolls.
And because SecureW2 PKI and Cloud RADIUS are fully cloud-native, the infrastructure to absorb higher renewal volumes already exists without on-premises servers to scale, patch, or maintain.
