TLS Certificate Validity Reduced to 47 Days: What to Know

Quick answer: The CA/Browser Forum’s SC-081v3 ballot, proposed by Apple and endorsed by Sectigo, has been ratified. It cuts the maximum validity of public TLS/SSL certificates from 398 days to 200 days by March 15, 2026, 100 days by March 15, 2027, and 47 days by March 15, 2029. Enterprises that still issue and renew certificates manually need to automate before the 2027 milestone or risk outages.

TLS certificate validity is no longer an open question. What began in 2024 as Apple’s proposal to the CA/Browser (CA/B) Forum to shorten the maximum lifespan of public TLS/SSL certificates is now ratified industry policy. Ballot SC-081v3 passed on April 14, 2025, with Sectigo’s endorsement, and it phases certificate validity down from today’s 398-day maximum to 47 days by 2029. Google had earlier floated a separate proposal to cut validity to 90 days, but the industry converged on the CA/B Forum’s more aggressive schedule, which is the one now in force.

For organizations managing digital certificates at any scale, this is a shift in daily operations, not a distant compliance deadline. Renewal frequency roughly doubles at the first milestone, then doubles again, then again, until certificates that once lasted more than a year need to be reissued every seven weeks. This article lays out the ratified timeline, what it means for PKI, security, platform, and compliance teams, and how to build a realistic migration plan before the shorter windows arrive.

Key Takeaways

• CA/B Forum ballot SC-081v3 is ratified policy, not a proposal. Maximum public TLS certificate validity drops to 200 days on March 15, 2026, 100 days on March 15, 2027, and 47 days on March 15, 2029.
• Domain Control Validation (DCV) reuse periods shrink on the same schedule: 200 days, then 100 days, then 10 days.
• DigiCert’s July 2025 Trust Pulse Survey found that 45% of enterprises had already experienced certificate-related downtime, and 37.5% traced outages directly to expired certificates, under today’s longer validity windows.
• Manual certificate tracking cannot scale to a 47-day renewal cadence. Automated certificate lifecycle management using protocols like ACME, SCEP, and EST moves from a convenience to a requirement.
• PKI, security, platform, and compliance teams each carry distinct action items on this timeline, mapped out in the impact table below.

What Changed: From Apple’s Proposal to Ratified CA/B Forum Policy

Apple first raised the idea of a 45-day certificate lifespan with the CA/B Forum in 2024, arguing that shorter validity periods limit how long a compromised private key stays useful to an attacker and force the ecosystem toward automation. Sectigo endorsed the proposal in January 2025, and the CA/B Forum passed the resulting ballot, SC-081v3, on April 14, 2025. The final ratified number is 47 days, not 45, and the change rolls out in three stages rather than all at once.

The Phased Validity Timeline

The rollout gives certificate authorities, browsers, and enterprises time to adjust before the shortest lifespan takes effect. Each milestone reduces both the maximum certificate validity and the DCV reuse period together.

Effective Date	Requirement	Who Is Impacted	Action Needed
March 15, 2026	Maximum TLS certificate validity reduced to 200 days; DCV reuse reduced to 200 days	Every organization issuing or managing public TLS certificates	Move certificate issuance and renewal onto an automated CLM platform if this is not already in place
March 15, 2027	Maximum TLS certificate validity reduced to 100 days; DCV reuse reduced to 100 days	Organizations with certificate fleets beyond a few hundred assets	Confirm automation covers every production certificate and remove remaining manual issuance paths
March 15, 2029	Maximum TLS certificate validity reduced to 47 days; DCV reuse reduced to 10 days	Every organization issuing public TLS certificates	Verify automation, monitoring, and alerting are production-tested well ahead of the deadline

Official Policy Sources and Effective Dates

Every deadline in this article traces back to a primary source rather than a secondary summary. Cite these directly when briefing internal stakeholders or auditors:

• CA/B Forum Ballot SC-081v3, via Sectigo, April 14, 2025: Confirms the phased schedule of 200 days by March 2026, 100 days by March 2027, and 47 days by March 2029, along with matching DCV reuse reductions. Source: Sectigo, April 14, 2025.
• DigiCert Trust Pulse Survey, July 2, 2025: Reports that 45% of enterprises experienced certificate-related downtime in the prior year, with 37.5% linking outages specifically to expired certificates. Source: DigiCert, July 2, 2025.

Why This Matters for Enterprise Certificate Lifecycle Management

Shorter certificate lifespans are, on balance, a net security improvement. A compromised private key on a 47-day certificate has far less time to cause damage than one on a 398-day certificate, and the more frequent renewal cycle forces organizations to keep their cryptographic practices current rather than set-and-forget. The trade-off is operational load. A certificate fleet that generates a manageable number of renewals per year at 398 days generates roughly eight times that volume once certificates last only 47 days.

DigiCert’s July 2025 Trust Pulse Survey puts a number on the risk this creates. Under today’s longer validity periods, 45% of enterprises reported certificate-related downtime in the past year, and 37.5% traced that downtime directly to expired certificates. Those figures reflect the current environment. As renewal cycles compress toward 47 days, the same manual processes that produce that failure rate today will be asked to run far more often, with far less room for error.

In our experience advising enterprise PKI teams, the organizations that struggle most with validity reductions are not the ones with the largest certificate fleets. They are the ones that treated their last certificate management upgrade as a one-time project instead of an ongoing operational capability. Certificate lifecycle management has to be built to absorb the next reduction, not just the current one.

Impact by Date and Role

Each milestone lands differently depending on which team owns which part of the certificate lifecycle. The table below maps what changes and who needs to act by when.

Role	What Changes	Action Needed	Target Date
PKI and Certificate Operations	Renewal volume roughly doubles at the 2026 milestone, then climbs sharply through 2027 and 2029	Deploy or expand an automated CLM platform covering every CA in use	Before March 2026
Security Teams	Shorter lifespans reduce the exposure window for a compromised private key but raise the stakes of any missed renewal	Update key protection and incident response runbooks for a higher renewal frequency	Before March 2027
Platform and DevOps Teams	Certificates embedded in CI/CD pipelines, load balancers, and containers need programmatic renewal instead of manual upload	Integrate ACME, SCEP, or EST directly into deployment pipelines	Before March 2027
Compliance Teams	Audit evidence has to reflect a faster-changing certificate inventory	Update compliance documentation and reporting cadence to match the new validity schedule	Ongoing, reviewed at each milestone

Readiness Checklist for PKI, Security, Platform, and Compliance Teams

Use this checklist to confirm each team is tracking the parts of the transition it owns.

PKI and Certificate Operations Teams

• Inventory first: Confirm you have a complete, current inventory of every public and private certificate in your environment, including ones issued outside central IT.
• Automate issuance: Enable ACME, SCEP, or EST for every certificate authority you use, not just your primary one.
• Test renewal at scale: Run a renewal cycle against your full production fleet before the 2026 milestone, not just a pilot group.

Security Teams

• Update runbooks: Revise incident response procedures to account for a higher renewal frequency and shorter key exposure windows.
• Review private key storage: Confirm private keys generated during more frequent renewals are still stored and rotated according to policy.
• Set alerting thresholds: Lower expiration alert windows so security teams are notified with enough lead time under a 47-day lifespan.

Platform and DevOps Teams

• Remove manual uploads: Identify every pipeline, load balancer, or container configuration that still requires manually uploading a certificate.
• Integrate with CI/CD: Wire certificate renewal directly into deployment automation so new certificates deploy without a change ticket.
• Cover cloud-native workloads: Extend automated renewal to containers and ephemeral cloud infrastructure, not just static servers.

Compliance Teams

• Map deadlines to controls: Tie each CA/B Forum milestone to the internal controls and audit evidence it affects.
• Automate evidence generation: Move certificate audit reporting away from manual spreadsheet assembly and toward on-demand reports from your CLM platform.
• Brief leadership early: Communicate the 2026 and 2027 milestones to leadership well ahead of time, since remediation budget requests take longer to approve than the runway between milestones allows if raised late.

Security Risks of Manual Certificate Management at Shorter Lifespans

A 398-day manual renewal process is inconvenient. A 47-day manual renewal process is a standing operational risk. The gap between the two grows wider at each milestone in the phased schedule.

Legacy Systems and Manual Renewal Workflows

Manual renewal processes that were merely tedious at a 398-day lifespan become untenable well before certificates reach 47 days. Legacy systems compound the problem in two specific ways: they typically lack support for automation protocols such as ACME, and their underlying infrastructure is often not built to absorb the increased renewal volume that shorter lifespans require.

Resource-Constrained IT Teams

Smaller IT teams face a disproportionate burden as validity periods shrink, since they typically have the least capacity to absorb a higher renewal frequency without automation. A team that can manually track a few hundred certificates renewing once a year struggles considerably more once those same certificates renew nearly eight times as often. Prioritizing automation early, even with a smaller initial scope, prevents that burden from becoming unmanageable at the 2027 and 2029 milestones.

How Automation Reduces Certificate Outage Risk

Automated certificate lifecycle management addresses the root cause behind most certificate-related outages: a human being was supposed to notice an expiration date and renew a certificate in time, and did not. Automation removes that single point of failure in three specific ways.

• Continuous discovery: Automated platforms scan the environment on an ongoing basis, so certificates issued outside a central process still show up in inventory rather than becoming invisible risk.
• Protocol-driven renewal: ACME, SCEP, and EST let certificates renew automatically at the infrastructure level, without waiting for a person to notice an expiration date.
• Centralized alerting: A single dashboard tracking every certificate across every CA replaces scattered spreadsheets and calendar reminders that inevitably fall out of date.

This is precisely the gap CertSecure Manager is built to close. It automates certificate discovery, issuance, and renewal across Microsoft, public, and private CAs from a single dashboard, so renewal frequency stops being a scaling problem for the IT team managing it.

Migration Roadmap: Short-Term and Long-Term Actions

The 2029 deadline for 47-day certificates is still years away, but building the automation to meet it takes real planning time. Treat the roadmap below as a sequence, not a single project.

Short-Term Actions (Next 6 Months)

• Evaluate CLM solutions: Assess platforms such as CertSecure Manager against your certificate volume, CA mix, and integration requirements.
• Audit existing automation: If some automation is already in place, confirm it actually covers your full certificate inventory rather than a subset.
• Adjust manual workflows: Begin migrating the highest-volume manual issuance paths to automated ones first, since they carry the most risk.

Long-Term Actions (6 to 36 Months)

• Build for scalability: Choose infrastructure that can absorb the 2027 and 2029 milestones without a second platform migration.
• Track ROI on automation: Measure the reduction in manual effort and outage incidents to justify continued investment as renewal volume grows.
• Design for what comes next: Build certificate management infrastructure with enough flexibility to absorb future CA/B Forum changes without another rebuild.

Multi-Cloud and Hybrid PKI Considerations

Organizations running certificates across multiple cloud providers and on-premises PKI face an added layer of complexity: each environment tends to develop its own certificate management habits by default. A migration roadmap for multi-cloud or hybrid PKI needs a single management layer that spans every CA and cloud account, rather than a separate manual process per environment. Without that consolidation, shadow certificates accumulate in whichever cloud account or subsidiary PKI hierarchy central IT has the least visibility into, which is exactly where an expired certificate is most likely to cause an unplanned outage.

Connection to the 47-Day Certificate Readiness Timeline

The 47-day maximum validity does not take effect until March 15, 2029, but the phased schedule exists specifically to force automation adoption well ahead of that date. Organizations that treat 2029 as the trigger to start planning will be attempting a compressed migration under a live 100-day renewal cadence, which is the exact scenario the phased rollout is designed to prevent. For a closer look at what full 47-day certificate readiness requires across an enterprise environment, including automation coverage targets and rollout sequencing, see Encryption Consulting’s dedicated readiness resource.

How Encryption Consulting Can Help

Encryption Consulting built CertSecure Manager specifically to handle the shift the CA/B Forum’s phased schedule is forcing on every enterprise: certificate renewal moving from an occasional task to a constant operational rhythm.

• Discovery across every CA: CertSecure Manager continuously discovers certificates across Microsoft, public, and private CAs, so nothing issued outside a central process stays invisible as renewal frequency climbs.
• Protocol-driven automation: Built-in support for ACME, SCEP, EST, and REST APIs lets certificates renew automatically at the infrastructure level, which is the only way to absorb an eightfold increase in renewal volume without adding headcount.
• One dashboard, every milestone: A single pane of glass tracks every certificate against the 2026, 2027, and 2029 deadlines, replacing the spreadsheets and calendar reminders that break down once renewal cycles shrink to weeks.
• Audit-ready reporting: On-demand compliance reports mean your evidence generation keeps pace with a faster-changing certificate inventory instead of falling behind it.

Request a demo to see how CertSecure Manager handles automated renewal at the volume a 47-day certificate lifespan requires.

Conclusion

The CA/B Forum’s phased reduction to 47-day TLS certificates is settled policy with three fixed dates: March 2026, March 2027, and March 2029. Each milestone multiplies renewal volume, and each one narrows the margin for manual error a bit further. The organizations that treat this as a multi-year automation program, rather than a deadline to react to in 2028, are the ones that will reach 47-day certificates without an outage along the way. Building that capability now, while the runway is still measured in years rather than months, is the difference between a planned migration and a compressed one.

Frequently Asked Questions

What is the main takeaway from the TLS certificate validity reduction to 47 days?

The CA/B Forum’s ratified ballot SC-081v3 phases maximum public TLS certificate validity down from 398 days to 200 days by March 15, 2026, 100 days by March 15, 2027, and 47 days by March 15, 2029. Organizations that still rely on manual issuance and renewal need to automate well before the 2027 milestone to avoid outages.

Why does this matter for enterprise certificate lifecycle management?

Shorter validity periods multiply the number of renewal events an enterprise handles each year. At a 47-day lifespan, a fleet of a few thousand certificates generates renewal volume that can overwhelm manual tracking. Automated certificate lifecycle management becomes a requirement rather than a convenience, since missed renewals translate directly into downtime and compliance gaps.

What teams are responsible for acting on this guidance?

PKI and certificate operations teams own discovery, automation tooling, and renewal workflows. Security teams own risk assessment and private key protection policy. Platform and DevOps teams own certificate integration into CI/CD pipelines, load balancers, and containers. Compliance teams own mapping the new validity schedule to audit evidence and regulatory reporting obligations.

What risks increase if this topic is handled manually?

Manual tracking cannot scale to the renewal frequency a 47-day lifespan requires. DigiCert’s July 2025 Trust Pulse Survey found that 45% of enterprises had already experienced certificate-related downtime, with 37.5% tracing outages directly to expired certificates, under today’s longer validity periods. That exposure grows as renewal cycles shrink from months to weeks.

How does automation reduce certificate outage risk?

Automated certificate lifecycle management continuously discovers certificates across CAs, tracks expiration in real time, and triggers renewal through protocols like ACME, SCEP, and EST without manual intervention. This removes the human error and tracking gaps behind most certificate-related outages and lets IT teams absorb higher renewal volume without added headcount.

What metrics should teams track after implementation?

Track certificate inventory completeness, mean time to renewal, the share of certificates renewed automatically versus manually, the count of expired or near-expiry certificates, and audit evidence generation time. These metrics show whether automation is actually closing the outage and compliance gaps that shorter validity periods create.

How does this connect to 47-day TLS certificate readiness?

The 47-day maximum validity takes effect March 15, 2029, but the phased schedule of 200 days in 2026 and 100 days in 2027 exists to force automation adoption well before that date. Organizations that wait until 2028 to automate will be attempting a compressed migration under a live 100-day renewal cadence, which the phased timeline is specifically designed to prevent.

How should this be handled in multi-cloud or hybrid PKI environments?

Multi-cloud and hybrid PKI environments need a certificate management layer that spans every CA, cloud provider, and on-premises issuance point from a single dashboard, rather than separate manual processes per environment. Centralized discovery and policy enforcement prevent shadow certificates from accumulating in cloud accounts or subsidiary PKI hierarchies that central IT lacks full visibility into.