Executive Summary

The CA/Browser Forum approved Ballot SC 081v3, introducing a staged reduction in the maximum permitted lifetime of publicly trusted TLS certificates. This article outlines the reduction schedule, the rationale behind the changes, the scope of enforcement, and considerations for private PKI environments.

Background

The CA/Browser Forum is the industry body responsible for defining requirements governing publicly‑trusted TLS certificates. These requirements are enforced indirectly through browser and OS root programs.

Ballot SC‑081v3, published in April 2025, introduces a multi‑year schedule to reduce both:

• Maximum certificate validity periods
• Maximum reuse periods for domain and organisation validation data

The full ballot text is available here.

Certificate Lifetime Reduction Schedule

The ballot defines the following phased reductions:

The values appear a little unusual but there is some logic behind this. There is a deliberate ~25% reduction each year and the values align with validation data reuse windows. The intention is also to avoid round numbers, that could encourage manual renewal practices and promote automation.

The final 47‑day limit is intentionally short to ensure that manual certificate management becomes operationally infeasible.

Scope of Applicability

Publicly‑Trusted CAs

These requirements explicitly apply ONLY to Public CAs as per the CA/B Forum Baseline Requirements.

This includes certificates issued by CAs whose roots are embedded in:

• Web browsers (Chrome, Firefox, Safari, Edge)
• Operating systems (Windows, macOS, iOS, Android, Linux distributions)

It is only these CAs that must comply with the new validity limits.

Private / Enterprise CAs

Private CAs are not governed by CA/B Forum rules. Their roots are not distributed* via browser/OS trust stores, and therefore:

• They are not subject to the Baseline Requirements
• They are not required to be audited under WebTrust/ETSI for public trust
• They may define certificate lifetimes according to internal policy

Internal private PKI environments often have operational constraints (e.g. legacy devices, isolated networks, IoT hardware) that make short certificate lifetimes impractical.

*Private CA certificates can be added to local root stores and are thus then trusted by Browsers - but are still not included in the CA/B Forum rules imposed by those browsers (see Enforcement Mechanisms below to find out how this works).

Should Private CAs Adopt Similar Lifetime Reductions?

While some organisations consider aligning private PKI with public CA/B Forum rules as best practice, this is not always beneficial. The motivations driving the CA/B Forum reductions do not always apply to internal environments.

Why Public CAs Benefit from Short Lifetimes

• Automation is ubiquitous: ACME (Automatic Certificate Management Environment) and other automated issuance mechanisms are already widely used. E.g. Around 60% of public sites are already protected by Let’s Encrypt (who provide free public CA certificates obtained via the ACME protocol).
• Revocation checking is unreliable: Browsers often soft‑fail OCSP/CRL checks, so shorter lifetimes reduce exposure to compromised keys.
• Domain ownership changes: Public domains may change hands, making long‑lived certificates risky.
• High‑value public endpoints: Public services face continuous exposure to internet‑scale threats.

Why Private CAs May Not Benefit

• Legacy or embedded systems may not support automated renewal.
• Air‑gapped or segmented networks may not be able to reach automation endpoints.
• Internal risk profiles differ: Private endpoints are not exposed to the public internet.
• Operational overhead may outweigh security benefits.

Private PKI should adopt certificate lifetimes that reflect internal threat models, not public web PKI requirements.

Enforcement Mechanisms

So how do browsers only enforce these rules for publicly trusted certificates when you can add your own private CA roots and intermediates to the trust store?

Browsers, have their own lists of publicly trusted certificates, separate from the Browser/OS certificate trust stores. These lists are the ones the browser uses to decide whether to impose the CA/B Forum rules.

The important thing to note is that adding an internal CA certificate, to an OS or Browser trust store, does not make it a candidate for the new rules.

These browser stores can be viewed. For example, if you open Chrome and type the following into the address window:

chrome://system/#chrome_root_store

and press Enter

You will be able to view the defined set of Public CA certificates.

Certificates under these CAs will be evaluated against the CA/B Forum rules. Any others in the trusted CA stores will not.

Implication

• Public CAs must comply with the new limits.
• Private CAs can issue certificates of any duration.
• Browsers enforce the rules by validating the issuing CA’s root against their internal trust stores.

What Does the TLS Certificate Lifetime Reduction Mean for Your Organisation?

If your organisation relies on publicly trusted TLS certificates for any internet-facing service, the practical effect of Ballot SC 081v3 is that the renewal cadence you are used to is about to change materially. A certificate issued today at the maximum 398 day validity will, by March 2029, be replaced by one valid for 47 days. That is a shift from roughly one renewal per year to approximately eight per year for every certificate in scope.

For most enterprises, the immediate implications fall into three areas. First, any team still renewing certificates manually will find the workload untenable well before 2029. A modest estate of 100 public certificates translates to roughly 800 renewals per year at the final cadence. Second, the window to react to an outage shrinks. A certificate that expires unexpectedly on a 47 day cycle cannot be recovered with the same manual scramble that a 398 day certificate permits. Third, validation data reuse is reducing in parallel, which means the operational overhead of revalidating domain and organisation information is compounding alongside the renewal cadence itself.

The organisations most exposed are those with fragmented certificate ownership, spreadsheet-based inventories, or certificates scattered across load balancers, CDNs, reverse proxies, and legacy middleware without a single authoritative view. Without automation, each reduction in the schedule increases the probability of a service-affecting expiry.

The cost of getting this wrong is well documented. We have written separately on the real cost of expired certificates and how CLM prevents it, which quantifies the operational and reputational impact of certificate-driven outages.

How to Prepare for 47 Day TLS Certificates

Preparation is not a 2029 problem. The first reduction lands in March 2026, the second in March 2027, and the third in March 2029. Each step reduces the margin for error. The organisations that transition cleanly will be the ones that treat the first reduction as the forcing function, not the last.

Preparation Checklist

1. Audit current renewal processes. Identify every publicly trusted certificate in the estate, the system it protects, the owner, the current renewal method, and the lead time typically required. This inventory is the baseline for every subsequent decision.
2. Evaluate ACME protocol support across your infrastructure. ACME is the de facto standard for automated public certificate issuance. Check which of your load balancers, web servers, CDNs, WAFs, and API gateways support ACME natively, which support it via an agent, and which do not support it at all. The last category is where the risk concentrates.
3. Implement Certificate Lifecycle Management automation. Manual renewal at a 47 day cadence is not a viable operating model for any non-trivial estate. CLM tooling provides the discovery, orchestration, and alerting required to operate at this frequency without relying on individual team members to remember renewal dates.
4. Test automated renewal workflows in non-production environments. Automation that has never been exercised under realistic conditions is a liability. Validate renewal, deployment, and service reload steps end to end, and confirm that monitoring correctly detects both successful renewals and silent failures.
5. Review CDN and load balancer certificate handling. Edge certificate management is a frequent blind spot. Certificates deployed to CDN providers, cloud load balancers, or third-party reverse proxies often sit outside the primary CLM scope and need to be brought into the same automated lifecycle.
6. Establish an exception process. Some systems will not support automated renewal in the short term. Document them, assign remediation owners, and track them as managed risk rather than allowing them to quietly drift toward a 47 day cliff edge.

Aligning CLM Capability With the New Cadence

Automation is the load-bearing requirement in this transition, and the automation story is larger than just ACME. Modern certificate management protocols each have their own strengths and trade-offs. Our comparison of CMP, ACME, EST, and SCEP sets out where each protocol fits, which is particularly relevant for organisations operating mixed public and private PKI environments.

The broader operational capability required to manage certificates at this cadence is what we describe as Certificate Lifecycle Management. For a structured view of what CLM covers and how it is delivered, see our certificate lifecycle management service.

Organisations that have historically deferred automation will encounter the cultural as well as the technical dimension of this shift. We address the common sources of resistance in overcoming resistance to automation in certificate management.

Conclusion

Ballot SC 081v3 represents a significant shift in the public web PKI, driving the ecosystem toward full automation, improved crypto-agility, and reduced exposure to compromised keys.

However, these requirements apply only to publicly trusted CAs. Private PKI environments should evaluate their own operational needs, security posture, and automation capabilities before adopting similar reductions.

In many cases, the CA/B Forum driven changes are not directly applicable to internal CAs and may introduce unnecessary complexity without corresponding security benefits.

For organisations that need support scoping their response, whether that is extending automation coverage for public certificates, modernising a private PKI estate, or aligning CLM tooling with the new cadence, our PKI consultancy service provides structured engagement from discovery through to delivery.