TLS Certificates Go from Years to Days: The New Standard Limits Them to 47 Days and Mandates Full Automation

The digital certificate ecosystem is set to undergo a dramatic transformation in the coming years. The CA/Browser Forum—the organization that brings together leading certification authorities (CAs) and browser vendors—has approved a plan to gradually reduce the maximum lifespan of TLS certificates to just 47 days starting in 2029.

Behind this change lies a simple but compelling idea: long certificates are becoming less reliable, and the only way to maintain web security is through more frequent revalidation… and by completely automating their management.

A historic shift driven by Apple and supported by major players

The proposal to shorten the validity period of TLS certificates further was presented by Apple within the CA/Browser Forum via “Ballot SC-81.” The plan outlines a gradual schedule culminating in 2029 with a maximum validity of 47 days. The vote was approved in April 2025 after months of deliberation with browser manufacturers and certification authorities.

Google, which had previously advocated for a 90-day limit, supported Apple’s proposal almost immediately, establishing a clear consensus among the major ecosystem players in browsers and operating systems.

For the sector, the message is unequivocal: manual management of the certificate lifecycle is becoming obsolete.

Reduction schedule: from 398 days to just 47

Until now, the strictest practical limit was 398 days for a server TLS certificate. This was already a result of previous reductions (from the historic 3- and 5-year periods). Under the new standards, the CA/Browser Forum has set the following schedule:

Source: summary of ballot SC-81 and communications from commercial CAs.

Practically, this means that by the late 2020s:

• Any TLS certificate will not be valid for more than 47 days.
• The domain or IP control validation (DCV) performed by the CA to issue it can only be reused for 10 days.

In other words, organizations thinking of “renewing once a year” will simply be out of the game.

Why is the certificate lifespan being shortened so drastically?

Apple and other proponents cite several underlying reasons:

1. Certificate information ages poorly
   Ownership or control of a domain, associated infrastructure, or responsible parties can change quickly. The longer an old validation is reused, the less likely it reflects the current reality.
2. Revocation systems are inefficient
   Traditional revocation methods (CRL and OCSP) are problematic: lists can be huge, connectivity issues occur, and many browsers effectively ignore or soften revocation checks to maintain performance and user experience. Shortening certificate validity reduces the window during which a compromised certificate can be accepted.
3. Short-duration certificates have proven effective
   In 2023, the CA/Browser Forum itself opened the door to very short-duration certificates (e.g., 7 days) that don’t even require CRL or OCSP support. This experience supports the idea that shorter certificates + automation outperform long certificates + traditional revocation.
4. The world is moving toward automation
   Providers like Let’s Encrypt demonstrated that mass issuance of 90-day certificates via the ACME protocol is viable, making protection easier and more affordable for millions of websites worldwide.

Given this context, reducing the lifespan to 47 days is not arbitrary but the culmination of a trend: shorter certificates with increasingly automated management.

The role of automation: from attractive option to indispensable requirement

Various commercial CAs’ documentation already acknowledges that, with this schedule, manual management will become unfeasible well before 2029.

ACME and other lifecycle management solutions

The ACME (Automatic Certificate Management Environment) standard was created precisely to automate certificate issuance and renewal, validating domain control and deploying new credentials without human intervention through clients like Certbot, acme.sh, or integrations with web servers and network devices.

Beyond the “free” and community-based ecosystems, major certification authorities have been implementing their own automation solutions for years:

• Platform-based certificate lifecycle management (CLM) with centralized inventories.
• ACME integrations supporting DV, OV, and even EV certificates, as DigiCert does via its enterprise platforms.
• APIs for automated deployment and renewal in load balancers, TLS proxies, WAFs, or IoT devices.

Organizations that have not yet automated at least basic deployment and renewal processes for web servers, gateways, and critical services will need to do so before 2027… and very likely much earlier than 2029.

Impacts for businesses, hosting providers, and sysadmins

The change is not just about “setting a cron to renew certificates.” It affects processes, tools, and responsibilities.

1. Inventory and visibility

Many organizations still lack a comprehensive inventory of their certificates: forgotten subdomains, internal services, exposed APIs… With 47-day cycles, any “lost certificate” is a guarantee of downtime within weeks if not integrated into a centralized management platform.

2. Integration with critical infrastructure

Automated renewal on a web server is relatively straightforward. The real challenges include:

• Layer 7 load balancers and proxies.
• Network devices and firewalls terminating TLS.
• Legacy applications or appliances where manual certificate import remains necessary.

Each of these areas must be capable of receiving new certificates automatically (via API, scripting, native integration, or well-orchestrated periodic procedures).

3. OV/EV certificates and compliance processes

For OV and EV certificates, reducing the reuse of Subject Identity Information (SII) from 825 to 398 days isn’t as aggressive as for domain validation, but still requires revisiting internal compliance, KYC, and documentation workflows.

Issuers of numerous OV/EV certificates must ensure that:

• Corporate documentation is maintained up-to-date.
• Validation processes with the CA for re-verification are smooth and, where possible, partially automated.

4. Cultivating a “short-lived by design” culture

This shift encourages adopting a design mindset where all credential-related activities are based on short durations:

• External certificates with maximum 47-day lifespans.
• Tokens, API keys, and secrets rotated frequently.
• CI/CD pipelines and deployment workflows treating renewal as a routine event, not an annual exception.

What should organizations start doing today?

Although the most aggressive changes kick in 2029, the practical impact begins as early as 2026. Clear recommendations include:

1. Audit all existing certificates
   • Domains, subdomains, internal services, VPNs, APIs, load balancers…
   • Identify responsible parties and issuing CAs for each.
2. Adopt ACME or equivalent solutions
   • For public websites, start with ACME using an appropriate CA.
   • For OV/EV, evaluate automation options offered by current CA (enterprise ACME, agents, connectors, etc.).
3. Centralize management and monitoring
   • Use certificate lifecycle management platforms or at least monitoring systems that alert well in advance of expirations.
4. Redesign internal processes
   • Integrate certificate issuance and renewal into standard change cycles.
   • Train development, security, and ops teams on short lifecycle management.
5. Engage with CAs and providers
   • Inquire about automation tools (ACME, APIs, agents).
   • Review contracts and subscription models to prevent unexpected costs from frequent issuance.

Frequently Asked Questions about the reduced TLS certificate validity

How will the new 47-day validity period impact resource-constrained SMEs?
Even small businesses will need to abandon manual annual renewal processes. The good news is that free and commercial solutions based on ACME exist to automate almost entirely the issuance and renewal, reducing unexpected expiries without large investments.

What tools are available for automating TLS certificate renewal on web servers and load balancers?
The ACME protocol is supported by numerous clients (Certbot, acme.sh, lego, etc.) and many CAs, both free and paid. Most modern web servers, reverse proxies, and load balancers also include integrations or plugins for ACME or API-based automation, enabling seamless renewal and deployment.

How will management of DV, OV, and EV certificates change with the new validity limits?
DV certificates will be more affected by the reduction in domain validation reuse—forcing full automation of domain control checks. For OV and EV, organizations will need to maintain updated corporate documentation and ensure validation workflows are efficient and partly automated, considering the shorter 398-day reuse limit for subject information.

Can I continue using wildcard certificates under these new validity restrictions?
Yes, wildcard certificates will remain possible if supported by the CA and validation requirements are met. However, their maximum lifespan will now also follow the schedule (200, 100, 47 days), necessitating much more frequent renewal, ideally automated, just like other TLS certificates.

Sources:
CA/Browser Forum Ballot SC-81; Apple and Google documentation on reducing certificate lifespans; technical articles from DigiCert and other providers on automation and ACME; public documentation on ACME and Let’s Encrypt; Wikipedia entries and specialized PKI/TLS portals.