47-Day TLS Certificates

Quick answer: The CA/Browser Forum’s Ballot SC-081v3 cuts the maximum public TLS certificate lifespan from 398 days to 47 days by March 2029, phased through 200 days in 2026 and 100 days in 2027, with domain validation reuse dropping to 10 days. Manual renewal cannot keep pace, making automated certificate lifecycle management essential for PKI, security, platform, and compliance teams.

TLS (Transport Layer Security) certificates, still commonly called SSL certificates after their predecessor protocol, are the digital credentials that secure the connection between a browser and a website. They encrypt traffic, verify that a site is who it claims to be, and trigger the padlock icon browsers show for a properly secured connection. Get certificate management wrong and that padlock disappears, along with customer trust.

That foundation is about to be tested on a much tighter clock. The CA/Browser Forum, the industry body of certificate authorities and browser vendors that sets the rules for public trust on the web, has approved a phased reduction in maximum certificate lifespan that ends at 47 days by March 2029. Backed unanimously by Apple, Google, Mozilla, and Microsoft, the change also compresses how long a completed domain validation can be reused, tightening the entire certificate issuance and renewal cycle. For organizations still relying on spreadsheets and manual renewal calendars, this is the deadline that turns certificate management from an occasional chore into a continuous operational discipline.

Key Takeaways

• The CA/Browser Forum’s Ballot SC-081v3, approved April 11, 2025, cuts maximum public TLS certificate validity from 398 days to 47 days by March 15, 2029, in three phases: 200 days (March 2026), 100 days (March 2027), and 47 days (March 2029).
• Domain Control Validation (DCV) reuse shrinks in parallel, from 398 days down to 10 days by 2029, so domain ownership must be reverified far more often.
• A DigiCert Trust Pulse Survey (July 2, 2025) found that 45% of enterprises experienced certificate-related downtime in the past year, and 37.5% of those outages traced to expired certificates.
• Manual certificate tracking cannot sustain 47-day renewal cycles at enterprise scale; automation through ACME and a certificate lifecycle management (CLM) platform becomes a requirement, not an option.
• PKI, security, platform and DevOps, and compliance teams each carry distinct action items ahead of the March 2026 and 2027 deadlines, detailed in the impact matrix later in this article.
• Earlier proposals, including Google’s 2023 suggestion of 90-day certificates, did not become the adopted standard. The current, binding requirement is the 47-day schedule under Ballot SC-081v3.

Official Policy Timeline for 47-Day TLS Certificates

Every deadline below comes from a single, binding source: CA/Browser Forum Ballot SC-081v3, approved on April 11, 2025 with 29 votes in favor and none opposed. The table lists the effective date, the requirement that takes hold, who it affects, the action to take, and the official source for verification.

Effective Date	Requirement	Who Is Impacted	Action Needed	Source
March 15, 2026	Maximum validity: 200 days DCV reuse: 200 days	All publicly trusted TLS certificates (DV, OV, EV)	Move certificate tracking off spreadsheets; pilot ACME-based issuance	CA/Browser Forum Ballot SC-081v3
March 15, 2027	Maximum validity: 100 days DCV reuse: 100 days	All publicly trusted TLS certificates	Automate renewal for all internet-facing certificates; extend discovery to internal and cloud-issued certificates	CA/Browser Forum Ballot SC-081v3
March 15, 2029	Maximum validity: 47 days DCV reuse: 10 days	All publicly trusted TLS certificates	Full CLM automation with persistent or scripted DCV in place; manual renewal is no longer viable	CA/Browser Forum Ballot SC-081v3

Policy sources: DigiCert Trust Pulse Survey (July 2, 2025) found that 45% of organizations reported certificate-related downtime and 37.5% linked outages to expired certificates. Full report: digicert.com/news/digicert-survey-finds-manual-processes-expose-organizations. CA/Browser Forum Ballot SC-081v3, announced via Sectigo (April 14, 2025), confirms the phased schedule to 200 days (March 2026), 100 days (March 2027), and 47 days (March 2029). Full announcement: sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-days.

How Certificate Lifespans Got Shorter

The 47-day figure is not a sudden jump. Maximum certificate validity has been trending downward for well over a decade:

• 2011: Certificates were valid for up to 8 to 10 years, prioritizing convenience over cryptographic agility.
• 2015: Reduced to 3 years as the industry recognized the security cost of long-lived keys.
• 2018: Reduced to 2 years, driven by faster advances in cryptanalysis and CA/Browser Forum pressure.
• 2020: Reduced to 398 days (about 13 months) in September, the ceiling that held until the 2026 phase of SC-081v3.
• 2025 to 2029: Ballot SC-081v3 phases validity down to 200 days, then 100 days, then 47 days, the schedule this article covers.

What Is Changing and Why It Matters

The shift from 398-day to 47-day certificates did not happen in one step, and it did not land where the industry first expected. In 2023, Google proposed cutting TLS certificate lifespans from 398 days to 90 days, and Apple pushed further with a 47-day proposal. After roughly two years of CA/Browser Forum discussion and a formal ballot, the industry settled on Apple’s 47-day figure, delivered through the phased SC-081v3 schedule. If a source still frames 90 days as the upcoming standard, treat that as outdated: the approved, binding requirement is 47 days by March 2029, reached through the 200-day and 100-day intermediate steps covered above.

Organizations still running deprecated protocols such as TLS 1.0 or TLS 1.1, or relying on weak cipher suites like RC4 or SHA-1, face a harder transition. These protocols and algorithms are vulnerable to attacks such as POODLE and BEAST, and most current browsers and certificate authorities no longer support them. Shorter certificate lifespans and stricter validation policies make TLS 1.2 (preferably TLS 1.3) and modern cipher suites such as AES-GCM and Elliptic Curve Cryptography (ECC) a practical requirement rather than a best practice: AES-GCM adds authenticated encryption that helps prevent data tampering, and ECC delivers strong security with shorter, faster keys.

The Case for Shorter Lifespans

Shorter validity periods are a direct, low-effort way to raise an organization’s security baseline. The benefits show up in four areas.

• Reduced attack surface: A compromised certificate is only useful to an attacker for a short window. In April 2025, SSL.com discovered a flaw in its domain validation process that led to the misissuance of 11 TLS certificates, which could have supported spoofed sites or man-in-the-middle attacks. The certificates were revoked within 24 hours, but the incident showed how quickly a validation gap can turn into exposure when certificates live for months rather than weeks.
• Faster cryptographic refresh: Frequent renewals create natural checkpoints to retire outdated algorithms and rotate keys, which matters more after Mozilla and Google moved to distrust Entrust-issued certificates in 2024. Shorter lifespans make it easier to switch certificate authorities and reduce reliance on any single long-term trust anchor.
• Cleaner certificate inventory: Frequent renewals surface forgotten or orphaned certificates that would otherwise sit unmanaged for years. Cisco has reported that more frequent renewal cycles helped its teams identify and retire orphaned certificates that had been creating unnecessary risk.
• Stronger fit with cloud and DevOps: Ephemeral, cloud-native infrastructure already treats credentials as short-lived. Certificate lifecycles that match that pattern integrate more cleanly with CI/CD pipelines and reduce the number of stale credentials sitting in an environment.

The Operational Risks

None of this comes free. Compressing renewal cycles by up to eight times a year multiplies the operational load on teams that still manage certificates by hand.

• Exponential renewal volume: Moving from 398-day to 47-day certificates means up to eight renewals a year instead of one. An organization managing 500 certificates manually would need to process roughly 4,000 renewal events annually, a workload manual processes cannot realistically absorb.
• Manual processes fail under load: Microsoft Teams suffered a three-hour outage in 2019 when an expired authentication certificate locked out roughly 20 million users. A shorter, tightly monitored renewal cycle paired with automation would likely have caught the expiration well in advance; without automation, the same gap only gets more dangerous as renewal frequency climbs.
• Outages become more likely without automation: According to the 2022 State of Machine Identity Management Report, around 81% of organizations experienced at least one certificate-related outage that year. Google Voice suffered a global outage in 2021 tied to an expired TLS certificate, and Cisco SD-WAN devices have failed in the field when a hardware certificate lapsed.
• Compliance exposure grows: In the Equifax breach, a monitoring device’s expired certificate went unnoticed for 19 months, during which the company was carrying 324 expired SSL certificates, 79 of them on critical monitoring systems. Shorter lifespans without matching visibility multiply the number of certificates that can expire in exactly this way.

Impact by Team and Date

The SC-081v3 timeline touches more than the certificate team. Here is what changes for the four groups that typically share ownership of TLS certificates, and the first action each should take.

Team	What Changes	First Action	Target Date
PKI and Certificate Team	Renewal frequency roughly doubles in 2026 and again in 2027, then increases sharply in 2029	Complete a full certificate discovery and inventory across on-premises, cloud, and hybrid environments	Before March 2026
Security Team	Shorter validity narrows the exploitation window for a compromised key, but only if revocation and monitoring keep pace	Confirm OCSP stapling and CRL distribution are configured correctly and actively monitored	Before March 2026
Platform and DevOps Team	CI/CD pipelines, load balancers, and application configs built around long-lived certificates need to support ACME-based renewal	Integrate ACME clients and DNS or HTTP validation automation into deployment pipelines	Before March 2027
Compliance Team	Audit evidence must reflect certificates that now change far more often than once a year	Move certificate inventory reporting to a continuous, automated model instead of a point-in-time snapshot	Ongoing, before March 2027

47-Day Certificate Readiness Checklist

• Inventory every certificate across on-premises, cloud, and hybrid environments, including short-lived and internally issued certificates.
• Identify every system that still assumes a 90-day, one-year, or longer certificate lifecycle.
• Deploy ACME or an equivalent protocol for automated issuance and renewal.
• Configure persistent or automated domain control validation so renewal does not depend on a manual step.
• Set expiration alerting well ahead of the deadline, not only at the point of failure.
• Assign a named owner for every certificate and every automation workflow.
• Extend the same discipline to internal PKI and private certificates. They are not bound by CA/Browser Forum rules, but they carry the same operational risk.

Automation: The Only Viable Path Forward

With renewals landing every few weeks instead of every year, manual certificate management stops being merely inconvenient and becomes a liability. The CA/Browser Forum’s own rationale for Ballot SC-081v3 treats automation as the baseline assumption, not an optional upgrade, and regulatory frameworks such as HIPAA, DORA, and PCI DSS are placing growing emphasis on certificate management as part of broader digital trust requirements.

Organizations managing large certificate inventories still need to solve several problems before automation runs smoothly end to end.

• Automated revocation: Revoking a certificate in real time and ensuring every dependent system reflects the change is harder than it sounds at scale.
• Timely propagation: Revocation status has to reach OCSP responders and CRLs quickly, or stale, vulnerable certificates stay trusted longer than they should.
• OCSP stapling and CRL management: Both require careful configuration so browsers and systems receive current revocation information without added latency.
• Dependency management: Certificates usually have application or service dependencies that need coordination during renewal or revocation.
• Audit and visibility: Automated actions need to be logged and traceable to support compliance requirements and troubleshooting.
• Downtime risk: Automation configured incorrectly can cause the exact outages it was meant to prevent.

Done well, automation reduces the risk of errors and downtime while improving cost efficiency and audit readiness. As renewal frequency climbs toward the 2029 deadline, automation shifts from a competitive advantage to the baseline requirement for staying secure and compliant.

Recommended Steps to Implement Automation

These steps reflect the sequence organizations have found most reliable when moving off manual certificate management.

1. Conduct a complete audit of the current certificate inventory.
2. Identify every platform and system that requires automation.
3. Select a certificate lifecycle management solution that covers the full renewal and revocation workflow.
4. Integrate the CLM platform with existing infrastructure and DevOps pipelines.
5. Define clear renewal, issuance, and revocation policies.
6. Schedule regular compliance checks and reporting.

Migration Roadmap for 47-Day Certificate Readiness

Readiness for 47-day certificates is not a single project. It builds in stages, and each stage extends naturally into the broader crypto agility work most PKI and security teams already have on their roadmap.

1. Discover and inventory: Run certificate discovery across on-premises, cloud, and hybrid infrastructure before evaluating any automation tool. A cryptographic discovery and inventory platform such as CBOM Secure surfaces certificates and cryptographic assets that manual tracking typically misses.
2. Automate issuance and renewal: Move internet-facing certificates onto ACME-based issuance and renewal first, since these carry the most immediate business risk if they expire.
3. Extend crypto agility beyond TLS: Certificate automation is one piece of a larger crypto agility practice. Pair it with a living inventory, covered in more depth in how a cryptographic bill of materials turns inventory into intelligence, so algorithm and key changes can roll out without a fire drill.
4. Build toward post-quantum readiness: Shorter TLS lifespans and the coming post-quantum transition share the same underlying requirement: the ability to change cryptographic material quickly and safely. Teams building that muscle now can review PQC readiness guidance and the PQC Center of Excellence to extend certificate automation into a broader quantum-safe migration plan.

How Encryption Consulting’s CertSecure Manager Can Help

CertSecure Manager by Encryption Consulting is built for the operational reality of shorter certificate lifespans. As renewal cycles compress toward 47 days, automation moves from a nice-to-have to the mechanism that keeps certificates from becoming a source of outages.

Automated Certificate Discovery and Inventory

CertSecure Manager discovers certificates across on-premises, cloud, and hybrid environments, including self-signed certificates that often go unmanaged. A centralized inventory makes it possible to see every certificate due for renewal well before the 47-day deadline creates pressure.

Advanced ACME Protocol Integration

By supporting the ACME protocol, CertSecure Manager automates issuance and renewal in a standardized, secure way, removing the manual steps that break down once renewals happen every few weeks instead of once a year.

Automated Renewal, Reissuance, and Revocation

CertSecure Manager keeps certificates current automatically and revokes compromised or unnecessary certificates without waiting on a manual ticket. That reduces both the security exposure of a lingering certificate and the administrative load of tracking renewal dates by hand.

Compliance and Reporting

CertSecure Manager runs automated compliance checks against standards such as PCI DSS, GDPR, and ISO, and generates audit-ready reports on demand. That turns certificate compliance from a manual, point-in-time exercise into something a compliance team can pull whenever an auditor asks.

Integrations and Renewal Agents

CertSecure Manager integrates with tools such as Terraform, Ansible, and Azure Key Vault, and automates certificate provisioning and deployment inside CI/CD pipelines across databases and web servers including Apache, IIS, and NGINX. Renewal agents tailored to each service keep certificates current with minimal manual intervention, which is exactly the capability the 47-day schedule requires at scale.

Conclusion

The move to 47-day TLS certificates is one clear example of how digital trust standards are evolving to meet modern threats. Shorter lifespans meaningfully reduce the window an attacker can exploit a compromised certificate, but they also demand a level of automation and visibility that manual processes cannot deliver. Organizations that start with discovery, move quickly to automated issuance and renewal, and extend that same discipline to their broader cryptographic estate will meet the 2026, 2027, and 2029 deadlines without the outages that manual approaches tend to produce.

Encryption Consulting offers a full range of certificate and cryptography services, including PKI audits, enterprise PKI design and optimization, encryption audits, and code signing through the CodeSign Secure platform. We support Zero Trust initiatives and provide ongoing compliance advisory alongside strong identity and encryption practices, so your organization stays protected, compliant, and ready for what comes after 47-day certificates.

Frequently Asked Questions

What is the main takeaway from 47-day TLS certificates?

The main takeaway is that public TLS certificate validity is shrinking to 47 days by March 2029 under CA/Browser Forum Ballot SC-081v3, with intermediate steps of 200 days in 2026 and 100 days in 2027. Domain validation reuse falls to 10 days over the same period. Manual certificate management cannot sustain that renewal frequency, which makes automated certificate lifecycle management a near-term requirement rather than a future consideration.

Why does this matter for enterprise certificate lifecycle management?

Enterprises with hundreds or thousands of certificates will see renewal volume climb from once a year to as often as every 47 days, roughly an eightfold increase. Certificate lifecycle management platforms that were previously optional become operationally necessary, since manual tracking and spreadsheet-based renewal calendars cannot keep pace with that frequency without a meaningful risk of missed deadlines.

What teams are responsible for acting on this guidance?

PKI and certificate teams, security teams, platform and DevOps teams, and compliance teams all share responsibility. PKI teams own discovery and inventory, security teams own revocation and monitoring, platform teams own pipeline automation, and compliance teams own audit evidence. The impact and action matrix earlier in this article breaks down what each group should prioritize before the March 2026 and 2027 deadlines.

What risks increase if this is handled manually?

Manual handling increases the risk of missed renewals, unplanned outages, and compliance gaps. The 2022 State of Machine Identity Management Report found that around 81% of organizations experienced a certificate-related outage in a single year, and incidents such as the Microsoft Teams and Google Voice outages both traced back to expired certificates that manual processes failed to catch in time.

How does automation reduce certificate outage risk?

Automation removes the dependency on a person remembering a renewal date. ACME-based issuance, persistent domain validation, and integration with CI/CD pipelines let certificates renew on schedule without manual intervention, while automated monitoring can flag failures before they cause downtime. This matters more as renewal cycles compress from 398 days to 47 days, since the margin for human error shrinks along with the certificate lifespan.

What metrics should teams track after implementation?

Teams should track certificate renewal success rate, the number of certificates discovered outside the managed inventory, mean time to renew, expired or near-expired certificate count, and the share of certificates issued through automated workflows versus manual request. Tracking these consistently shows whether automation is actually reducing outage risk rather than shifting the same manual work to a different tool.

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

This article is the policy and impact explainer behind 47-day certificate readiness: it lays out the CA/Browser Forum timeline, why it exists, and who it affects. Readiness is the operational response, building the discovery, automation, and monitoring capability described in the migration roadmap above so the 2026, 2027, and 2029 deadlines arrive as scheduled maintenance rather than as an emergency.

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

Multi-cloud and hybrid environments need one centralized view of certificates issued across every cloud provider, on-premises CA, and SaaS platform, since fragmented visibility is exactly what allows certificates to expire unnoticed. A certificate lifecycle management platform that supports ACME, SCEP, and EST across these environments, paired with cryptographic discovery that spans cloud and on-premises infrastructure, keeps the renewal cadence consistent regardless of where a certificate was issued.