Executive summary

The CA/Browser Forum has approved Ballot SC-081v3, introducing a staged reduction in the maximum permitted lifetime of publicly trusted TLS certificates, alongside parallel reductions in how long validation data may be reused.

This article sets out the schedule, the reasoning the Forum gave for it, how enforcement actually works, and why private PKI environments should think carefully before adopting the same limits.

Background

The CA/Browser Forum is the industry body responsible for defining requirements governing publicly trusted TLS certificates. Those requirements are enforced indirectly, through browser and operating system root programs rather than by the Forum itself.

Ballot SC-081v3 was proposed by Clint Wilson of Apple and endorsed by Sectigo, Google Chrome and Mozilla. It passed on 11 April 2025 with 25 certificate issuers voting in favour, none against and five abstaining, and with all four certificate consumers — Apple, Google, Microsoft and Mozilla — voting in favour.

The ballot introduces a multi-year schedule reducing two things in parallel:

• Maximum certificate validity periods, from 398 days to 47 days.
• Maximum reuse periods for validation data, with domain validation dropping from 398 days to 10 days, and non-domain validation data from 825 days to 398 days.

The full ballot text is available from the CA/Browser Forum.

The reduction schedule

Certificate validity reduces in three stages:

• Issued on or after 15 March 2026, before 15 March 2027 — maximum 200 days.
• Issued on or after 15 March 2027, before 15 March 2029 — maximum 100 days.
• Issued on or after 15 March 2029 — maximum 47 days.

Domain validation data reuse reduces on the same timeline, reaching 10 days by March 2029. This is the less discussed of the two changes and arguably the more operationally significant: by 2029 a CA cannot rely on domain validation evidence more than ten days old when issuing a certificate, so re-validation becomes a recurring activity rather than something that happens at renewal.

Why 47 days

The figure is not arbitrary. It comes from CA/Browser Forum discussions as one maximal month of 31 days, plus half a 30-day month of 15 days, plus a single day of margin. That accommodates a monthly renewal cadence with enough slack for a failed renewal to be retried, while being short enough that manual management becomes impractical.

A practical note on the numbers

Certificate authorities are issuing slightly below the stated limits. DigiCert moved to 199 days from 24 February 2026 and Sectigo from 12 March 2026.

The reason is that CA/Browser Forum validity limits are precise to the second, and exceeding one by even a single second constitutes misissuance, which triggers mandatory revocation. Most CA software measures certificate terms midnight to midnight, which is 24 hours and one second — over the limit. Rounding down by a day avoids a mass revocation event caused by an edge case.

The Baseline Requirements themselves define a day as 86,400 seconds and advise that certificates should not be issued for the maximum permissible period by default. In practice this only matters to CAs and CLM vendors. If you renew a week or two early, the distinction is irrelevant.

Why the Forum made these changes

The ballot sets out its own reasoning, and it is worth reading rather than inferring. The stated benefits are:

• Certificates are a point-in-time record. At issuance, the data they certify is correct. The more time passes, the more likely that data has diverged from reality. Shorter lifetimes raise the average reliability of certificates in circulation.
• Formerly-correct certificates carry real risk. Domains change hands, key access passes to third parties, and organisations restructure. Research cited in the ballot documents security-relevant events that allow a third party to impersonate a domain outside their control. Shorter lifetimes reduce both the likelihood and the duration of that exposure.
• Improper validation is contained. More frequent revalidation limits how long a mistake in the validation process can persist and how many certificates it can affect.
• Revocation does not work well enough. The ballot is explicit that CRLs and OCSP do not adequately protect relying parties at internet scale, citing privacy concerns, performance impact, timeliness and reliability. Shorter validity provides protection that does not depend on revocation infrastructure functioning correctly.
• Cryptographic transitions become faster. Where a weakness is found in an algorithm or library, a shorter maximum validity means the ecosystem can move through a transition in months rather than years. This is directly relevant to the eventual post-quantum migration.
• Automation improves as a consequence. The Forum describes better certificate lifecycle automation as an ancillary benefit rather than the objective — though for most organisations it is the part that determines whether the transition is manageable.

The fourth point is the one most coverage misses. A significant part of the rationale is that revocation has never worked reliably enough to be depended on, and shorter certificate lifetimes are a way of limiting exposure without requiring revocation to function.

Scope: who this applies to

Publicly trusted CAs

These requirements apply only to public CAs, as defined by the CA/Browser Forum Baseline Requirements. That covers certificates issued by CAs whose roots are embedded in:

• Web browsers — Chrome, Firefox, Safari, Edge.
• Operating systems — Windows, macOS, iOS, Android and Linux distributions.

Only these CAs must comply with the new validity limits. The Baseline Requirements themselves are explicit that they address certificates "intended to be used for authenticating servers accessible through the Internet", and that other use cases, including private PKI, are not in scope.

Private and enterprise CAs

Private CAs are not governed by CA/Browser Forum rules. Their roots are not distributed through browser or operating system trust stores, and therefore:

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

Internal PKI environments frequently have operational constraints — legacy devices, isolated networks, IoT hardware — that make very short certificate lifetimes impractical.

Note that a private CA certificate can be added to local root stores and will then be trusted by browsers. It is still not covered by the CA/Browser Forum rules those browsers enforce. The mechanism for that is explained below.

‍

How browsers enforce the rules

If you can add your own private CA root to a trust store, how do browsers apply these rules only to publicly trusted certificates?

The answer is that browsers maintain their own lists of publicly trusted CAs, separate from the operating system trust store. It is these lists that determine whether the Baseline Requirements are applied.

Adding an internal CA certificate to an OS or browser trust store does not make it a candidate for the new rules.

You can view this directly. Open Chrome, enter the following in the address bar and press Enter:

chrome://system/#chrome_root_store

Expand the chrome_root_store entry and you will see the defined set of public CA certificates. Certificates chaining to those CAs are evaluated against the Baseline Requirements. Anything else in the trusted CA stores is not.

The practical implication:

• Public CAs must comply with the new limits.
• Private CAs may issue certificates of any duration.
• Browsers enforce the distinction by validating the issuing CA's root against their own internal trust store.

Should private CAs adopt similar reductions?

Some organisations treat alignment with CA/Browser Forum rules as best practice for internal PKI. That is not always beneficial, because the motivations driving the public reductions do not all apply internally.

Why public CAs benefit from short lifetimes

• Automation is ubiquitous. ACME and equivalent mechanisms are already widely deployed across the public web, and Let's Encrypt alone issues a very substantial share of publicly trusted certificates.
• Revocation checking is unreliable. Browsers frequently soft-fail OCSP and CRL checks, so shorter lifetimes are the practical mitigation for a compromised key.
• Domain ownership changes. Public domains change hands, which makes long-lived certificates a genuine risk.
• Public endpoints face constant exposure. Internet-facing services are under continuous, internet-scale attack.

Why private CAs may not

• Legacy and embedded systems may not support automated renewal.
• Air-gapped or segmented networks may be unable to reach automation endpoints.
• Internal risk profiles differ, since private endpoints are not exposed to the public internet.
• Operational overhead may outweigh the security benefit.

Private PKI should adopt certificate lifetimes that reflect internal threat models, not public web PKI requirements. That said, the operational capability required to run short lifetimes — discovery, automated enrolment, renewal orchestration — is worth building regardless, because it is the same capability post-quantum migration will depend on.

What this means for your organisation

If you rely on publicly trusted TLS certificates for any internet-facing service, the practical effect is that your renewal cadence changes materially. A certificate that would once have run for 398 days will, by March 2029, run for 47. That is a move from roughly one renewal per year to approximately eight, for every certificate in scope.

Three consequences follow.

Manual renewal stops being viable well before 2029. A modest estate of 100 public certificates translates to roughly 800 renewals per year at the final cadence.

The window to recover from a failure shrinks. A certificate expiring unexpectedly on a 47-day cycle cannot be recovered with the same manual scramble a 398-day certificate permitted, because the process has to work every time rather than once a year.

Validation overhead compounds alongside renewal. Domain validation reuse reducing to 10 days means re-validating domain ownership becomes a continuous activity, not something that happens at issuance.

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 with no single authoritative view. Each step in the schedule increases the probability of a service-affecting expiry.

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

Preparation is not a 2029 problem. The first reduction has already taken effect, the second lands in March 2027, and 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 rather than the last.

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, and most organisations find more certificates than their records show. Our guidance on building a cryptographic inventory covers where to start.

Evaluate ACME support across the 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 it natively, which support it via an agent, and which do not support it at all. The last category is where the risk concentrates.

Implement certificate lifecycle management

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 depending on individuals remembering renewal dates.

Test automated renewal end to end

Automation that has never been exercised under realistic conditions is a liability. Validate renewal, deployment and service reload as a complete sequence, and confirm that monitoring detects silent failures as well as successful renewals. A renewal is not complete until the application is actually serving the new certificate.

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 bringing into the same automated lifecycle.

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 drift quietly towards 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 ACME alone. Certificate management protocols each have their own strengths and trade-offs, and our comparison of CMP, ACME, EST and SCEP sets out where each fits — particularly relevant for organisations operating mixed public and private PKI.

The broader operational capability required to manage certificates at this cadence is what we describe as certificate lifecycle management, and our article on the four pillars of CLM sets out what good looks like.

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 towards automation, improved crypto-agility and reduced exposure to compromised keys.

These requirements apply only to publicly trusted CAs. Private PKI environments should evaluate their own operational needs, security posture and automation capability before adopting similar reductions. In many cases the changes are not directly applicable to internal CAs and may introduce complexity without a corresponding security benefit.

For organisations that need support scoping their response — 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 assessment and delivery. A PKI health check establishes the current position first.

Talk to our team about your certificate estate.