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

If your organization manages public TLS certificates today and is still relying on manual renewal workflows, calendar reminders, or any process that requires a human to notice an impending expiry and take action, the next three years are going to be genuinely disruptive.

On April 11, 2025, the CA/Browser Forum approved Ballot SC-081v3, formally titled “Introduce Schedule of Reducing Validity and Data Reuse Periods.” The vote was unambiguous: 25 Certificate Authorities in favor, zero against, with all four major browser vendors, Apple, Google, Microsoft, and Mozilla, voting yes. The result is a locked, phased schedule that reduces the maximum validity of all publicly trusted TLS certificates from 398 days today, down to 47 days by March 15, 2029.

In this blog, we will walk through exactly what SC-081v3 requires, why the CA/Browser Forum made this decision, what the operational consequences are for teams managing TLS certificates, and what your organization should be doing right now to stay ahead of each phase.

What Changed and When

Ballot SC-081v3 was originally proposed by Apple in January 2025 and 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 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 the same three phases; all on March 15 of each year:

Phase	Effective Date	Max TLS Certificate Validity	DCV Reuse Period
Phase 1	March 15, 2026	200 days	200 days
Phase 2	March 15, 2027	100 days	100 days
Phase 3	March 15, 2029	47 days	10 days

Before a Certificate Authority can issue a TLS certificate for a domain, it must first verify that the applicant actually controls that domain. This is domain control validation. In practice, a CA requires the applicant to complete a challenge, typically by placing a specific file at a known URL on the domain (HTTP-01), adding a specific DNS TXT record (DNS-01), or responding to a validation email sent to a registered contact address for the domain. Once the CA confirms the challenge is satisfied, it considers the domain validated. Historically, that validation evidence could be reused for up to 398 days, meaning a CA could issue subsequent certificates for the same domain without requiring fresh proof for over a year.

SC-081v3 reduces this reuse window in lockstep with certificate validity, ultimately dropping it to just 10 days by March 2029. At that point, domain ownership must be re-verified at nearly every certificate renewal, making automated DCV, through ACME’s challenge-response protocol, a hard operational requirement rather than an optimization.

As of today, Phase 1 is already in effect, with any new TLS certificate being issued carries a maximum validity of 200 days. Certificates issued before each phase deadline remain valid for their original term. Any certificate issued on or after each deadline must comply with the new maximum for that phase as there is no grace period for newly issued certificates.

Why the CA/Browser Forum Made This Decision

The move toward shorter certificate validity has been building for years. TLS certificates were valid for up to five years until 2015, when the CA/Browser Forum reduced that to three years. In 2018, the maximum dropped to two years. In 2020, Apple unilaterally capped trust for new certificates at 398 days in Safari, forcing the industry to adopt that limit across the board.

• Limiting the blast radius: When a private key is stolen, a certificate is fraudulently issued, or a signing algorithm is discovered to be weak, the damage potential is directly proportional to how long the certificate remains valid. A certificate with 47 days of remaining validity represents a far smaller window of exploitable trust than one with 398 days.
• Making revocation effective: Certificate revocation is, in practice, largely broken. Online Certificate Status Protocol (OCSP) operates on a soft-fail basis in most browsers, that is, if the OCSP responder is unreachable, browsers typically proceed rather than blocking the connection. Certificate Revocation Lists (CRLs) are infrequently updated and inconsistently checked. Let’s Encrypt began phasing out OCSP entirely in 2024 and completed that transition in 2025, citing its ineffectiveness.
• Stronger cryptographic practices: Long-lived certificates allow organizations to defer algorithm migrations. A certificate issued with a weak key size or a deprecated algorithm in 2023 might still be in production in 2026 if its validity extends that far. Shorter validity periods force more frequent issuance, which means more frequent opportunities to apply current algorithm and key standards.
• Required Automation: The CA/Browser Forum has stated explicitly that one of the goals of SC-081v3 is to drive the adoption of automated certificate lifecycle management. A 47-day certificate renewed every six weeks is not compatible with manual processes as the operational overhead is simply too high, which will make this process more reliable, more auditable, and more resilient than any human-dependent process.

What 47-Day Certificates Mean Operationally

The operational consequences of SC-081v3 vary significantly depending on the size and complexity of your certificate setup and the current state of your certificate management practices.

Certificate Inventory Visibility

You cannot manage the renewal of certificates you do not know exist. Certificate sprawl, where certificates are issued across multiple teams, cloud environments, Kubernetes clusters, CDN configurations, and legacy servers without central tracking, 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 or third-party services is the foundational requirement for this update in certificate validity timeline.

CI/CD and Deployment Integration

One of the more common failure modes in automated certificate environments is the “renewal-deployment gap”, where 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 in a file system, or secrets store while the old certificate continues serving traffic until it expires.

At 47-day validity, the deployment gap is a critical failure mode. Certificate renewal must be integrated with deployment and the new certificate must be verified as deployed and serving traffic before the renewal is considered complete.

Legacy Infrastructure and Certificate Pinning

Legacy applications with hardcoded certificates, IoT devices with firmware-embedded CAs, systems that use certificate pinning, and environments with manual deployment processes all represent points where 47-day certificates create genuine 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. If the pinned certificate must be replaced every six weeks, the client configuration must be updated at the same frequency. The only viable approach for pinned environments is to migrate away from pinning entirely toward standard CA-based trust verification before the 47-day mandate takes effect.

Prepare for the Shorter TLS Certificate Validity

With Phase 1 already in effect and Phase 2 arriving in March 2027, the window to build the infrastructure required for the 47-day era is not infinite. Here is a practical sequence for building readiness:

Step 1: Build a complete certificate inventory

Discover every public TLS certificate your organization has issued, across all environments and teams. Use Certificate Transparency (CT) log monitoring, cloud provider APIs, network scanning, and integrations with your CA’s management console to build a centralized inventory. Encryption Consulting’s CBOM Secure is purpose-built for exactly this. It performs continuous cryptographic discovery across your entire setup, giving you a complete picture of every cryptographic object before you begin automating anything. This is the foundational step as everything else depends on knowing what you have in your environment.

Step 2: Establish renewal alerting with appropriate lead times

The alert thresholds need to be reconfigured at each phase. 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, alerts should fire at 25–30 days, with escalating alerts at 14 days and 7 days.

Step 3: Standardize on ACME for certificate issuance.

ACME (Automated Certificate Management Environment) is the protocol specifically designed for automated certificate issuance and renewal. Encryption Consulting’s CertSecure Manager supports ACME natively alongside SCEP and EST protocols, making it the right platform to standardize on for automated certificate issuance and renewal at any scale. It integrates directly with both public and private CAs ensuring that your ACME-based renewal workflows are fully compatible with whichever CA your organization relies on.

Step 4: Eliminate hardcoded renewal intervals

Audit all scripts, cron jobs, and automation configurations that control certificate renewal. Any configuration with a hardcoded renewal interval such as “renew every 60 days” or “renew every 90 days” will break as certificate lifetimes continue to shorten. Replace with dynamic renewal logic based on certificate expiry dates or ACME ARI signals.

Step 5: Close the renewal-deployment gap

For every certificate in your inventory, verify that the renewal process includes a deployment step and a post-deployment verification step, confirming that 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 separate teams.

Step 6: Address legacy infrastructure

Identify any systems that cannot participate in automated renewal, including legacy servers, firmware-embedded certificates, and pinned configurations. For each, define a migration path before Phase 2 forces the issue. These are typically the most time-consuming and resource-intensive changes, and they need to start well before the final deadline.

Step 7: Establish centralized visibility and governance

Move toward a central certificate lifecycle management (CLM) platform such as our CertSecure Manager 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.

How Encryption Consulting Can Help

At Encryption Consulting, we have built a portfolio of products and services specifically designed to help organizations navigate the 47-day certificate transition, from automated lifecycle management and cryptographic discovery to fully managed PKI and post-quantum readiness.

CertSecure Manager is Encryption Consulting’s dedicated certificate lifecycle management platform and the most direct answer to what the 47-day mandate demands. It automates certificate issuance, renewal, and deployment at scale using ACME, SCEP, and EST protocols, and is built specifically for high-frequency renewal cycles where manual processes simply cannot keep pace.

The platform automates certificate enrollment and renewal across web servers including Apache, Tomcat, and IIS, and with load balancers including F5 BIG-IP. It integrates with public trusted CAs like DigiCert and Entrust, and private trusted CAs including Microsoft PKI, AWS Private CA, and HashiCorp CA. Renewals are triggered dynamically from certificate expiry data, not hardcoded intervals, making it inherently compatible with each new phase of the SC-081v3 schedule.

It is built with crypto-agility at its core and as NIST’s finalized PQC standards begin influencing browser and root program requirements, the platform helps organizations assess their current cryptographic posture and migrate to quantum-safe certificates in a controlled, phased way, without a platform replacement or disruptive manual migration.

Along with our CertSecure Manager, we also offer PKI-as-a-Service for organizations that need to handle the significantly increased certificate issuance load that comes with 47-day lifespans without building or overhauling internal PKI infrastructure. It provides a fully managed PKI built to scale with the new renewal frequency. As certificate issuance rates increase 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, letting your team focus on governance and compliance rather than CA operations.

CBOM Secure is another Encryption Consulting’s product for cryptographic discovery and inventory solution that will help you achieve and execute the roadmap for 47-day shift for TLS certificates. Before you can bring certificates under automated management you need to know exactly what cryptographic assets exist across your environment. CBOM Secure discovers every certificate across your infrastructure, so you know precisely what needs to be brought under automated management before each deadline hits.

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. With Phase 1 already here and Phase 2 arriving in March 2027, the 47-day endpoint in 2029 is now a matter of months away on the timelines for infrastructure planning.

The organizations that will understand and apply these phases 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.

At Encryption Consulting, we are here to help at every step of that journey. The time to build this infrastructure is now, before Phase 2 makes the gaps painful and difficult to manage.