- Key Takeaways
- From the 90-Day Proposal to the 47-Day Certificate Mandate: A Timeline
- Why Shorter Certificate Lifespans Improve Security
- The Cost of Manual Certificate Management
- The Case for Automated Certificate Lifecycle Management
- Who Owns This: Action Matrix by Team
- Readiness Checklist and Migration Roadmap
- What Happens When Certificates Are Left Unmanaged
- How Encryption Consulting Can Help
- Metrics to Track After Implementation
- Conclusion
- Frequently Asked Questions
Quick answer: The CA/Browser Forum’s SC-081v3 ballot, passed on April 11, 2025, replaces the original 90-day certificate proposal with a phased reduction: a 200-day maximum TLS certificate validity from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. Automation, not manual renewal, is now required to keep pace with the new cadence.
SSL/TLS certificates are the mechanism your browser uses to confirm that the site you are connecting to is who it claims to be, not an imposter set up to steal credentials or payment details. When a certificate is valid, the padlock and the connection details behind it tell users their session is authenticated and encrypted. When it lapses, browsers throw hard warning pages, and expired certificates reliably drive users away from a site that no longer looks safe.
Two years ago, the certificate lifecycle conversation centered on one number: 90 days. Apple and Google both floated the idea of forcing TLS certificates down from the long-standing 398-day maximum to a 90-day cycle. That specific proposal never became the binding industry rule. Instead, the CA/Browser Forum passed a more gradual, and now official, ballot in April 2025 that phases certificate validity down to 47 days by 2029. If your team is still planning around a flat 90-day requirement, this guide brings you current.
What follows is the finalized timeline, who inside your organization needs to act and when, what happens when certificate management stays manual, and how a certificate lifecycle management (CLM) platform such as CertSecure Manager keeps renewals from becoming a fire drill every few months.
Key Takeaways
- The 90-day certificate proposal from 2023 was never adopted as the binding standard. The actual rule is CA/Browser Forum ballot SC-081v3, which phases maximum TLS certificate validity to 200 days on March 15, 2026, 100 days on March 15, 2027, and 47 days on March 15, 2029.
- By March 2029, every publicly trusted 47-day TLS certificates will need to be reissued roughly every six weeks, which makes manual renewal impractical for any organization running more than a handful of domains.
- DigiCert’s July 2025 Trust Pulse Survey found that 45% of organizations had certificate related downtime in the past year, and 37.5% of outages were caused specifically by expired certificates.
- PKI, security, platform, and compliance teams each own a different piece of this transition. None of them can treat it as someone else’s problem.
- Certificate lifecycle management automation, using a protocol such as ACME, is the practical way to meet a 47-day renewal cadence without increasing outage risk.
- Shorter certificate lifespans also support post-quantum cryptography readiness, since frequent reissuance forces much of the same infrastructure work that crypto agility requires.
From the 90-Day Proposal to the 47-Day Certificate Mandate: A Timeline
The validity period of SSL/TLS certificates has shrunk steadily for two decades, driven by the evolution of cybersecurity threats and the ongoing push for stronger web security.
In the early internet, certificates carried lifetimes as long as ten years, and obtaining one could require direct contact with a certificate authority’s validation team. As internet practices matured, the CA/Browser Forum formed to standardize certificate practices, and one of its recurring efforts has been reducing the maximum validity period. By 2016 the cap was 3 years, and by 2018 it dropped to 2 years (730 days).
In 2019, Apple proposed cutting validity to 1 year (398 days) at the CA/Browser Forum. The Forum did not pass that ballot, but Apple enforced 398-day validity unilaterally in Safari during 2020, and the rest of the industry effectively followed. In 2023, Google raised the idea of pushing validity down further, to 90 days, as a future direction for the Chrome root program. That 90-day figure is where much of the industry conversation, including earlier versions of this guide, got stuck.
The industry did not settle on 90 days. In January 2025, Sectigo endorsed a ballot proposing a phased reduction to 47 days, and on April 11, 2025, the CA/Browser Forum passed that ballot as SC-081v3. It replaces the flat 90-day idea with three scheduled steps between now and 2029.
Official Policy Timeline and Sources
| Effective Date | Requirement | Who Is Impacted | Action Needed | Source |
|---|---|---|---|---|
| March 15, 2026 | Maximum TLS certificate validity drops to 200 days. The Domain Control Validation (DCV) reuse period also drops to 200 days. | Every publicly trusted TLS/SSL certificate and the teams that issue and renew them | Move to a roughly six-month renewal cadence; confirm your CA and CLM tooling issue certificates within the new window | CA/Browser Forum Ballot SC-081v3, via Sectigo |
| March 15, 2027 | Maximum validity drops to 100 days. DCV reuse also drops to 100 days. | Same certificates and teams, plus any workflow still relying on manual CSR generation | Finish automating issuance and renewal; retire manual certificate request processes | CA/Browser Forum Ballot SC-081v3, via Sectigo |
| March 15, 2029 | Maximum validity drops to 47 days. DCV reuse drops to 10 days. | All publicly trusted TLS certificates industry-wide | Have full CLM automation in place, including discovery, alerting, and revocation workflows | CA/Browser Forum Ballot SC-081v3, via Sectigo |
Both dates above come from a primary source: the CA/Browser Forum ballot SC-081v3, originally proposed by Apple and passed on April 11, 2025. A second primary source, DigiCert’s Trust Pulse Survey published July 2, 2025, quantifies the operational risk of managing this schedule manually. Treat any resource, including older versions of this guide, that cites a flat 90-day requirement as outdated.
Why Shorter Certificate Lifespans Improve Security
There is no single scientifically ideal validity period, but the direction of travel is consistent: shorter lifespans reduce the window of exposure if a certificate or its private key is compromised, and they force more frequent adoption of stronger cryptography.
-
Reduced damage from key compromise:
A shorter validity period limits how long a stolen private key stays useful to an attacker. If a key tied to a 47-day certificate is compromised, the exposure window closes in weeks instead of the thirteen months a legacy 398-day certificate allowed. That shorter window also gives a compromised organization a faster path to revoke the affected certificate and issue a clean one.
-
Faster adoption of stronger cryptography:
Shorter validity periods force more frequent key generation and certificate reissuance. That cadence makes it easier for organizations to fold in new cryptographic algorithms as they become available, rather than waiting a full year or more for the next scheduled renewal. This same discipline is what makes an organization’s PQC readiness more tractable once quantum-resistant algorithms are mandatory.
The Cost of Manual Certificate Management
As the renewal cadence shrinks from once a year to once every six to seven weeks, the margin for human error shrinks with it. DigiCert’s July 2025 Trust Pulse Survey, based on responses from enterprise security leaders, puts a number on that risk.
- 45% of organizations reported service downtime caused by certificate related incidents in the past year.
- 37.5% of those outages were attributed specifically to certificates that had already expired, one of the most preventable causes of downtime in enterprise environments.
- 31% of organizations reported losses between $50,000 and $250,000 tied to certificate issues, and 18.5% reported losses above $250,000.
- 80% of respondents expect their certificate volume to keep growing over the next 12 months, while 56.6% said they are already concerned about their ability to track expiration dates.
Those numbers describe certificate management under today’s longer validity periods. As the maximum drops to 200, then 100, then 47 days, the same manual processes will be asked to run two to eight times more often, with far less room for a missed renewal to go unnoticed.
The Case for Automated Certificate Lifecycle Management
The same DigiCert survey found that 51% of organizations named automated certificate lifecycle management a top strategic priority for the year ahead, which lines up with what the 47-day timeline requires. Manual practices that were merely inconvenient at a 398-day cadence become a genuine operational risk at 47 days.
A CLM platform such as CertSecure Manager delivers the certificate automation needed to remove human error from the equation by discovering every certificate across your environment, tracking expiry automatically, and triggering revocation and reissuance through a protocol such as ACME before a certificate ever lapses. Centralizing that work also frees IT staff to focus on higher-value security initiatives instead of tracking spreadsheets and calendar reminders.
Who Owns This: Action Matrix by Team
The shift to 47-day certificates touches more than one team, and each one has a different job to do before March 2026.
| Team | What Changes for Them | Immediate Action |
|---|---|---|
| PKI Team | Certificate templates, CA integrations, and issuance workflows must support 47-day reissuance without manual CSR generation | Update CA and RA templates now, and confirm ACME support with your issuing CA well before the March 2026 deadline |
| Security Team | A shorter compromise window improves posture, but a missed renewal now creates an outage risk every six to seven weeks instead of once a year | Add certificate expiry to existing risk and vulnerability dashboards; treat an expired certificate as a monitored risk, not a routine IT ticket |
| Platform and DevOps Team | Every service, load balancer, and API gateway needs an automated renewal path; manual certificate installs will not scale to a 47-day cycle | Integrate certificate issuance into CI/CD pipelines through ACME or a CLM platform’s API |
| Compliance Team | Audit evidence for certificate lifecycle controls, including under frameworks such as DORA and PCI DSS, must reflect a continuously renewed and monitored inventory | Confirm that the inventory and renewal logs your CLM platform produces satisfy your specific compliance framework’s evidence requirements |
What to Do Next, by Team
- PKI team: update certificate templates and confirm ACME support with your issuing CA before March 2026.
- Security team: add certificate expiry to existing risk and vulnerability dashboards this quarter.
- Platform and DevOps team: wire certificate issuance into CI/CD pipelines through ACME or a CLM platform API.
- Compliance team: confirm renewal and inventory logs already satisfy your audit evidence requirements under frameworks such as DORA and PCI DSS.
Readiness Checklist and Migration Roadmap
A certificate lifecycle management platform gives you the tools to automate certificate workflows, but getting the most out of it depends on following a sequence rather than turning on automation everywhere at once.
-
Find:
Start by discovering and inventorying every TLS/SSL certificate across the organization. Run automated discovery tools across the network to locate every certificate in use, then store that inventory in a central certificate management system as the single source of truth. A hospital network, for example, might need this kind of scan to uncover certificates securing both public patient portals and internal electronic health record systems.
-
Policy:
Set a policy that treats a shortening lifecycle as the default rather than an exception, and define who owns requesting, approving, and rotating certificates. The policy should also define an exception process, with documented justification and sign off, for cases such as a legacy application that cannot yet support automated renewal.
-
Provision:
Automate issuance wherever possible and integrate it with your certificate authority through a protocol such as ACME. Reducing the chance of an expired certificate, streamlining deployment, and keeping the same practice consistent across every system frees IT resources for more strategic work.
-
Monitor:
Build continuous monitoring with real-time alerts for impending expiration, revocation, or misconfiguration. A dashboard that gives an organization-wide view of certificate health lets administrators catch and resolve problems before they affect production traffic.
-
Control:
Restrict which systems and people can request, issue, or manage certificates, using role-based access control to separate the duties of requesting, approving, and issuing. Review these controls whenever the organizational structure or security policy changes, and audit the process regularly.
-
Report:
Generate regular reports covering certificate name, issuer, issue date, expiry date, days remaining, and domain. A current report is what lets a team confirm that no certificate is quietly heading toward expiration unnoticed.
Multi-Cloud and Hybrid PKI Environments
Most enterprises now run certificates across more than one cloud provider alongside an on-premises certificate authority, which means a 47-day renewal cycle cannot rely on each platform’s native, siloed certificate tools. A hybrid PKI environment needs one CLM platform that can discover and renew certificates across AWS, Azure, Google Cloud, and on-premises infrastructure from a single point of control. Without that centralized visibility, a short renewal cycle spread across fragmented environments multiplies the odds that a certificate in a less visible corner of the estate gets missed.
What Happens When Certificates Are Left Unmanaged
SSL/TLS certificates protect website integrity and secure the transmission of information. When a certificate expires unnoticed, especially under a 47-day cycle where there is far less buffer than there used to be, the consequences go well beyond an inconvenient warning page.
In 2017, Equifax suffered a data breach that exposed the personal information of roughly 148 million Americans. A network monitoring device relied on a certificate that had expired about 19 months earlier and gone unnoticed, which left encrypted traffic on that segment of the network uninspected. Once attackers gained a foothold, they exfiltrated data for 76 days before the expired certificate was finally renewed and the suspicious activity was detected.
-
Data breaches:
A valid SSL/TLS certificate protects sensitive data such as login credentials, payment details, and personal information as it moves between a user and a server. When that certificate expires or its integrity fails, the encrypted tunnel collapses and creates an opening for an attacker to intercept that data in transit.
-
Reputation damage:
An expired certificate signals to users that basic security hygiene was overlooked. That kind of visible lapse is difficult to walk back and can undercut trust that took years to build.
-
Search engine penalties:
Search engines reward sites that maintain valid SSL/TLS certificates and flag those that do not. A site marked unsafe because of an expired certificate can see its rankings drop, which reduces visibility and traffic.
-
Service interruption:
Browsers detect an expired certificate and block access with a warning page. For an e-commerce business, that is lost sales during the outage. For every other visitor, it is a broken experience that erodes confidence in the site.
How Encryption Consulting Can Help
Managing a handful of certificates with spreadsheets and calendar alerts was never elegant, but it was survivable. Managing hundreds of certificates across multiple applications and subdomains on a 47-day cycle is a different problem, and it is the one CertSecure Manager is built to solve.
-
Automated renewal:
CertSecure Manager automates the full renewal process, from generating the request to ordering it from the CA and installing the renewed certificate on the target system. That removes the manual work that becomes unsustainable once renewals happen every six to seven weeks instead of once a year, and it supports automated replacement across common platforms such as IIS, Apache, Tomcat, and F5 load balancers.
-
Discovery and inventory management:
A full scan of your IT infrastructure removes blind spots that let renewals slip through unnoticed. A single, centralized view of every certificate’s status, validity dates, and ownership supports better decisions about where to prioritize automation first.
-
Alerts and reporting:
Rather than waiting for a certificate to expire, CertSecure Manager generates proactive alerts ahead of renewal windows and produces detailed health reports covering upcoming renewals and potential risk areas, which is especially useful once every certificate is on a 47-day clock.
-
Integration with DevOps:
CertSecure Manager works with popular certificate authorities and automation frameworks, and integrates into existing deployment pipelines. That reduces the manual effort needed to move certificate data between systems and supports automated provisioning as new environments come online.
Certificate renewal automation is only part of the picture. Encryption Consulting’s CBOM Secure discovers every cryptographic asset across your environment, not just TLS certificates, and our guide on how a CBOM turns inventory into intelligence explains how that discovery work feeds directly into post-quantum migration planning through our PQC Center of Excellence.
Metrics to Track After Implementation
Rolling out automation is not the finish line. These are the metrics worth reviewing on a regular cadence once a CLM platform is in place.
- Renewal success rate across the full certificate inventory
- Number of certificates approaching expiry without an active renewal job attached
- Mean time to reissue a certificate after a revocation event
- Percentage of the certificate inventory under automated management versus manual tracking
- Number of outages attributable to certificate expiry, which should trend toward zero
- Time required to generate compliance evidence for an audit request
Conclusion
The 90-day certificate proposal that once dominated this conversation was never adopted. What is actually binding is the CA/Browser Forum’s phased schedule: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029. That timeline is not a distant hypothetical; the first deadline is less than a year away.
Meeting it comfortably means adopting automation now rather than waiting for the deadline to force the issue. A CLM solution such as CertSecure Manager handles discovery, issuance, renewal, and revocation across your full certificate inventory, which turns a shrinking validity window from a recurring emergency into a routine background process.
Shortening certificate lifespans requires real planning, but the payoff, stronger security, cleaner compliance evidence, and a certificate infrastructure that already has current certificate discovery in place, outweighs the short-term effort of getting there.
Frequently Asked Questions
What is the main takeaway from Your Guide for the 90 Day Digital Certificate Shift?
The original 90-day certificate proposal was never adopted. The CA/Browser Forum’s binding SC-081v3 ballot instead phases maximum TLS certificate validity down to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029. Organizations still planning around a flat 90-day cycle need to update their roadmap to this phased, shorter timeline and move to automated certificate lifecycle management well before the first deadline.
Why does this matter for enterprise certificate lifecycle management?
At a 47-day renewal cadence, every publicly trusted certificate needs reissuing roughly eight times a year instead of once. Manual tracking through spreadsheets or calendar reminders cannot keep pace with that frequency across hundreds or thousands of certificates, which is why DigiCert’s 2025 survey found that nearly half of enterprises already experience certificate related downtime under today’s much longer validity periods.
What teams are responsible for acting on this guidance?
PKI teams need to update certificate templates and CA integrations to support shorter validity and ACME-based issuance. Security teams need to fold certificate expiry into existing risk monitoring. Platform and DevOps teams need to automate certificate renewal inside deployment pipelines. Compliance teams need to confirm that renewal and inventory logs satisfy audit requirements under frameworks such as DORA and PCI DSS.
What risks increase if this topic is handled manually?
Manual certificate management increases the odds that a missed renewal turns into an outage, since a 47-day cycle leaves far less room for human error than an annual one did. It also raises the chance of duplicate or orphaned certificates going untracked, expired certificates slipping past a routine spreadsheet review, and compliance evidence being incomplete when an auditor asks for it.
How does automation reduce certificate outage risk?
A certificate lifecycle management platform discovers every certificate across your environment, tracks its expiry automatically, and triggers renewal through a protocol such as ACME before the certificate lapses, without waiting on a person to notice a calendar reminder. That closes the specific gap DigiCert’s survey identified, where 37.5% of certificate related outages were caused by certificates that had simply expired.
What metrics should teams track after implementation?
Track renewal success rate, the number of certificates approaching expiry without an active renewal job, mean time to reissue after a revocation event, the percentage of your certificate inventory under automated management versus manual tracking, and the number of outages caused by certificate expiry, which should trend toward zero once automation is in place.
How does this connect to 47-day TLS certificate readiness?
The 47-day deadline in March 2029 is the final phase of the same CA/Browser Forum timeline covered in this guide. The 200-day and 100-day milestones in 2026 and 2027 exist specifically to give organizations a gradual path to full 47-day readiness, so the automation and discovery work done now directly prepares your certificate infrastructure for the final phase.
How should this be handled in multi-cloud or hybrid PKI environments?
Multi-cloud and hybrid PKI environments need a certificate lifecycle management platform that can discover and renew certificates across every cloud provider, on-premises certificate authority, and load balancer from one place, rather than relying on each cloud’s native, siloed certificate tools. Without centralized visibility, a 47-day renewal cycle across fragmented environments multiplies the chance that something gets missed.
- Key Takeaways
- From the 90-Day Proposal to the 47-Day Certificate Mandate: A Timeline
- Why Shorter Certificate Lifespans Improve Security
- The Cost of Manual Certificate Management
- The Case for Automated Certificate Lifecycle Management
- Who Owns This: Action Matrix by Team
- Readiness Checklist and Migration Roadmap
- What Happens When Certificates Are Left Unmanaged
- How Encryption Consulting Can Help
- Metrics to Track After Implementation
- Conclusion
- Frequently Asked Questions
