Preparing for 200-, 100-, and 47-Day TLS Certificates
Publicly trusted TLS certificate lifetimes are shrinking on a fixed schedule — 200 days now, 100 in 2027, 47 in 2029. Here is the timeline, the workload impact, and what to put in place.
As of 2026, the maximum lifetime of a publicly trusted TLS certificate is 200 days — reduced from 398 on 15 March 2026 — and the CA/Browser Forum has scheduled further cuts to 100 days in 2027 and 47 days in 2029 under ballot SC-081v3. The practical effect: calendar-and-spreadsheet renewal stops being viable. The way to stay online is to discover every certificate, automate renewal, and verify deployment before each cut lands.
The schedule, exactly
This isn't a rumor or a proposal — it's an adopted schedule with fixed dates. Maximum certificate validity steps down as follows: CA/B Forum
- 398 days — until 15 March 2026 (≈ 1 renewal/yr)
- 200 days — from 15 March 2026 · current (≈ 2/yr)
- 100 days — from 15 March 2027 (≈ 4/yr)
- 47 days — from 15 March 2029 (≈ 8/yr)
What shrinking lifetimes do to your workload
The security rationale is sound: shorter lifetimes limit how long a mis-issued or compromised certificate stays valid, and they force the automation that keeps inventories accurate. But the operational reality is a multiplier problem.
Take the renewals-per-year figure and multiply it by how many certificates you actually run — across load balancers, CDNs, internal services, cloud resources, and appliances. A team with a few hundred certificates moves from a few hundred renewals a year to a few thousand once the 47-day window arrives. Any process that relies on a person remembering, or a spreadsheet staying current, breaks well before then.
Three things to put in place now
1. Discover the full inventory
You cannot renew what you cannot see. Start with continuous discovery across every public domain, cloud account, and internal network — not a one-time spreadsheet export.
2. Automate issuance and renewal
Where the endpoint supports it, move to automated renewal with the ACME protocol so certificates reissue on a schedule without human involvement. At a 47-day cadence, automation isn't an optimization — it's the only model that holds.
3. Verify deployment — renewal isn't "done" at issuance
This is the step teams miss. A certificate that has been renewed but not actually deployed to the endpoint serving traffic still expires on schedule and still causes an outage. "Done" means the new certificate is installed, serving, and validated in production — not sitting in a directory.
# confirm the NEW certificate is the one actually being served
echo | openssl s_client -connect app.example.com:443 2>/dev/null \
| openssl x509 -noout -serial -enddate
serial=4F2A9C...E71B # matches the renewed cert
notAfter=Feb 09 23:59:59 2027 GMT # new expiry live in productionWhat about internal and private certificates?
The CA/Browser Forum schedule governs publicly trusted TLS certificates. CA/B Forum Certificates from a private or internal CA aren't bound by these exact limits — your organization sets their lifetimes. But the operational discipline is identical, and internal PKI often runs even shorter lifetimes for workloads and service meshes. Discovery, automated renewal, and deployment verification apply to every certificate you operate, public or private.
Frequently asked
What is the maximum TLS certificate lifetime in 2026?
For publicly trusted certificates it is 200 days, in effect since 15 March 2026 (down from 398). It steps down again to 100 days in 2027 and 47 days in 2029 under CA/Browser Forum ballot SC-081v3.
When does the 47-day certificate limit take effect?
On 15 March 2029, per the CA/Browser Forum schedule. The intermediate cut to 100 days takes effect 15 March 2027.
Do I have to replace certificates more often now?
Yes. Renewal frequency roughly doubles at each step — from about once a year at 398 days to roughly eight times a year at 47 days, per certificate. Across a real inventory, manual renewal stops being practical.
Does this apply to internal or private certificates?
No — the CA/Browser Forum limits govern publicly trusted certificates only. Private and internal CAs set their own lifetimes (often shorter). The automation and verification practices apply to every certificate you run.
- CA/Browser Forum — Ballot SC-081v3, Sunset of the SSL/TLS certificate validity period: 398 days (to 2026-03-15), 200 days (from 2026-03-15), 100 days (from 2027-03-15), 47 days (from 2029-03-15).
- RFC 5280 section 4.1.2.5 — certificate validity runs from notBefore through notAfter, inclusive.