Topic starter
04/07/2026 5:05 pm
TL;DR: Akeyless says public TLS certificate lifetimes will fall to 47 days by March 2029, with intermediate reductions in 2026 and 2027, making spreadsheet-based tracking too slow for discovery, renewal, provisioning, and revocation at scale. Manual certificate management stops being operationally survivable once every certificate needs repeated lifecycle action each year.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “Preparing for the 47-Day Certificate Era: A Full Certificate Lifecycle Demo”.
By the numbers:
- The maximum validity for a public TLS certificate drops to 47 days by March 15, 2029, under the CA/Browser Forum schedule.
- The reduction steps down from 398 days today through 200 days in 2026 and 100 days in 2027.
- A 47-day certificate means roughly eight renewals a year for each certificate.
Key questions
Q: What breaks when certificate lifetimes shrink to 47 days?
A: Manual certificate processes break first, followed by renewal consistency, deployment timing, and outage tolerance.
Q: Why do shorter TLS lifetimes create more governance risk for CLM teams?
A: They compress the time available to discover, replace, and validate certificates before they fail.
Q: How do security teams know if certificate lifecycle management is working?
A: Certificate lifecycle management is working when every certificate has a clear owner, renewal is automated or tightly managed, and expiry cannot occur without escalation.
Practitioner guidance
- Automate certificate discovery across all workloads Inventory hosts, ports, and DNS names continuously so unmanaged certificates are visible before they expire or drift outside policy.
- Move issuance into a governed CLM workflow Use managed issuance paths that tie certificate creation to ownership, naming, TTL, and approved destinations instead of ad hoc requests.
- Version renewals before revoking retired certificates Treat renewal as a new version of the same managed object, then provision it to the target and verify the live service before revoking the old version.
Bottom line: The 47-day certificate schedule turns certificate management into a continuous lifecycle problem rather than a periodic maintenance task.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step discovery commands for finding unmanaged certificates on a live NGINX target
- Live issuance, provisioning, and reload workflow against an Akeyless Gateway
- Renewal and version history output showing how replacement certificates are promoted safely
- Revocation and CRL verification commands for confirming retired certificates are no longer trusted
👉 Read Akeyless's walkthrough of the 47-day TLS certificate lifecycle →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
04/07/2026 5:05 pm
Short-lived certificates turn CLM into identity governance, not admin housekeeping. When a public TLS certificate drops to a 47-day validity window, the governance problem shifts from periodic maintenance to continuous state control. Discovery, issuance, renewal, and revocation now have to be treated as one lifecycle, because any gap between those steps becomes an outage or compliance defect.
A few things that frame the scale:
- According to the 2023 State of Machine Identity Management report, only 47% of companies have enough staff dedicated to their PKI.
A question worth separating out:
Q: What should teams do immediately when a managed certificate is compromised or obsolete?
A: Revoke the retired version, confirm the revocation is published, and keep the replacement certificate serving traffic before closing the old one out. The objective is to remove trust in the exposed credential without creating an avoidable outage on the live service.
👉 Read our full editorial: 47-day TLS certificates make manual lifecycle tracking untenable