Safeguard
Security Guides•

TLS certificate lifetimes are shrinking to 47 days: what to do

CA/Browser Forum rules cut public TLS certificate validity to 200 days, then 100, then 47. The dates and a plan to automate renewal before it hurts.

Safeguard Security Team
3 min read

The CA/Browser Forum Baseline Requirements cut the maximum validity of public TLS certificates in steps: 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Manual renewal stops being workable, so automate it now.

The schedule

From the Baseline Requirements:

  • 15 March 2026. Maximum certificate validity: 200 days. Domain validation reuse: 200 days.
  • 15 March 2027. Maximum certificate validity: 100 days. Domain validation reuse: 100 days.
  • 15 March 2029. Maximum certificate validity: 47 days. Domain validation reuse: 10 days.

The same document caps validations using the persistent DCV TXT record method at 10 days of reuse, and allows subject identity information to be reused for up to 398 days from 15 March 2026. Re-check the current text of the requirements before you plan around specific numbers.

Why it matters

A certificate renewed by hand once a year is easy to forget. At 47 days, you renew about eight times a year per certificate. Short reuse of domain validation means the proof of control must also be repeated often, so DNS or web server automation has to keep working.

Automate

OWASP's key management guidance prefers automated rotation through a key service or an automated certificate protocol such as ACME to reduce operational error.

A plan:

  1. Inventory. List every public certificate, who owns it, and where it is installed. Load balancers, CDNs, appliances and partner endpoints are the usual surprises.
  2. Pick an automated issuance path for each, using ACME clients or your platform's managed certificates.
  3. Check validation paths. Make sure DNS or HTTP challenges work without a human.
  4. Monitor expiry independently of the automation, with alerts at a threshold well inside the new lifetimes.
  5. Handle the exceptions. Devices that cannot be automated need a plan: replace, front with a proxy, or move to internal certificates where appropriate.

Keys are separate from certificates

OWASP points out that renewing a certificate does not necessarily replace its key pair. Decide on a key replacement schedule as well. See how often to rotate encryption keys.

Internal certificates from your own CA are not bound by these public rules, although the same discipline helps.

What the arithmetic means for operations

Take a team with 60 public certificates. At a 47 day maximum, that is roughly 450 renewals a year, or more than one a day, before counting emergency reissues. Even at 100 days it is over 200. Nobody does that by hand reliably. The practical consequence is that certificate ownership becomes a platform concern, with monitoring and a clear escalation path when a renewal fails. Decide who gets paged when automation breaks, test the failure path once, and make sure expiry alerts go to a shared channel and not one person's inbox.

Quick check

Do these limits apply to my private CA?

The Baseline Requirements govern publicly trusted certificates. Your own CA sets its own policy.

What breaks first when lifetimes shrink?

Usually the forgotten manual ones: appliances, partner endpoints and old load balancers.

Safeguard's asset discovery can help you find systems you did not know you were running, which is the first step of the inventory.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.