Stronger Security with TLS Certificates in 47-day Validity by 2029

CA/Browser Forum Ballot SC-081v3, approved April 2025, reduces the maximum validity of publicly trusted TLS certificates from 398 days to 47 days by March 15, 2029, in three phases. If your organization still relies on manual renewal workflows, calendar reminders, or any human-dependent process to track certificate expiry, the operational math stops working before the final phase arrives. The required first action is a complete certificate inventory: you cannot automate what you cannot find.

Quick Answer: What Is the 47-Day TLS Certificate Mandate?

CA/Browser Forum Ballot SC-081v3 cuts maximum TLS certificate validity from 398 days to 47 days by March 15, 2029, through three phases: 200 days from March 15, 2026 (already in effect), 100 days from March 15, 2027, and 47 days from March 15, 2029. Domain control validation (DCV) reuse shrinks on the same schedule, reaching 10 days in 2029. Manual renewal processes are not compatible with this schedule. ACME-based automation is required.

Key Takeaways

• CA/Browser Forum Ballot SC-081v3 cuts maximum TLS certificate validity from 398 days to 47 days in three phases: 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. Phase 1 is already in effect.
• Domain control validation (DCV) reuse periods shrink on the same schedule, reaching just 10 days by 2029, making ACME-based automated domain validation a hard operational requirement, not an optimization.
• 72% of organizations experienced at least one certificate-related outage in the past 12 months, and only 34% have a complete, current view of their own certificates. The 47-day schedule compresses that same workload into cycles six times shorter.
• Manual renewal and calendar reminders do not scale to 47-day certificates. ACME-based automation, deployment verification, and a central certificate inventory are now baseline requirements.
• Certificate pinning is fundamentally incompatible with 47-day validity. Environments using pinning must migrate to standard CA-based trust verification before March 2029.
• The renewal-deployment gap, where a renewed certificate is obtained but not deployed, is a critical failure mode at 47-day validity. Automation must include post-deployment verification.

What Did Ballot SC-081v3 Change and When Does Each Phase Take Effect?

Ballot SC-081v3 was originally proposed by Apple in January 2025. The CA/Browser Forum approved it on April 11, 2025, with 25 Certificate Authorities voting in favor and zero against. All four major browser vendors, Apple, Google, Microsoft, and Mozilla, voted yes. The IP Rights Review Period closed on May 13, 2025 with no objections, making the ballot fully enforceable from that date.

The ballot modifies two sections of the CA/Browser Forum TLS Baseline Requirements:

• Section 6.3.2: sets the phased schedule for reducing maximum TLS certificate validity periods.
• Section 4.2.1: sets the parallel schedule for reducing how long domain control validation (DCV) evidence can be reused between certificate issuances.

Both changes take effect in three phases, all on March 15 of each year:

Phase	Effective date	Max TLS certificate validity	Max DCV reuse period	Current status
Phase 1	March 15, 2026	200 days	200 days	In effect. Any new TLS certificate issued on or after this date carries a 200-day maximum.
Phase 2	March 15, 2027	100 days	100 days	Upcoming. Renewal frequency doubles relative to Phase 1.
Phase 3	March 15, 2029	47 days	10 days	Upcoming. Certificates renew approximately every 6 weeks. DCV must be re-verified at nearly every renewal.

Domain control validation (DCV) is the process a Certificate Authority uses to verify that a certificate applicant controls the domain being requested. Historically, that validated evidence could be reused for up to 398 days. SC-081v3 reduces this reuse window to just 10 days by March 2029, meaning domain ownership must be re-verified at nearly every certificate renewal. For a detailed walkthrough of automating the DCV step, see our guide to persistent DCV and DNS connectors.

Why Did the CA/Browser Forum Make This Decision?

The move toward shorter certificate validity has been building for over a decade. TLS certificates were valid for up to five years until 2015. The maximum dropped to three years in 2015, two years in 2018, and 398 days in 2020 when Apple unilaterally capped trust for new certificates in Safari. SC-081v3 continues that trajectory with a fixed endpoint. The CA/Browser Forum articulated four rationales for the change:

• Limiting the blast radius of compromised certificates: When a private key is stolen, a certificate is fraudulently issued, or a signing algorithm is found to be weak, the damage is directly proportional to how long the certificate remains valid. A 47-day certificate represents a far smaller window of exploitable trust than a 398-day certificate.
• Making revocation effective: Certificate revocation is largely broken in practice. Online Certificate Status Protocol (OCSP) operates on a soft-fail basis in most browsers, meaning if the OCSP responder is unreachable, browsers proceed rather than blocking the connection. Certificate Revocation Lists (CRLs) are infrequently updated and inconsistently checked. Let’s Encrypt phased out OCSP entirely in 2024 and completed that transition in 2025. At 47-day validity, natural expiry becomes the primary revocation mechanism.
• Enforcing stronger cryptographic practices: Long-lived certificates allow organizations to defer algorithm migrations. A certificate issued with a weak key size or deprecated algorithm in 2023 can remain in production until 2025 under 398-day validity. Shorter validity periods force more frequent issuance and more frequent application of current algorithm and key standards.
• Driving automation adoption: The CA/Browser Forum stated explicitly that one goal of SC-081v3 is to force adoption of automated certificate lifecycle management. A 47-day certificate renewed every six weeks is operationally incompatible with manual processes, making automation a structural requirement rather than a best practice.

What Does the Data Show About Current Certificate Management Maturity?

The disruption SC-081v3 creates is not hypothetical. Industry research shows an environment already stretched thin at 398-day validity:

• 72% of organizations experienced at least one certificate-related outage in the past 12 months, and 45% said outages were happening weekly, up from just 12% reporting weekly outages in 2022, according to the 2025 State of Machine Identity Security Report.
• Only 34% of organizations have a complete, current view of their own digital certificates, and nearly three-quarters are very or extremely concerned about outages caused by expired certificates, according to a 2026 global survey of more than 400 senior IT and security leaders.
• Machine identities now outnumber human identities by an estimated 82 to 1, and 79% of security leaders expect that ratio to grow further by as much as 150% over the next year.

These numbers describe an industry that was already failing at annual renewal cycles. Compressing the same workload into 47-day cycles, with a 10-day DCV reuse window that requires domain re-verification at nearly every renewal, is not something manual processes can absorb. For more on how machine identity growth compounds this problem for PKI teams, see our Machine Identity Guide for PKI Teams.

What Do 47-Day Certificates Mean Operationally?

The operational consequences of SC-081v3 vary by the size and complexity of the certificate estate and the current state of certificate management practices. Three areas create the most consistent operational challenges:

Certificate Inventory Visibility

You cannot automate the renewal of certificates you do not know exist. Certificate sprawl across multiple teams, cloud environments, Kubernetes clusters, CDN configurations, and legacy servers is the most common precondition for expiry outages. Under annual renewal cycles, an undiscovered certificate might go unnoticed for months before expiring. Under 47-day cycles, an untracked certificate will expire within weeks of issuance. Building comprehensive certificate inventory visibility across all environments, including internal services, non-customer-facing infrastructure, and certificates managed by external teams, is the foundational prerequisite for everything else.

The Renewal-Deployment Gap

One of the most common failure modes in automated certificate environments is the renewal-deployment gap: the ACME client successfully obtains a new certificate, but the deployment step that installs it on the relevant server, load balancer, or Kubernetes ingress fails silently. The renewed certificate sits unused while the old certificate continues serving traffic until it expires. At 47-day validity, this gap is a critical failure mode. Certificate renewal must be integrated with deployment verification confirming the new certificate is actually being served to clients before the renewal is marked complete.

Legacy Infrastructure and Certificate Pinning

Legacy applications with hardcoded certificates, IoT devices with firmware-embedded CAs, and environments using certificate pinning all represent points where 47-day certificates create challenges that automation alone cannot solve. Certificate pinning, where a client is configured to trust only a specific certificate or public key rather than any certificate from a trusted CA, is fundamentally incompatible with 47-day validity. The only viable approach for pinned environments is to migrate away from pinning toward standard CA-based trust verification before March 2029.

Manual vs. Automated Certificate Management: Which Approach Survives 47 Days?

The comparison below shows why manual processes stop being viable before Phase 3 arrives:

Requirement at 47-day validity	Manual or calendar-driven	Automated CLM (ACME + CertSecure Manager)
Renewals per certificate per year	1 today, rising to 8 or more by March 2029	Same volume, no added headcount
Domain validation (10-day DCV reuse by 2029)	Re-run by hand at every renewal cycle	Machine-to-machine challenge-response via ACME protocols (HTTP-01, DNS-01)
Certificate inventory	Spreadsheets, tribal knowledge, and manual scans	Continuous discovery across cloud, on-premises, and Kubernetes
Renewal-to-deployment gap	Common; renewed certificates can sit unused while old ones expire	Deployment verified automatically before renewal is marked complete
Outage risk	High, consistent with the 72% industry outage rate cited above	Lower; renewal triggers off expiry data, not a calendar reminder
Audit and compliance reporting	Manual log pulls; inconsistent coverage across environments	Centralized, exportable renewal and issuance history across all environments
DCV automation	Manual challenge completion; breaks at 10-day reuse window	ACME automates challenge completion; DNS connectors enable persistent DCV

How Should Organizations Prepare for the 47-Day Certificate Schedule?

With Phase 1 already in effect and Phase 2 arriving March 2027, the window to build the infrastructure required for the 47-day era is not infinite. The seven-step sequence below reflects the order in which dependencies must be resolved:

1. Build a complete certificate inventory: Discover every public TLS certificate across all environments and teams. Use Certificate Transparency (CT) log monitoring, cloud provider APIs, network scanning, and integrations with your CA’s management console. CBOM Secure performs continuous cryptographic discovery across cloud, on-premises, and Kubernetes environments, giving you a complete picture of every certificate before automating anything. This is the foundational step: everything else depends on knowing what you have. Evidence artifact: complete certificate inventory with CA, expiry date, installed location, and owner for each certificate.
2. Establish renewal alerting with phase-appropriate lead times: Under 200-day validity (Phase 1), set renewal alerts at 60 days before expiry. Under 100-day validity (Phase 2), set alerts at 30 days. Under 47-day validity (Phase 3), alerts should fire at 25 to 30 days, with escalating alerts at 14 days and 7 days. Evidence artifact: CLM platform alert configuration showing threshold per environment and phase.
3. Standardize on ACME for certificate issuance: The Automated Certificate Management Environment (ACME) protocol (RFC 8555) is the mechanism specifically designed for automated certificate issuance and renewal. CertSecure Manager supports ACME natively alongside SCEP and EST protocols, integrating directly with both public and private CAs. Evidence artifact: ACME client deployment records; automated renewal success logs showing domain validation completion.
4. Eliminate hardcoded renewal intervals: Audit all scripts, cron jobs, and automation configurations for hardcoded renewal intervals such as “renew every 60 days” or “renew every 90 days.” Replace with dynamic renewal logic based on certificate expiry dates or ACME ARI (Automatic Renewal Information) signals. Evidence artifact: configuration audit results; updated automation showing expiry-based renewal logic.
5. Close the renewal-deployment gap: For every certificate in scope, verify that the renewal process includes a deployment step and a post-deployment verification step confirming the renewed certificate is actually being served to clients. This is most critical in environments where renewal and deployment are handled by separate systems or teams. Evidence artifact: deployment verification logs showing certificate served matches renewed certificate for each renewal event.
6. Address legacy infrastructure and certificate pinning: Identify any systems that cannot participate in automated renewal: legacy servers, firmware-embedded certificates, and pinned configurations. For each, define a migration path before Phase 3. These changes are typically the most time-consuming and must start well before March 2029. Evidence artifact: legacy infrastructure inventory; migration plan with owner and target date for each system; certificate pinning removal records.
7. Establish centralized CLM governance: Move to a central certificate lifecycle management platform that provides unified inventory, renewal automation, deployment orchestration, and compliance reporting across all environments. The operational complexity of the 47-day era is not compatible with fragmented, per-environment certificate management. Evidence artifact: CLM platform deployment covering all in-scope environments; compliance report showing zero certificates within 7 days of expiry.

TLS 47-Day Readiness Audit Checklist

Use this checklist to assess your organization’s readiness for each SC-081v3 phase. Items are organized by which phase they become critical:

Control area	Requirement	Critical by	Evidence artifact	Status
Certificate inventory	Complete inventory of all public TLS certificates with CA, expiry date, installed location, and responsible team	Now (Phase 1 in effect)	CLM inventory export or CBOM Secure discovery report	To action
Phase 1 compliance	All new TLS certificates issued on or after March 15, 2026 have maximum 200-day validity	March 15, 2026 (already in effect)	CA issuance policy configuration; certificate audit confirming no new certificates exceed 200 days	To action
ACME automation deployment	ACME-based automated renewal deployed for all public TLS certificates	Before Phase 2 (March 2027)	ACME client deployment records; automated renewal success logs	To action
DCV automation	Automated domain control validation capable of completing HTTP-01 or DNS-01 challenges without manual intervention	Before Phase 2 (March 2027); critical by Phase 3 (10-day reuse window)	ACME challenge completion logs; DNS connector configuration	To action
Renewal alert thresholds	Alert thresholds configured per phase: 60 days for Phase 1, 30 days for Phase 2, 25 to 30 days for Phase 3	Ongoing; update at each phase	CLM platform alert configuration; alert delivery evidence	To action
Hardcoded renewal interval audit	No automation scripts or cron jobs use hardcoded renewal intervals; all use expiry-based or ACME ARI logic	Before Phase 2 (March 2027)	Configuration audit results; updated scripts showing dynamic renewal logic	To action
Renewal-deployment gap closure	Certificate renewal automation includes post-deployment verification confirming new certificate is served to clients	Before Phase 2 (March 2027)	Deployment verification logs per renewal event	To action
Phase 2 compliance	All new TLS certificates issued on or after March 15, 2027 have maximum 100-day validity	March 15, 2027	CA issuance policy configuration; certificate audit confirming compliance	To action
Legacy infrastructure migration	All systems using manual certificate deployment, hardcoded certificates, or firmware-embedded CAs have a documented migration plan with target date before March 2029	Before Phase 3 (March 2029)	Legacy infrastructure inventory; migration plan with owner and target date	To action
Certificate pinning removal	No production systems use certificate or public key pinning for publicly trusted certificates	Before Phase 3 (March 2029)	Application code audit; pinning removal records; standard CA-based trust verification confirmed	To action
Phase 3 compliance	All new TLS certificates issued on or after March 15, 2029 have maximum 47-day validity; DCV reuse does not exceed 10 days	March 15, 2029	CA issuance policy; DCV automation logs; certificate audit confirming compliance	To action
CLM central governance	Centralized CLM platform provides unified inventory, renewal automation, deployment orchestration, and compliance reporting across all environments	Before Phase 3 (March 2029)	CLM platform coverage report; compliance report showing zero certificates within 7 days of expiry	To action
Crypto-agility for authentication systems	CLM platform supports post-quantum certificate issuance for future migration as NIST PQC standards are adopted by browser root programs	Planning now; execution 2028 to 2030	Vendor PQC roadmap; CLM platform PQC support documentation	To action

How Encryption Consulting Can Help With the 47-Day Transition

Encryption Consulting is an ISO/IEC 27001:2022 and SOC 2 certified applied-cryptography firm. Our portfolio covers every component of the 47-day transition: automated lifecycle management, cryptographic discovery, fully managed PKI, and post-quantum readiness.

• CertSecure Manager: CertSecure Manager is Encryption Consulting’s certificate lifecycle management platform and the most direct operational answer to what the 47-day mandate demands. It automates certificate issuance, renewal, and deployment at scale using ACME, SCEP, and EST protocols. It automates enrollment and renewal across web servers including Apache, Tomcat, and IIS, and load balancers including F5 BIG-IP. Renewals trigger dynamically from certificate expiry data, not hardcoded intervals, making it inherently compatible with each SC-081v3 phase. It is built with crypto-agility at its core, allowing organizations to migrate to post-quantum certificates in a controlled, phased way as NIST PQC standards are adopted by browser root programs. See our Post-Quantum Cryptography Migration Guide for the full nine-phase migration framework.
• CBOM Secure (Cryptographic Inventory): CBOM Secure discovers every certificate across your infrastructure, including cloud accounts, on-premises environments, and Kubernetes clusters, so you know precisely what needs to be brought under automated management before each deadline hits. This is the foundational step in the seven-step preparation sequence: you cannot automate what you cannot find. See also our guide to The Cryptographic Blind Spot Hiding in Your Own Infrastructure for why most inventories miss critical certificates.
• PKI as a Service: For organizations that need to handle the significantly increased certificate issuance load of 47-day lifespans without overhauling internal PKI infrastructure, PKI-as-a-Service provides a fully managed CA built to scale with the new renewal frequency. As issuance rates increase sixfold by 2029, organizations running under-resourced internal CA infrastructure will face throughput and availability challenges. PKI-as-a-Service absorbs that load without requiring internal infrastructure changes.
• Persistent DCV and DNS Connectors: For organizations needing to automate the domain validation step itself, our persistent DCV and DNS connector guide covers ACME challenge automation for the 10-day DCV reuse window arriving in Phase 3.

Conclusion

The CA/Browser Forum’s decision to reduce TLS certificate validity to 47 days by March 2029 is the most significant shift in certificate lifecycle management in more than a decade. Phase 1 is already in effect. Phase 2 arrives in March 2027. The 47-day endpoint in March 2029 is a fixed deadline that browser enforcement will make non-negotiable.

The organizations that navigate each phase smoothly are the ones that treat certificate lifecycle management as automated, monitored, centrally governed, and continuously tested infrastructure rather than as a periodic administrative task. The organizations that wait for each phase to force the issue will face recurring operational crises with mounting frequency as validity periods continue to shorten.

Frequently Asked Questions

What is the CA/Browser Forum’s 47-day certificate validity rule?

Ballot SC-081v3, approved April 2025, reduces maximum publicly trusted TLS certificate validity from 398 days to 47 days by March 15, 2029, in three phases: 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. All major browser vendors, including Apple, Google, Microsoft, and Mozilla, voted in favor. Phase 1 is already in effect.

Do certificates issued before a phase deadline need to be replaced early?

No. A certificate issued before a phase’s effective date keeps its original validity period until it naturally expires. The new maximum only applies to certificates issued or renewed on or after each deadline. There is no grace period: any certificate issued on or after March 15, 2026 must comply with the 200-day maximum for that phase.

What is domain control validation (DCV) reuse and why does it matter?

DCV reuse is how long a Certificate Authority can rely on a previous domain ownership verification before requiring fresh proof. SC-081v3 reduces this to 10 days by March 2029, meaning domain ownership must be re-verified at nearly every certificate renewal. This makes ACME-based automated domain validation a hard operational requirement rather than a convenience.

Does the 47-day rule apply to internal or private certificates?

No. SC-081v3 only governs publicly trusted TLS certificates issued by CAs in browser root programs. Private or internal PKI is not subject to the CA/Browser Forum’s Baseline Requirements and can continue using longer validity periods. Many organizations choose to align internal policy with the public schedule for consistency and to simplify CLM automation.

What is certificate pinning and why is it incompatible with 47-day certificates?

Certificate pinning hardcodes a specific certificate or public key into a client application or device. At 47-day renewal cycles, the client must also be updated every six weeks, which is operationally unmanageable. The only viable approach is migrating away from certificate pinning toward standard CA-based trust verification before March 2029.

What is the renewal-deployment gap and how do organizations close it?

The renewal-deployment gap occurs when a new certificate is obtained but not deployed, leaving the old certificate serving traffic until it expires. At 47-day validity, this is a critical failure mode. Closing it requires that certificate renewal automation includes a post-deployment verification step confirming the new certificate is actually being served before marking the renewal complete.

How should organizations prepare for 47-day TLS certificates?

The seven-step sequence is: (1) build a complete certificate inventory; (2) establish phase-appropriate renewal alert thresholds; (3) standardize on ACME automation; (4) eliminate hardcoded renewal intervals; (5) close the renewal-deployment gap; (6) address legacy infrastructure and certificate pinning; and (7) establish centralized CLM governance. Start with the inventory, since every other step depends on knowing what certificates you have.