CA/Browser Forum (the forum of browsers and certification authorities) officially voted to radically shorten the maximum validity period of public SSL/TLS certificates to just 47 days. This decision represents a worldwide policy change for all major certificate providers—from commercial CAs such as DigiCert, Sectigo, Entrust, and GlobalSign, to non-profit organizations like Let’s Encrypt. The initiative to shorten certificate lifetimes was launched by Apple and supported by other browser vendors (Google Chrome, Mozilla) as well as by certificate issuers themselves (including Sectigo). The vote, concluded on April 11, 2025, adopted this proposal, ushering in a new chapter in Internet trust management. Over the next few years, the maximum certificate lifetime will be gradually reduced to reach the target of 47 days by March 2029. In this article, we discuss the reasons for this change, its scope, and its impact on IT infrastructure, DevOps practices, enterprise certificate management, and end-user experience. We also present the challenges and opportunities of the era of ultra-short-lived certificates.
Table of Contents
ToggleThe move to a maximum 47-day validity caps a years-long trend of shortening TLS certificate lifespans. A decade ago, certificates commonly lasted up to 5 years, then were reduced to 3 years, then 2 years, and finally to about 13 months (398 days). The watershed moment came in 2020 when Apple unilaterally enforced a 398-day maximum for public certificates in its ecosystem. Following that, the industry began exploring even shorter periods—early in 2022 S/MIME certificate validity was reduced, and in March 2023 Google introduced the “Moving Forward, Together” initiative proposing 90-day certificates. The argument was that “more timely domain validation better protects domain owners by reducing the risk of relying on stale or invalid information that could lead to mistaken certificate issuance.”
After a year of debate on the CA/Browser Forum, Apple went further by formally proposing a staged reduction down to 47 days. In April 2025, Apple’s proposal gained support from both browser vendors and the largest CAs (including Google, Mozilla, and Sectigo). Notably, Google—initially a proponent of a 90-day limit—immediately backed Apple’s 47-day proposal during the vote. With the regulation adopted, automation of certificate lifecycle management becomes mandatory (as emphasized in the proposal: “by progressively shortening validity periods, the Forum has signaled that automation is essentially required for effective certificate lifecycle management”). Below is the implementation schedule:
TLS Certificate Maximum Validity Reduction Schedule (as adopted by the CA/Browser Forum):
These changes apply to all publicly trusted SSL/TLS certificates used by websites. At the same time, the allowable reuse period for domain validation results by CAs will be shortened—from the current 398 days to 10 days by 2029. This means CAs must re-validate domain control far more frequently (even if renewal is automated). For OV/EV certificates, the validity period for verified organization information (Subject Identity Information) will also be reduced from 825 days to 398 days—requiring annual re-validation of the organization. In summary, by 2029 both certificates and the information used to issue them will be refreshed almost monthly.
The primary rationale for drastically shortening certificate lifespans is to enhance security and the integrity of the certificate-based trust model. The longer a certificate remains valid, the higher the risk its embedded information becomes outdated or less reliable. An SSL/TLS certificate enables the browser to verify a server’s identity—and in a year, companies may dissolve or merge, domains can change hands, and contact details can become obsolete. As Apple noted, “information in certificates becomes increasingly untrustworthy over time,” which can only be addressed by more frequent re-authentication. Shorter validity forces more frequent renewals, ensuring that domain control and organizational data (for OV/EV) remain current.
A second key aspect is limiting the impact of key compromise or issuance errors. If a private key is stolen or a certificate mistakenly issued to an unauthorized party, a short lifespan dramatically limits the window for abuse. With a 47-day validity, a compromised certificate will soon expire on its own even without formal revocation. This is critical because certificate revocation mechanisms (CRL/OCSP) can be unreliable—browsers often ignore revocation status due to delays or errors. In practice, even a revoked certificate may be accepted until it expires. Shorter lifespans mitigate this issue: a problematic certificate quickly becomes invalid, regardless of CRL/OCSP. Indeed, in 2023 the CA/B Forum approved ≤7-day short-lived certificates that require no CRL/OCSP handling—their brevity alone suffices as protection. In short, shorter certificates reduce exposure to attacks following compromise and elevate overall web security.
Another fundamental driver is the imperative to automate certificate issuance and renewal. Manual management, feasible with annual or biennial renewals, becomes untenable when renewals occur every few weeks. The CA/Browser Forum has long signaled—through successive validity reductions—that the industry *must transition to automated lifecycle management. Apple explicitly stated that without automation, organizations cannot cope with such short cycles. Even at 100-day certificates (effective 2027), manual processes will collapse, risking widespread service outages. In short, automation shifts from “nice to have” to absolute necessity for infrastructure continuity.
Pressure from industry leaders accelerated this shift. Apple and Google publicly endorsed shorter certificates for their security and reliability benefits. Google signaled a 90-day plan in 2023, and Apple proposed an even shorter period—critically securing support from other browser vendors (Google, Mozilla) and major CAs (e.g., Sectigo). The result is a consensus: full automation plus shorter certificates is the right path, cementing the change’s adoption. Furthermore, shorter lifespans foster rapid response to emerging threats—e.g., post-quantum cryptography—allowing more frequent algorithm transitions if current ones are weakened.
Such a dramatic shortening of certificate validity will be felt in day-to-day IT operations. Administrators will need to install and deploy new certificates far more often across servers, devices, and services. Instead of an annual cycle, certificates renewed every 47 days require about 7–8 renewals per year (with renewals typically occurring a few days early). This represents over an eight-fold increase in certificate-management operations compared to today. Moving to a 90-day cycle already implied renewing every ~60 days (4–6 times per year), whereas a 47-day cycle demands renewals every ~40–45 days. As a result, infrastructure and web-service teams must gear up for continuous certificate management, substantially raising their operational load. Without robust automation integrated into routine tasks, the risk of errors and outages—such as missing a renewal deadline and letting a certificate expire—escalates.
To meet these challenges, IT infrastructure must be backed by tools and processes for automatic certificate renewal and distribution. Web servers and network devices should support mechanisms that automatically import and activate new certificates and private keys without downtime. Many modern servers (e.g., Nginx, Apache, application servers) allow in-flight certificate reloads—but orchestration is key: every few weeks, the system must fetch a new certificate from the CA and update it everywhere. In containerized environments and with orchestrators (like Kubernetes), operators or controllers (e.g., cert-manager) integrate with ACME to automatically obtain and apply certificates. Organizations still relying on manual uploads during periodic maintenance windows will need to overhaul their practices. The frequency of changes (every few weeks) mandates a “zero-downtime” approach—renewals occur seamlessly in the background before expiration, invisible to users.
DevOps and CI/CD (Continuous Integration/Continuous Delivery) workflows will also adapt to the faster certificate lifecycle. Many organizations will incorporate certificate management as a regular CI/CD pipeline step. For example, during automated deployments of new application or infrastructure versions, the pipeline can call a CA’s API (e.g., via the ACME protocol) to obtain or update certificates for services being deployed. Infrastructure as Code should include certificate definitions, and configuration management systems must ensure automatic renewal and distribution before expiration. DevOps teams will need to tightly integrate certificate tools with existing automation platforms (orchestration tools, CI systems, cloud solutions).
Another aspect is pipeline monitoring and testing. With such frequent renewals, monitoring must automatically track expiry dates for all certificates in the environment and alert on renewal failures. Best practices will include regular renewal tests (e.g., in staging) and canary deployments of new certificates—ensuring before production rollout that all system components accept the updated certificate. CI/CD processes may also incorporate security checks to verify no components use expired certificates.
Overall, this change aligns with the broader “Everything as Code” trend in DevOps—certificates become dynamic, regularly renewed assets managed automatically like code or configuration. Organizations that adopted automated renewal early will gain an advantage. For others, this may spur pipeline modernization. The ACME standard grows in importance as the universal interface for automated certificate handling—many DevOps tools already support or are adding ACME integration to streamline certificate renewal within continuous delivery cycles.
In enterprises with hundreds or thousands of certificates, adopting a 47-day cycle will be particularly impactful. Traditional practices—where each business unit orders certificates manually and IT teams install them annually—simply won’t scale for monthly renewals. Large organizations must invest in centralized certificate lifecycle management (CLM) systems that track every certificate, renew them automatically before expiration, and distribute them to the necessary systems. Many enterprises will turn to platforms like Venafi, DigiCert CertCentral, DigiCert One, Sectigo CLM, GlobalSign Atlas, or deploy open-source tools integrated with their infrastructure (e.g., ACME-based scripts). Having a complete inventory of certificates and alert mechanisms is crucial to prevent any—from seldom-updated systems—from expiring unnoticed.
Process standardization around certificates will become even more critical. Many corporations already enforce a “no unmanaged certificates” policy—this change will expand such mandates. Renewal automation must cover both public-facing and internal certificates (even though internal ones aren’t governed by CA/B Forum rules, the automation trend still applies). Large enterprises may also increase use of wildcard or multi-domain certificates to reduce the total count of certificates to manage—while not changing renewal frequency, this simplifies operations by securing multiple services with a single certificate.
Importantly, shorter certificate validity should not significantly increase financial costs for enterprises. Most CAs have long since adopted subscription models (e.g., annual or multi-year), allowing unlimited renewals within the paid period. Thus, instead of paying per certificate issuance (which would skyrocket with an eightfold renewal increase), organizations purchase a yearly subscription and simply renew more often. CAs assert that transitioning to 100-day or shorter certificates will not raise fees—annual pricing remains unchanged, with multiple renewals included. Of course, companies must invest in automation and integration systems (incurring software, deployment, and training costs), but in the long run, automation yields fewer outages and incidents, avoiding much higher hidden costs.
For the average Internet user, this change will be nearly imperceptible—provided service providers adapt correctly. Shorter certificate validity does not alter the encrypted connection process: browsers will still display a TLS lock icon, and encryption functions as before. Users might notice that certificate expiration dates (visible via the lock icon’s details pane) are closer to the current date, but this is purely informational.
If all goes as planned, end users will enjoy indirect benefits from enhanced security—there will be less chance of encountering certificates that, although unexpired, have been compromised or contain stale information. Shorter lifecycles force administrators to eliminate certificate-management neglect, leading to fewer outages due to expired certificates. High-profile incidents where major services went offline because of missed renewal deadlines should become a thing of the past with widespread automation. From the user’s perspective, online services will be more reliable and resilient against a class of operational errors (forgotten renewals).
There is, however, a transitional risk—if some providers fail to implement automation in time, users may temporarily see more untrusted or expired-certificate warnings. Yet browser enforcement (potentially blocking over-aged certificates) and fear of losing customers will drive serious operators to comply. Ultimately, the change unfolds behind the scenes—users will primarily notice safer, more stable connections.
This major shift in the TLS ecosystem brings operational challenges and measurable impacts. First, there will be a dramatic increase in certificate issuance/renewal requests handled by CAs. Instead of annual renewals, site owners will renew ≈8 times per year, implying an up to eightfold surge in global CA transactions. Today, an estimated 60–70% of certificates already have ≤90-day lifespans—driven by the popularity of automated services like Let’s Encrypt. Nevertheless, a 47-day limit means every certificate (including those previously annual) becomes short-lived, so renewal cycles multiply worldwide. We can expect annual public TLS certificate issuance to climb into the hundreds of millions or even billions. For context, Let’s Encrypt already issues hundreds of millions yearly, showing the infrastructure can scale. Commercial CAs, however, must optimize systems to handle an avalanche of API/ACME requests without user interaction.
The increased renewal traffic may impact CA network and service load. ACME is relatively lightweight (a typical request includes submission, domain validation, and certificate download), but at global scale, even tens of kilobytes per request times hundreds of millions of operations poses a challenge. Maintaining high availability is critical—any CA outage risks numerous renewals failing and certificates expiring. Providers will invest in redundancy and scalability to guarantee near-100% uptime. We may see “failover ACME” solutions, where tools automatically renew with a secondary CA if the primary is unreachable—though this raises trust and compliance issues and will be nontrivial to implement.
Another consideration is the growth of public Certificate Transparency (CT) logs—every new certificate must be logged, so CT logs will grow faster. Fortunately, CT was designed for large scale, and shorter lifecycles have long been anticipated, so log operators should be prepared.
In summary, operational challenges include an explosive increase in transaction volume, the need for robust automation, and maintaining high-performance CA infrastructure. However, most major CAs have already prepared—implementing automated APIs and protocols, and many enterprises began adapting before the requirement became official. Those yet to act must urgently catch up, as there is no more time for manual certificate management.
Despite initial hurdles, shortening maximum certificate validity to 47 days will yield significant benefits for the industry and users. Key advantages include:
Shortening maximum SSL/TLS certificate validity to 47 days is an unprecedented change heralding a new era in public-key infrastructure management. The motivations—enhanced security, removal of error-prone human elements, and accelerated innovation—are clear and reflected in unanimous support from browsers and CAs. For administrators and IT teams, the coming years will demand intensive preparation: process automation, tooling updates, and staff training. Those already using ACME or other automated systems will transition smoothly; others must quickly catch up to avoid service disruptions. Ultimately, all ecosystem participants—from large enterprises to small-site owners—will reap long-term benefits. The Internet will be more secure thanks to fresher, more frequently verified certificates, and incidents caused by expired or outdated certificate data will become rare. Short-lived certificates also catalyze further automation and innovation in identity and security management. Thus, the decision to shorten validity to 47 days, though demanding, aligns with the broader trend of simplifying, automating, and strengthening trust in digital infrastructure. It is a significant step forward that will make the web more reliable for everyone.
Have questions about automating the SSL lifecycle? Contact our sales team.