TL;DR: Public TLS certificate lifetimes are being reduced from 398 days to 47 days by 2029, turning manual tracking into an operational and audit risk, according to Akeyless and the CA/Browser Forum. The shift makes automated certificate discovery, issuance, renewal, provisioning, and revocation the only sustainable model for identity teams.
NHIMG editorial — based on content published by Akeyless: the 47-day TLS certificate lifecycle walkthrough
By the numbers:
- Only 38% have automated certificate lifecycle management in place.
- Certificate expiry is the leading cause of outages for 45% of organisations.
- 69% of organisations now have more machine identities than human ones.
Questions worth separating out
Q: How should teams manage TLS certificates when renewal windows shrink to weeks?
A: Teams should treat TLS certificates as governed identities, not static files.
Q: Why do short-lived certificates create more operational risk for IAM teams?
A: Short-lived certificates reduce the abuse window for a compromised certificate, but they multiply the number of lifecycle events that can fail.
Q: What breaks when certificate lifecycle management is still manual?
A: Manual lifecycle management breaks at scale because it depends on people noticing expiry, remembering renewal steps, and pushing the replacement in time.
Practitioner guidance
- Automate continuous certificate discovery Scan hosts, ports, and DNS names on a recurring basis, then bind each discovered certificate to an owner, expiry date, and replacement path.
- Replace spreadsheet tracking with lifecycle state management Track certificates through discover, issue, provision, renew, version, and revoke states so teams can see exactly what is live, what is retired, and what still needs action.
- Require service reloads as part of provisioning Make post-provision certificate reloads mandatory so the workload actually serves the new certificate instead of leaving the renewed material on disk unused.
What's in the full article
Akeyless' full walkthrough covers the operational detail this post intentionally leaves for the source:
- Step-by-step Terraform setup for the NGINX target and Akeyless Gateway lab environment
- Exact command sequence for discovery, provisioning, renewal, and revocation against a live workload
- Console views showing certificate versions, CRL publication, and status changes after revocation
- Lab runbook and teardown steps for practitioners who want to reproduce the lifecycle flow
👉 Read Akeyless' walkthrough of 47-day TLS certificate lifecycle automation →
47-day TLS certificates: what does this mean for CLM teams?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
Certificate lifecycle management is now machine identity governance, not PKI housekeeping. When certificate validity contracts to 47 days, the control problem shifts from periodic administration to continuous identity operations. The same visibility, ownership, and rotation gaps that affect service accounts now apply to TLS certificates at scale. Practitioners should treat CLM as part of the machine identity program, not a standalone infrastructure task.
A few things that frame the scale:
- Only 38% have automated certificate lifecycle management in place, according to The Critical Gaps in Machine Identity Management report.
- 59% of companies face greater difficulties auditing machine identities, primarily due to lack of clear ownership and limited visibility.
A question worth separating out:
Q: Who is accountable when a certificate expires and takes a service down?
A: Accountability sits with the team that owns the certificate lifecycle, not just the system administrator who happens to touch the host. Governance frameworks expect ownership, visibility, and auditable control over machine identities. If those responsibilities are unclear, the organisation will learn too late that no one truly owned the renewal path.
👉 Read our full editorial: 47-day TLS certificates make manual lifecycle tracking untenable