Google’s 90-Day Certificates: Quick and Effective Transition to 90-Day TLS/SSL Certificates

Quick answer: Public TLS/SSL certificates are not capped at 90 days. Under CA/Browser Forum Ballot SC-081v3, maximum certificate validity drops to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029. Organizations still issuing annual or 398-day certificates need automated certificate lifecycle management in place before the first deadline.

When Google first floated a 90-day cap on public TLS/SSL certificate validity, it was widely reported as the coming industry standard. That specific proposal never became the binding rule. Instead, the CA/Browser Forum passed Ballot SC-081v3, which sets a phased, multi-year reduction schedule that lands on 47 days by 2029, not a single jump to 90. Any certificate management plan still built around “90 days” is planning against a deadline that does not exist.

Key Takeaways

• The 90-day framing is outdated: CA/Browser Forum Ballot SC-081v3 (announced by Sectigo, April 14, 2025) replaced any single 90-day proposal with a phased schedule.

• Three deadlines, not one: Maximum public TLS/SSL certificate validity falls to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029.

• Manual renewal already breaks down at these intervals: DigiCert’s July 2, 2025 Trust Pulse Survey found 45% of organizations reported certificate-related downtime, and 37.5% traced outages directly to expired certificates.

• Spreadsheet tracking will not survive 47-day cycles: At roughly 7-8 renewals per certificate per year, manual tracking multiplies the workload that already causes outages today.

• Automation is the practical path: A certificate lifecycle management (CLM) platform like CertSecure Manager is how most enterprises meet each deadline without last-minute scrambles.

From Google’s 90-Day Proposal to the CA/B Forum’s Binding Schedule

Google raised the idea of a 90-day maximum validity period for public TLS certificates as part of its long-running push for shorter certificate lifetimes and stronger automation across the web PKI ecosystem. The proposal generated real debate: shorter lifetimes reduce the blast radius of a compromised key, but they also multiply the operational load on every organization that still issues and renews certificates by hand.

That debate was resolved through the CA/Browser Forum’s ballot process, not by a single browser vendor’s proposal. Ballot SC-081v3 passed and was announced by Sectigo on April 14, 2025, setting a phased reduction instead of an abrupt move to 90 or 47 days. The result is a schedule every publicly trusted certificate authority and every relying browser must follow: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029.

Content and guidance that still centers on “Google’s 90-day certificates” is describing a proposal that history overtook. The operative document is the CA/B Forum ballot, and the operative number enterprises should be planning around is 47 days, phased in over roughly three years.

Official Policy Sources and Effective Dates

TLS Certificate Validity Timeline: 200 → 100 → 47 Days

Each step below is binding on every publicly trusted certificate authority and enforced by every major relying-party browser. Use this table to line up your renewal cadence, automation rollout, and audit evidence against the actual deadlines.

Implementation note: validate this table’s effective dates against the current CA/B Forum ballot text before each renewal cycle, since validation and reuse periods are subject to further ballots and should be re-checked, not assumed static.

Why Shorter Certificate Lifecycles Matter for Enterprise Certificate Lifecycle Management

Shorter validity periods are a direct response to a problem enterprises already have, not a new one being created. DigiCert’s July 2025 Trust Pulse Survey found that 45% of organizations reported certificate-related downtime, and 37.5% traced an outage directly to an expired certificate. Those numbers describe today’s environment under 398-day certificates. A move to 47-day certificates does not fix that underlying gap on its own; it removes the option of managing certificates manually and getting away with it.

Advantages of Shorter-Validity Certificates

• Enhanced Security

  If a private key is compromised, a shorter validity period shrinks the window an attacker can use it. Faster expiry and mandatory key rotation limit the damage even when a compromise goes undetected for a while.

• Stronger Compliance Posture

  Frequent, forced renewal keeps cryptographic parameters current against evolving CA/B Forum baseline requirements, reducing the chance of an audit finding a certificate issued under an outdated policy.

• Faster Adaptability

  Organizations are not locked into long-term certificate commitments, so a new algorithm requirement or revoked CA does not leave certificates stranded for a year or more.

• Lower Misuse Window

  A stolen or misissued certificate has less time to be used before it expires on its own, on top of any revocation action.

• Tighter Key Management

  More frequent renewals force more frequent key rotation, which is one of the most effective, least glamorous controls in key management.

• Simpler Long-Term CLM

  Once automation is in place, short-lived certificates are actually easier to operate than long-lived ones: issuance, renewal, and revocation all run on the same predictable, automated cadence.

Risks of Manual Certificate Management Under Shorter Lifecycles

An expired certificate causes the same failures today that it always has; shorter cycles just mean it happens more often unless renewal is automated.

• Data Breaches

  When an SSL certificate expires, the secure connection it protected goes down with it, and attackers can intercept whatever was previously encrypted in transit.

• Service Interruption

  Expired certificates take sites and services offline. Browser warnings drive users away before they even see the content, which shows up directly in revenue and support tickets.

• Search Engine Penalties

  Expired SSL certificates can hurt search visibility, since major search engines actively deprioritize sites without valid HTTPS.

• Reputation Damage

  An outage caused by something as preventable as an expired certificate erodes customer trust in a way that takes far longer to rebuild than the renewal itself would have taken.

Certificate Automation: Reducing Outage Risk

Automation directly targets the 37.5% expired-certificate outage figure from DigiCert’s survey. It removes the two things that cause most certificate outages: a human forgetting a date, and a renewal process too slow to finish before expiry.

1. Time and Cost Savings

   Certificate automation removes manual handoffs between systems, freeing IT and security teams to work on higher-value tasks instead of chasing renewal dates.

2. Fewer Human Errors

   A single manual misconfiguration or missed renewal can cause an outage. Automation applies the same validated process every time, at every certificate count.

3. No Last-Minute Renewals

   At 47-day validity, “renew it next week” is not a viable strategy. Automated renewal triggers well ahead of expiry, every cycle, without relying on someone remembering.

4. Stronger Security Posture

   Certificates that renew automatically and on schedule close the exact gap (expired or lapsed certificates) that both the DigiCert survey and this article’s risk list point to as the leading cause of certificate-related incidents.

Impact by Role and Date: Who Needs to Act and When

The 47-day schedule touches more than the team that clicks “renew.” Use this matrix to route ownership before the March 2026 deadline, not after it.

PKI and Security Teams

PKI and security teams own the policy decisions: validity periods, key sizes, revocation SLAs, and which certificate authorities are approved. Under the phased schedule, these teams should treat certificate discovery as the first deliverable, not an afterthought, since you cannot automate renewal for certificates you do not know exist.

Platform and DevOps Teams

DevOps teams consume the largest share of certificates in most organizations, particularly in CI/CD pipelines. API-driven issuance through protocols like ACME, EST, or SCEP is what lets certificates get provisioned automatically during deployment instead of through a ticket queue that cannot keep pace with 47-day renewals.

Compliance Teams

Compliance teams need certificate inventory and renewal evidence that stays current between audits, not a spreadsheet assembled right before one. A CLM platform that generates reports on demand turns a multi-week audit-prep exercise into a query against live data.

Readiness Checklist and Migration Roadmap

Quick Readiness Checklist

• Complete a full certificate inventory, including self-signed certificates and shadow certificates outside the managed CA.

• Confirm every certificate has a named owner, not just a technical contact left over from provisioning.

• Select and pilot a CLM platform capable of ACME, EST, and SCEP issuance before March 2026.

• Set renewal automation to trigger with enough lead time to survive a failed first attempt.

• Map current validity periods and compliance frameworks so audit evidence is ready before the 100-day step.

• Confirm CI/CD and DevOps pipelines request certificates via API, not manual submission.

Migration Roadmap

A CLM rollout that meets the 47-day deadline without a scramble generally follows the same sequence:

1. Inventory

   Build a complete inventory of every certificate in the environment, including the ones nobody currently owns. This is the step most delayed migrations skip.

2. Certificate Discovery

   Run active and passive discovery to surface hidden and self-signed certificates that never went through a formal issuance process; these are frequently the ones that cause surprise outages.

3. Monitoring and Reporting

   Put continuous monitoring in place so anomalies in issuance or renewal are caught immediately, not discovered when a service goes down.

4. Automation

   Automate renewal end to end. At 47-day cycles, following up with certificate owners manually for days or weeks per certificate is no longer operationally possible.

5. Workflows and Policy

   Centralize policy enforcement so every new certificate request is validated against approved validity periods, key sizes, and issuing CAs before it is ever issued.

6. DevOps Integration

   Connect the CLM platform to CI/CD tooling via API so certificates provision automatically as part of deployment, matching the pace shorter validity periods demand.

CertSecure Manager: Automating Certificate Lifecycle Management for the 47-Day Era

CertSecure Manager covers certificate lifecycle management end to end (discovery, inventory, issuance, deployment, renewal, revocation, and reporting) through automation rather than manual handoffs. Built-in alerts flag upcoming expirations early enough to act, and reporting is built to support NIST, HIPAA, GDPR, and CA/B Forum compliance requirements without a manual evidence-gathering exercise before every audit.

Organizations using CertSecure Manager are positioned to move through each step of the phased schedule (200 days, then 100, then 47) on the same automated process, rather than re-architecting certificate management every time the CA/B Forum’s requirement changes.

Connecting Certificate Automation to Crypto-Agility and PQC Readiness

Certificate automation is not just a response to a shorter validity schedule; it is the same operational capability that post-quantum migration depends on. An organization that can renew, reissue, and rotate certificates automatically already has the foundation for crypto agility: the ability to change cryptographic primitives quickly and with confidence as standards shift.

That connection matters directly for teams already tracking post-quantum cryptography deadlines. Encryption Consulting’s PQC readiness programs and CBOM Secure platform build on the same discovery and inventory work described above: a complete, current certificate inventory is also the starting point for a Cryptographic Bill of Materials (CBOM). Teams that have already automated certificate lifecycle management are not starting from zero when PQC migration planning begins.

For a deeper look at turning that inventory into an actionable, continuously maintained system of record, see how a Cryptographic Bill of Materials turns inventory into intelligence.

What to Do Next

• PKI teams: finish certificate discovery and inventory, and confirm every certificate has a named owner before March 2026.

• Security teams: set validity, key size, and revocation policy now so it does not get set ad hoc under deadline pressure later.

• Platform teams: move certificate requests in CI/CD pipelines to API-driven issuance ahead of the 100-day step.

• Compliance teams: confirm CLM reporting maps to your existing audit frameworks well before the 47-day step makes manual evidence-gathering impractical.

Conclusion

The certificate industry is not moving to 90-day validity because Google proposed it. It is moving to 200, then 100, then 47 days because the CA/Browser Forum voted a binding schedule into effect. That distinction matters because the timeline, the deadlines, and the compliance obligations are different from what “90-day certificate” content still describes.

Organizations that treat this as a one-time renewal-frequency change will struggle at each step. Organizations that treat it as the trigger to finally automate certificate lifecycle management, and build the crypto-agility that automation enables, will meet March 2026, March 2027, and March 2029 on the same platform, without re-architecting their approach three times.

Frequently Asked Questions

What is the main takeaway from Google’s 90-Day Certificates: Quick and Effective Transition to 90-Day TLS/SSL Certificates?

Google’s original 90-day proposal was superseded by CA/Browser Forum Ballot SC-081v3, which sets a phased schedule instead: maximum public TLS/SSL certificate validity drops to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029. Plans should target this schedule, not a flat 90-day figure.

Why does this matter for enterprise certificate lifecycle management?

Shorter validity periods multiply how often every public-facing certificate must be renewed. Enterprises running certificate management manually will see renewal frequency roughly double at the 200-day step and rise again at each later step, turning an occasional task into a constant operational load without automation.

What teams are responsible for acting on this guidance?

PKI and certificate teams own inventory, discovery, and policy. Security teams set validity, key size, and revocation rules. Platform and DevOps teams integrate issuance into CI/CD pipelines. Compliance teams confirm that renewal and inventory reporting satisfies existing audit frameworks throughout the transition.

What risks increase if this topic is handled manually?

DigiCert’s July 2025 Trust Pulse Survey found 45% of organizations reported certificate-related downtime, with 37.5% tracing outages directly to expired certificates under today’s longer validity periods. Manual tracking at 47-day cycles increases the frequency of the same failure modes: outages, data exposure, search penalties, and reputational damage.

How does automation reduce certificate outage risk?

Automated renewal removes the two leading causes of certificate outages: a person forgetting a renewal date, and a manual process too slow to complete before expiry. A CLM platform triggers renewal on a fixed schedule with enough lead time to recover from a failed first attempt, regardless of certificate count.

What metrics should teams track after implementation?

Track certificate inventory completeness (including self-signed and shadow certificates), percentage of certificates on automated renewal, renewal failure rate, mean time to reissue after a failure, and the number of certificates still requiring manual action at each phase of the schedule.

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

The 47-day requirement, effective March 2029, is the final step of the same CA/B Forum schedule discussed in this article. The discovery, inventory, and automation work needed for the 200-day and 100-day steps is the same foundation 47-day certificate readiness requires; there is no separate project to build later.

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

Multi-cloud and hybrid environments need a single certificate inventory and CLM platform spanning every cloud provider and on-premises CA, rather than separate tracking per environment. Certificate discovery must cover all environments, since shadow certificates are more likely to appear where infrastructure is split across providers.