TLS Certificate Validity Timeline: From 398 Days to 47 Days by 2029

Quick answer: Public TLS certificate validity is shrinking from 398 days to 47 days under CA/Browser Forum Ballot SC-081v3. The reduction is phased: 200 days by March 2026, 100 days by March 2027, and 47 days by March 2029. Google’s earlier 90-day proposal was not the rule that passed. Organizations must automate issuance and renewal to keep pace.

Back in 2023, Google proposed cutting TLS certificate validity from 398 days to a flat 90 days at the CA/Browser (CA/B) Forum. That specific number never became policy. What did pass, in April 2025, is a phased schedule that lands on 47 days by 2029, proposed by Apple and endorsed by Sectigo and the wider CA/B Forum membership. The destination is even shorter than Google originally asked for. The path to get there just looks different than the industry expected two years ago.

If your certificate management process still assumes annual renewals, or if your team is still planning around a 90-day number, this is the moment to correct course. Below is what actually changed, why it matters for enterprise certificate lifecycle management, and what each team inside your organization needs to do before the first deadline hits in March 2026.

Key Takeaways

• The 90-day proposal did not pass: the CA/B Forum adopted a phased reduction to 47 days by 2029 instead, under Ballot SC-081v3.
• Three hard deadlines are already on the calendar: 200 days by March 15, 2026, 100 days by March 15, 2027, and 47 days by March 15, 2029.
• Manual certificate management will not survive this transition: nearly half of enterprises already report certificate related downtime today, before validity periods even shorten.
• Four teams need to act: PKI, security, platform and infrastructure, and compliance each own a different piece of readiness.
• Automation is no longer optional: a 47-day renewal cycle is not operationally realistic without ACME or an equivalent automated certificate lifecycle management platform.

From Google’s 90 Day Proposal to the CA/Browser Forum’s 47 Day Rule

Certificate lifespans have been shrinking for a decade. In 2017, the industry capped TLS certificate validity at 825 days. That dropped to 398 days in 2020, driven by the same logic each time: a compromised certificate is dangerous for as long as it remains valid, and shorter lifespans force faster adoption of current encryption standards.

In July 2023, Google published Moving Forward, Together, a proposal to cut maximum validity to 90 days. The stated goals were to shrink the window attackers have to exploit a stolen certificate, push the ecosystem toward automated renewal, and prepare the web for a faster transition to post quantum cryptography.

The 90-day number itself did not survive the CA/B Forum ballot process. Apple proposed an alternative schedule that reaches a shorter endpoint, 47 days, through three intermediate steps rather than one abrupt cut. Sectigo endorsed the plan in January 2025, and the ballot, designated SC-081v3, passed in April 2025 with broad support from certificate authorities and browser vendors. The practical result is that every organization operating public TLS certificates is now working against a fixed, multi year countdown rather than a single deadline.

Any internal documentation, runbooks, or vendor conversations that still reference a flat 90-day requirement are working from an outdated premise. The real schedule is longer to reach 47 days, but it starts sooner, with the first cut arriving in March 2026.

TLS Certificate Validity Timeline: What Changes and When

The table below lays out each deadline under CA/B Forum Ballot SC-081v3, who it affects, and what action it requires. Every date and figure is sourced directly from the ballot’s public announcement.

Effective Date	Requirement	Who Is Impacted	Action Needed	Source
Today	Maximum validity: 398 days	All organizations issuing public TLS certificates	Confirm your current renewal cadence and certificate inventory before the first cut arrives	CA/Browser Forum Baseline Requirements
March 15, 2026	Maximum validity drops to 200 days; domain control validation (DCV) reuse drops to 200 days	Every publicly trusted TLS certificate issued after this date	Move to a roughly six month renewal cadence; confirm ACME, EST, or SCEP support with your issuing CA	CA/Browser Forum Ballot SC-081v3, endorsed by Sectigo, April 14, 2025
March 15, 2027	Maximum validity drops to 100 days; DCV reuse drops to 100 days	Every publicly trusted TLS certificate issued after this date	Move to a roughly three month renewal cadence; automation stops being optional for any team managing more than a handful of certificates	CA/Browser Forum Ballot SC-081v3, endorsed by Sectigo, April 14, 2025
March 15, 2029	Maximum validity drops to 47 days; DCV reuse drops to 10 days	Every publicly trusted TLS certificate issued after this date	Full end-to-end automation across issuance, deployment, and renewal; monthly renewal cadence becomes the norm	CA/Browser Forum Ballot SC-081v3, endorsed by Sectigo, April 14, 2025

Why This Matters for Enterprise Certificate Lifecycle Management

Shorter validity periods are meant to shrink the window an attacker has to exploit a stolen or misissued certificate, and to force faster adoption of current cryptographic standards. Both goals are sound. The operational cost falls on whichever team is still managing certificate lifecycle management by hand.

Recent survey data shows how exposed manual processes already are, before validity periods even shrink. According to the DigiCert Trust Pulse Survey published July 2, 2025, 45 percent of enterprises reported experiencing service downtime due to certificate related incidents in the past year, and 37.5 percent of organizations attributed outages specifically to expired certificates, one of the most preventable causes of disruption in any enterprise environment. More than half of respondents said they were concerned about their own ability to track certificate expiration dates across their environment.

Those numbers describe today’s 398-day world. Compressing renewal cycles to 100 days, and eventually to 47, multiplies the number of renewal events every team has to execute correctly, without a matching increase in headcount. Manual tracking, spreadsheet based expiration logs, and one-off renewal requests do not scale down to a monthly cadence. Automated certificate lifecycle management is what makes the new schedule operationally survivable.

Risks of Manual Certificate Management in a 47 Day World

Every risk that already exists under manual certificate management gets worse as the renewal window shrinks. The main ones to plan around:

• Service outages: an unnoticed expiration on a 47-day cycle can recur many times a year instead of once, multiplying the chance of an outage reaching production.
• Security exposure: a missed or delayed renewal leaves a gap where an expired or misconfigured certificate can be exploited, and that gap opens more frequently as cycles shorten.
• Compliance findings: frameworks such as PCI DSS, HIPAA, and the EU’s DORA regulation expect documented, current certificate inventories; a manual process that cannot keep up becomes an audit finding on its own.
• Alert fatigue: teams that rely on calendar reminders or spreadsheet tracking will see renewal volume triple or quadruple by 2029, and manual alerting tends to fail quietly under that load.

Owner and Action Matrix: Who Does What

Certificate validity reduction is not solely a PKI team problem. Four groups typically share ownership, and each needs a distinct set of actions before the March 2026 deadline.

Team	Primary Responsibility	Key Actions Under the New Timeline
PKI Team	Certificate issuance architecture and CA relationships	Confirm ACME, EST, or SCEP support with every issuing CA in use; retire manual CSR based workflows; plan certificate authority and root rotation alongside the shortened validity schedule
Security Team	Risk ownership and incident prevention	Update risk registers to reflect the compressed renewal cadence; build certificate related outages into incident response runbooks; monitor private key exposure windows as renewal frequency increases
Platform and Infrastructure Team	Deployment and renewal automation	Deploy ACME clients or an automated certificate lifecycle management platform across load balancers, servers, and containers; build monitoring and alerting for renewal failures, not just expiration dates
Compliance Team	Regulatory alignment and audit evidence	Map the CA/B Forum schedule against PCI DSS, HIPAA, and DORA requirements; confirm audit documentation reflects the new renewal cycle rather than the old annual cadence

Readiness Checklist

• Inventory every publicly trusted TLS certificate and its issuing CA.
• Confirm ACME, EST, or SCEP support across all certificate authorities currently in use.
• Automate renewal for your highest risk, customer facing certificates before March 15, 2026.
• Build alerting for renewal failures, not only for approaching expiration dates.
• Assign a named owner to every certificate in your inventory.
• Align compliance documentation and audit calendars to the new validity schedule.

Migration Roadmap: What to Do Next

The three CA/B Forum deadlines give you natural planning horizons. Here is a realistic sequence for getting ahead of each one.

Before March 2026

Complete a full certificate inventory and confirm which of your issuing CAs already support ACME or an equivalent automated protocol. Pilot automated renewal on a small, low-risk set of certificates so your team has working experience with the tooling before the 200-day cap takes effect.

2026 to 2027

Expand automated renewal beyond the pilot group to cover the majority of your public-facing certificates. Use this window to retire remaining manual CSR workflows and to formalize ownership assignments across the PKI, security, platform, and compliance teams described above.

2027 to 2029

Reach full end-to-end automation across issuance, deployment, and renewal for every publicly trusted certificate in your environment. By this point a 47-day renewal cadence should be invisible to your operations team, handled entirely by automated tooling rather than manual intervention.

Connecting 47 Day Certificates to Post Quantum Readiness

The push toward shorter certificate lifespans and the push toward post-quantum cryptography share a common goal: crypto agility, the ability to swap algorithms, keys, and certificates quickly as standards change. An environment that can rotate a certificate every 47 days without manual intervention is, by definition, an environment that can adopt a new post-quantum algorithm faster once one becomes mandatory.

Getting there starts with visibility. You cannot automate renewal for certificates and cryptographic assets you do not know exist. A Cryptographic Bill of Materials, built with a platform like CBOM Secure, gives you a continuously maintained inventory of every certificate, algorithm, and key across your environment, which is the same inventory work described in the readiness checklist above. From there, Encryption Consulting’s PQC Center of Excellence and PQC readiness resources walk through how to sequence certificate automation alongside your broader post-quantum migration plan, rather than treating them as two separate projects.

How Encryption Consulting Can Help

Encryption Consulting’s CertSecure Manager is built for exactly the operational shift this timeline requires. It handles certificate discovery, inventory, issuance, deployment, renewal, revocation, and reporting from a single platform, with automated renewal that scales down to the 47-day cadence without adding manual workload.

Built-in alerts flag upcoming expirations and renewal failures before they become outages, and audit-ready reporting keeps PCI DSS, HIPAA, and DORA documentation current without a manual assembly effort ahead of every audit cycle. For organizations that also need visibility into their broader cryptographic posture, CertSecure Manager pairs with CBOM Secure to extend that same automation and inventory discipline across every algorithm and key, not only certificates.

Together, these tools let your PKI, security, platform, and compliance teams work from the same certificate inventory and the same renewal automation, instead of four separate spreadsheets racing the same deadline.

Conclusion

The number that matters is 47 days, not 90. Google’s original proposal opened the conversation, but the rule the industry actually adopted, CA/B Forum Ballot SC-081v3, reaches a shorter destination through a longer, phased path: 200 days by March 2026, 100 days by March 2027, and 47 days by March 2029.

Manual certificate management was already producing outages and compliance gaps under a 398-day cycle, as the DigiCert Trust Pulse Survey data above shows. It will not hold up under a monthly renewal cadence. Organizations that inventory their certificates now, automate renewal in stages against each deadline, and assign clear ownership across PKI, security, platform, and compliance teams will reach 2029 without disruption. Organizations that wait will be renewing certificates by hand every 47 days, at scale, with no automation in place.

Ready to automate before the next deadline hits? Contact us at [email protected] to see how CertSecure Manager can get your organization ready for the full 47-day certificate timeline.

Frequently Asked Questions

What is the main takeaway from Google’s TLS Certificate Validity Proposal: Are You Ready for the Shift from 398 Days to 90 Days?

Google’s 2023 proposal to cut TLS certificate validity to a flat 90 days was not the rule that ultimately passed. The CA/Browser Forum instead adopted Ballot SC-081v3, a phased reduction to 47 days by 2029, with intermediate steps at 200 days in March 2026 and 100 days in March 2027. The direction Google pushed for was correct, but the specific mechanism and endpoint changed.

Why does this matter for enterprise certificate lifecycle management?

Shorter validity periods mean far more renewal events per year for every publicly trusted certificate an organization operates. A process that renews certificates annually today will need to renew them roughly eight times a year by 2029. Enterprise certificate lifecycle management has to shift from a periodic, manual task to a continuous, automated one to keep up with that volume without increasing outage risk.

What teams are responsible for acting on this guidance?

Four teams typically share responsibility: the PKI team owns issuance architecture and CA relationships, the security team owns risk registers and incident response, the platform or infrastructure team owns deployment and renewal automation, and the compliance team owns mapping the new schedule to regulatory requirements such as PCI DSS, HIPAA, and DORA.

What risks increase if this topic is handled manually?

Manual certificate management already causes measurable harm today: the DigiCert Trust Pulse Survey found that 45 percent of enterprises experienced certificate related downtime in the past year, and 37.5 percent traced outages specifically to expired certificates. As renewal cycles compress toward 47 days, the same manual process has to execute correctly far more often, which raises the odds of a missed renewal, a service outage, or a compliance finding.

How does automation reduce certificate outage risk?

Automated certificate lifecycle management tools track expiration dates continuously, renew certificates before they lapse, and deploy the renewed certificate without manual steps. That removes the two most common failure points in manual processes: someone forgetting to act on an expiration alert, and someone deploying a renewed certificate incorrectly. Automation also scales down to shorter cycles without added headcount, which manual processes cannot do.

What metrics should teams track after implementation?

After automating certificate lifecycle management, track renewal success rate, the number of certificates renewed without manual intervention, mean time to renew after a triggered alert, the count of certificates still outside automated coverage, and any certificate related incidents or near misses. These metrics show whether automation coverage is actually keeping pace with the shrinking renewal window, rather than assuming it is.

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

The 47-day maximum is the final step in the CA/B Forum’s phased schedule, arriving March 15, 2029. Readiness for that date depends on the work done at the earlier milestones: organizations that automate renewal and build ownership structures during the 200-day and 100-day phases will find the 47-day cadence to be a continuation of an existing process rather than a new problem to solve from scratch.

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

Multi-cloud and hybrid environments need a certificate inventory and automation layer that spans every certificate authority in use, public and private, rather than separate tooling per cloud provider. A centralized certificate lifecycle management platform that supports ACME, EST, and SCEP across Microsoft, public, and private CAs gives PKI teams one place to enforce the new validity schedule consistently, instead of reconciling renewal policies across multiple disconnected systems.