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.
At a glance
What this is: This is a certificate lifecycle management walkthrough showing why 47-day public TLS certificates make manual inventory, renewal, and revocation workflows untenable.
Why it matters: It matters because shorter certificate lifetimes turn CLM into an always-on identity governance problem for workloads, not a periodic admin task.
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.
👉 Read Akeyless's walkthrough of the 47-day TLS certificate lifecycle
Context
Public TLS certificate lifetimes are collapsing from a yearly cycle into a short, repetitive operational rhythm. Certificate lifecycle management is the discipline of discovering, issuing, provisioning, renewing, and revoking certificates as one governed workflow, so expiries do not become outages or audit findings.
For identity teams, this is a workload identity and machine trust problem as much as a certificate problem. Manual tracking cannot keep pace when the same certificate must be located, replaced, and validated repeatedly across hybrid and multi-cloud environments.
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. When certificates behave like short-lived machine identities, any gap in inventory or ownership becomes an operational failure, not just an administrative delay. Security teams need automated issuance, deployment, and revocation to keep trust continuous.
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. That increases the chance of service disruption and weak audit evidence unless lifecycle management is automated and tied to clear ownership, renewal policy, and revocation handling.
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. Teams should also verify that dependent controls keep operating during renewal events. If certificates still depend on ad hoc admin tracking, the process is not mature enough.
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.
Technical breakdown
Why shorter TLS lifetimes break manual certificate operations
A public TLS certificate with a 47-day lifetime compresses every operational step that used to tolerate human scheduling. Discovery, issuance, provisioning, renewal, and revocation must happen as a linked system, because the margin for missed handoffs disappears. Spreadsheet tracking fails here not because people are careless, but because the renewal cadence is faster than manual inventory and approval loops can reliably support across distributed workloads.
Practical implication: replace ad hoc certificate tracking with continuous inventory and policy-driven renewal.
How CLM turns certificate renewal into a controlled workflow
CLM treats the certificate as a governed object with state transitions, not a static file on a server. A managed certificate can be issued, pushed to a workload, versioned on renewal, and revoked when needed, while the service reloads to pick up the new material. That structure matters because the trust artifact, the private key, and the running workload all have to stay aligned throughout the lifecycle.
Practical implication: define certificate ownership and lifecycle state transitions before shortening validity periods.
Why revocation and versioning matter more as expiries accelerate
Shorter certificate validity reduces exposure windows, but it also makes failure handling more important. If renewal produces a new version and the retired version is revoked cleanly, teams can rotate without dropping traffic. If revocation, CRL publication, or service reloads are not integrated, the organisation gets the worst of both worlds: more frequent change and more frequent service disruption.
Practical implication: test renewal, rollback, and revocation paths as one operational control set.
Threat narrative
Attacker objective: The objective is to create a service outage or exploit a certificate management gap before teams notice the trust state has changed.
- Entry occurs when an unmanaged or self-signed certificate is already live on a workload and outside central inventory.
- Credential access or abuse happens when teams keep relying on manually tracked certificate state instead of governed issuance and renewal.
- Impact emerges as missed expiry, failed trust validation, or an audit gap that can take the service down or leave it operating on stale trust material.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Manual certificate tracking no longer matches the operational tempo of modern trust infrastructure. Spreadsheets and ticket queues assume there is enough time to notice, approve, and replace each certificate before expiry. That assumption fails when renewals happen multiple times per year across large workloads, so the real issue is lifecycle visibility, not just certificate volume.
Certificate lifecycle management is now a control plane for workload trust. The article shows that the managed object, the target service, and the post-provision reload all have to stay in sync. That makes CLM part of broader machine identity governance, where the question is not whether a certificate exists, but whether it can be replaced safely at runtime.
Reduced validity strengthens security only when revocation and versioning are operationally real. Shorter lifetimes shrink the compromise window, but they also expose weak recovery paths. If revoked versions are not tracked, published, and enforced cleanly, the organisation gains more churn without getting the resilience the new schedule is supposed to deliver.
Named concept: certificate renewal tempo mismatch. The gap between human-paced certificate handling and machine-paced expiry is the central failure mode here. Practitioners need to assess every certificate workflow for whether it can operate at the tempo the public CA ecosystem now requires.
From our research library:
- According to the 2023 State of Machine Identity Management report, only 47% of companies have enough staff dedicated to their PKI.
- Read next: Machine Identity, PKI and Certificate Lifecycle Guide
What this signals
Certificate renewal tempo mismatch: The operational problem is no longer whether teams can issue certificates, but whether they can replace them at the pace the public CA ecosystem is moving toward. That shifts CLM into the same governance category as other workload identity controls, where issuance, replacement, and revocation must be measurable and continuous.
Short-lived certificates reward organisations that can prove state changes, not just store credentials. Discovery, versioning, and revocation evidence become the controls that determine whether certificate policy is real or merely documented.
For practitioners
- 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.
- Test revocation publication and service reload behavior Confirm that revocation status reaches the issuer CRL or equivalent publication path and that workloads reload the new certificate without downtime.
Key takeaways
- The 47-day certificate schedule turns certificate management into a continuous lifecycle problem rather than a periodic maintenance task.
- The biggest risk is not just expiry, but the inability to prove discovery, renewal, provisioning, and revocation across every workload.
- Automated CLM is the only practical way to keep short-lived certificates from becoming outages or audit failures.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Short-lived public TLS certificates create the same lifecycle pressure as long-lived machine credentials. |
| NHI-01 — Improper Offboarding | Revoked or retired certificates must be removed cleanly to avoid stale trust remaining active. | |
| Recommendation — Automate certificate renewal and replacement before validity windows collapse into outages. Revoke retired certificates and remove stale trust paths as part of offboarding. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate renewal and revocation are authenticator lifecycle controls. |
| Recommendation — Apply IA-5 to manage certificate issuance, renewal, and revocation as governed lifecycle events. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Certificate compromise and stale trust material both support credential abuse paths. |
| Recommendation — Map certificate exposure and compromise to TA0006 and prioritise exposed trust material for rotation. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Certificate lifecycle is part of cloud identity governance across workloads. |
| Recommendation — Govern certificate issuance and revocation through cloud IAM controls and continuous inventory. | ||
Key terms
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
- Certificate Discovery: Certificate discovery is the process of locating certificates already deployed across hosts, ports, DNS names, and services. It is the inventory foundation for lifecycle control because unmanaged certificates cannot be renewed, revoked, or audited reliably.
- Certificate Renewal Tempo: Certificate renewal tempo is the rate at which certificates must be replaced to stay valid and trusted. As public TLS lifetimes shrink, the tempo becomes a governance constraint because human-paced processes may be too slow to support repeated renewal, versioning, and revocation.
- Certificate Versioning: Certificate versioning is the practice of treating each renewed certificate as a new tracked version of the same managed item. That approach preserves history, supports rollback, and makes it possible to replace a live certificate without losing auditability or breaking the running service.
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
👉 Akeyless's full post covers the live demo, renewal sequence, and revocation verification in detail.
Deepen your knowledge
NHI governance, identity lifecycle management, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or CLM programme, it is worth exploring.
Published by the NHIMG editorial team on July 4, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org