From digital payments and healthcare data to SaaS logins and APIs, every secure online interaction and communication relies on Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates. So, in a bid to improve security hygiene and reduce exposure risk, the rules governing these SSL/TLS certificates have been tightening for over a decade. As of March 15, 2026, phase 1 of CA/Browser Forum Ballot SC-081v3 is in effect, reducing the maximum validity of publicly trusted TLS certificates from 398 days to 200 days. For security teams that have not yet invested in certificate lifecycle management automation, the operational consequences are already materializing.

This article traces the full history of certificate validity reductions, from multi-year lifespans to the current phased mandate, and emphasizes what the road to 47-day certificates requires of enterprise security programs today.

The History of Shrinking TLS Certificate Validity

The steady reduction of TLS certificate lifespans is a deliberate and sustained effort by browsers, certificate authorities, and the CA/Browser Forum to reduce the risk window associated with long-lived certificates. The historical progression is instructive:

• Before 2011: Maximum certificate validity was 96 months (8 years).
• 2012: Reduced to 60 months.
• 2015: Reduced to 39 months.
• 2018: Reduced to 27 months.
• 2020: Reduced to 398 days (approximately 13 months).

Each reduction was to improve the trustworthiness of certificate information. Domains change ownership, organizations evolve or dissolve, and validation data collected at issuance can become inaccurate long before a certificate expires. Shorter lifetimes force more frequent revalidation and reduce the window in which a compromised or mis-issued certificate can cause harm.

Google’s “Moving Forward, Together” and the 90-Day Proposal

In March 2023, Google’s Chromium project published a roadmap called “Moving Forward, Together,” which outlined its intention to further reduce maximum TLS certificate validity from 398 days to 90 days. The stated rationale covered three objectives: encouraging automation over manual issuance processes, promoting crypto agility to support faster algorithm transitions (including post-quantum migration), and reducing ecosystem dependence on revocation mechanisms that do not function reliably at web scale. Google indicated it could be achieved through either a Chrome Root Program policy update or a CA/Browser Forum ballot.

How the Industry Moved Beyond 90 Days

In late 2024, Apple stepped into the discussion and introduced a new CA/Browser Forum ballot that went further than Google’s original proposal. Rather than targeting 90 days as a single-step reduction, Apple’s proposal, which became Ballot SC-081v3, established a phased schedule of reductions, ultimately reaching a 47-day maximum validity by March 2029.

The decision to land on 47 days rather than 90 reflects several specific technical arguments. First, current revocation infrastructure does not work reliably. Certificate Revocation Lists grow unwieldy at scale, and OCSP-based revocation checking carries privacy implications and is not enforced by most browsers. Shorter certificate lifetimes reduce reliance on revocation by ensuring that compromised certificates expire before revocation propagation would have been effective in any case. Second, the phased structure was designed to give organizations a realistic runway to build automation capability before the most demanding renewal frequencies take effect.

The vote held on April 11, 2025 produced a result that was, by historical standards, remarkable. All four major browser vendors (Apple, Google, Mozilla, and Microsoft) voted in favor, 25 certificate issuers also voted yes, and zero votes were cast in opposition. Ultimately, Ballot SC-081v3 passed and the phased reduction schedule became the governing standard for publicly trusted TLS certificates.

The SC-081v3 Mandate: Phases, Timelines, and Scope

The phased reduction schedule established by Ballot SC-081v3 is as follows:

Several aspects of this schedule require careful attention:

• Phase 1 is already enforced. Any publicly trusted TLS certificate issued on or after March 15, 2026 has a maximum validity of 200 days. Organizations that have not yet adjusted their certificate management practices are already operating outside of best practice.
• The DCV reuse reduction is as significant as the validity reduction. Domain Control Validation (DCV) is the process by which a certificate authority confirms that the certificate requestor controls the domain in question. Under the current Phase 1 rules, domain validation data can be reused for up to 200 days. By Phase 3, that window drops to 10 days, meaning domain validation must occur with nearly every individual certificate issuance. This places automation requirements not just on certificate renewal workflows, but on the validation pipeline itself.
• Private PKI is not subject to this mandate. Ballot SC-081v3 governs only publicly trusted TLS certificates, those issued by certificate authorities included in browser root programs. Internal certificates issued by a private or enterprise certificate authority are not subject to CA/Browser Forum rules and may continue to carry longer validity periods. Organizations managing a mix of public and private PKI infrastructure need to account for this distinction in their CLM strategy.
• The connection to post-quantum cryptography is intentional. The SC-081v3 ballot explicitly frames shorter certificate lifetimes as a mechanism for improving crypto agility. Shorter-lived certificates are easier to replace when algorithm transitions are required, a directly relevant consideration as NIST’s post-quantum cryptographic standards (FIPS 203, 204, 205) move toward enterprise adoption and organizations prepare for the deprecation of RSA and ECDSA.

The Operational Reality: Certificate Volume at Scale

The operational consequences of the SC-081v3 phased schedule are proportional and concrete.

Consider an organization managing 1,000 publicly trusted TLS certificates.

• Under the 398-day model, approximately 1,000 renewal events per year are required.
• Under the 47-day model, more than 8,000 renewal events annually are required.

For organizations managing tens of thousands of certificates, which is not uncommon in financial services, healthcare, and telecommunications, the multiplication of renewal events represents a fundamental shift in operational workload.

Moreover, that workload does not scale with headcount. Certificate expiration events do not distribute evenly across the calendar, and each missed renewal leads to expired certificates that produce browser errors, break encrypted connections, disrupt API integrations, and generate compliance findings. The underlying problem is visibility. Organizations that do not have accurate, real-time inventory of their certificate estate cannot effectively manage renewal cycles at this frequency, regardless of team size.

Manual processes such as spreadsheet tracking, ticketing systems, and calendar reminders are already insufficient under Phase 1. By Phase 3, they will be operationally untenable.

Preparing for the 47-Day Era: Best Practices for Security Teams

Organizations that begin preparing now have the advantage of a phased runway. The following steps represent the foundational requirements for operating effectively in a 47-day certificate environment:

• Conduct a complete certificate discovery audit: Ensure that all publicly trusted certificates across cloud, on-premises, and hybrid environments are visible in a centralized inventory. Unknown certificates cannot be managed.
• Prioritize ACME protocol adoption: The Automated Certificate Management Environment (ACME) protocol is the industry standard for automated certificate issuance and renewal. Integrating ACME-compatible workflows across your infrastructure is the baseline requirement for Phase 3 readiness.
• Establish domain validation automation: Given the 10-day DCV reuse limit arriving in 2029, domain validation must be treated as an automated, continuous process, not a manual step in a renewal workflow.
• Separate private and public PKI management strategies: Internal certificates issued by a private CA can retain longer validity periods. Combining internal and public certificate management introduces unnecessary operational complexity and risk.
• Define certificate ownership and governance policies: At renewal frequencies exceeding eight times per year, accountability gaps in certificate ownership become critical failure points. Establish clear ownership, escalation paths, and SLAs for renewal failures.
• Integrate CLM into DevOps and infrastructure pipelines: Certificate provisioning and renewal should be embedded into CI/CD workflows, infrastructure-as-code practices, and cloud platform integrations.
• Begin evaluating crypto agility posture now: The path to 47-day certificates runs parallel to the path toward post-quantum readiness. Organizations that establish strong CLM automation infrastructure today are better positioned to execute algorithm transitions when they become mandatory.

Certificate Lifecycle Management Platforms and the Path Forward

The operational scale demanded by Ballot SC-081v3’s phased reduction schedule across discovery, automation, domain validation, multi-CA support, and policy enforcement cannot be addressed through point solutions or manual processes. This is where certificate lifecycle management platforms become essential infrastructure rather than optional tooling.

Leading CLM platforms including Keyfactor, AppViewX, CyberArk (Venafi), and DigiCert each provide capabilities across this requirement set: automated discovery, ACME-native renewal, multi-CA orchestration, and policy-driven governance. The appropriate platform for a given organization will depend on existing infrastructure, PKI maturity, cloud footprint, and integration requirements. So, vendor-agnostic evaluation, i.e., assessing each platform against organizational requirements rather than brand recognition, is the recommended approach.

Accutive Security operates as a Center of Excellence in Cryptography, Identity Security, and Data Protection, combining certified implementation expertise across these CLM platforms with vendor-agnostic advisory capability to help organizations select, deploy, and operationalize the right solution for their specific environment. As a certified services partner for Keyfactor, AppViewX, CyberArk (Venafi), and DigiCert, Accutive Security brings both the depth to evaluate options objectively and the technical capability to implement and manage what gets selected. That combination, advisory credibility backed by delivery expertise, is what distinguishes a Center of Excellence model from a traditional reseller engagement.

For organizations that have not yet selected a CLM platform, the Accutive Security Innovation Lab provides a practical starting point. It is a live, pre-built environment where security and infrastructure teams can evaluate CLM solutions through proof-of-concept testing and comparative platform assessment before committing to a procurement decision. It reduces procurement risk and accelerates the path from evaluation to production deployment.

Schedule a demo today to assess your certificate lifecycle management readiness and develop a roadmap for 47-day lifespans.