Executive Summary

The CA/Browser Forum approved Ballot SC‑081v3, introducing a staged reduction in the maximum permitted lifetime of publicly‑trusted TLS certificates.

Between 2026 and 2029, certificate validity will decrease from 297 days to 47 days, with reductions applied annually.

These requirements apply exclusively to Public CAs. Private enterprise CAs are not subject to these rules and may continue to define certificate lifetimes according to internal policy, operational constraints, and risk appetite.

This paper 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.

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.