47-day TLS certificates make manual lifecycle tracking untenable

At a glance

What this is: This is an Akeyless walkthrough of certificate lifecycle management, showing why the move to 47-day TLS certificates makes manual tracking and ad hoc renewal unworkable.

Why it matters: It matters because certificate lifecycle failures now create direct outage, audit, and trust risks for teams managing workload identity, machine identity, and broader IAM operations.

By the numbers:

• Only 38% have automated certificate lifecycle management in place.
• Certificate expiry is the leading cause of outages for 45% of organisations.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• 69% of organisations now have more machine identities than human ones.

👉 Read Akeyless' walkthrough of 47-day TLS certificate lifecycle automation

Context

Public TLS certificate management is becoming a lifecycle problem, not a renewal task. When certificate lifetimes shrink to 47 days, the operational failure is no longer the cryptography itself but the inability to discover, issue, provision, renew, and revoke certificates fast enough across the estate.

For IAM, the implication is straightforward: certificate handling now sits squarely inside NHI governance and workload identity control. Teams that still depend on spreadsheets or one-off renewals are carrying the same class of risk that appears anywhere ownership, visibility, and automation do not line up.

The primary keyword here is certificate lifecycle management, and the article makes the case that continuous discovery plus automated renewal is the only survivable model as validity windows contract.

Key questions

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. That means continuous discovery, versioned renewal, provisioning that reloads the workload, and revocation of retired material. A spreadsheet can record intent, but it cannot execute lifecycle controls across a distributed estate. The practical goal is to make certificate replacement routine before expiry becomes an incident.

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. Each renewal, provisioning, and reload step creates a chance for outage or audit failure. That is why certificate governance now belongs inside broader NHI and workload identity programs, not in ad hoc infrastructure checklists.

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. As certificate counts grow and validity periods shrink, that model fails first through missed renewals, then through service interruption, and finally through poor audit evidence. Continuous automation is the only durable control.

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.

Technical breakdown

Why shortening TLS certificate lifetimes changes the operating model

A public TLS certificate is not a static asset once lifetimes fall from years to weeks. Shorter validity increases the number of renewal events, which raises the probability of missed expiry, failed automation, and service interruption. It also shifts the control objective from occasional maintenance to continuous lifecycle execution. In practice, certificate lifecycle management must treat discovery, issuance, provisioning, renewal, versioning, and revocation as one chain, because any break in that chain can take a workload out of trust. The issue is not that renewal becomes more frequent. The issue is that manual workflows become structurally unable to keep pace.

Practical implication: move certificate operations out of spreadsheets and into a governed lifecycle workflow before renewal cadence becomes unmanageable.

Certificate discovery and inventory for machine identities

Discovery is the entry point because you cannot renew or revoke what you cannot see. In machine identity estates, certificates often live on servers, load balancers, containers, and internal services with weak ownership and inconsistent documentation. Discovery tools scan hosts, ports, and DNS names to build a certificate inventory, including unmanaged and self-signed certificates that would otherwise remain invisible until they fail. That inventory matters for trust, but it is only the starting point. Without ownership, expiry data, and replacement paths, visibility does not reduce risk. It simply exposes how much work still remains.

Practical implication: run continuous discovery against every environment where TLS is terminated, then tie each certificate to an owner and renewal path.

Renewal, versioning, and revocation as one control sequence

Renewal is only safe when it creates a new version, provisions that version, and preserves the ability to roll back or revoke the prior one without breaking service. That sequence matters because certificate replacement is not complete at issuance. The live workload must actually load the new material, and the retired version must be revoked once the replacement is confirmed. In a short-lifetime model, this is the real control boundary. Certificates should move through versioned state changes with auditability, not through ad hoc overwrites that obscure what is live and what has been retired.

Practical implication: require version-aware renewal and revocation so certificate replacement can happen without outage or audit gaps.

Threat narrative

Attacker objective: To force a trust failure or outage by exploiting unmanaged certificate lifecycle operations rather than by attacking the cryptography directly.

1. entry: the operational entry point is an unmanaged or self-signed certificate already present on a workload, which gives the organisation a trust asset it has not properly inventoried.
2. credential_harvested: the failure condition is not theft but missed ownership, where expiry and replacement data are not tied to a governed lifecycle process.
3. escalation: once the renewal window is missed, the certificate problem expands into service outage, failed audit evidence, and emergency manual intervention across the estate.
4. impact: the attacker objective is not central compromise but trust disruption, where certificate expiry or mismanagement takes production services offline or leaves them unverifiable.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Manual certificate tracking is the exact failure mode this transition exposes. Spreadsheets, one-off renewals, and local knowledge were designed for low-frequency maintenance, not for dozens of renewal events per certificate per year across a distributed estate. That assumption fails when workloads span cloud, Kubernetes, load balancers, and internal services. The implication is that governance must move from human memory to automated lifecycle state.

Identity blast radius: short-lived certificates reduce cryptographic exposure but increase operational exposure. The shorter lifetime narrows the abuse window for a compromised certificate, yet it also magnifies the cost of any missed renewal or broken provisioning path. This is the trade-off practitioners need to recognise. The implication is that resilience now depends on the weakest certificate workflow, not on the certificate format itself.

The certificate problem is a broader NHI visibility problem in disguise. Machine identity inventories are already larger than human identity inventories in many environments, and certificate estates grow inside that sprawl. The governance question is no longer whether a certificate is trusted, but whether the organisation can continuously prove where it lives, who owns it, and how it will be replaced. Practitioners should align certificate governance with the wider NHI lifecycle model.

47-day TLS is a forcing function for lifecycle maturity. The organisations that survive this shift will not be the ones with the best manual runbooks. They will be the ones that can discover, version, revoke, and audit machine identities as a repeatable control system. The implication is clear: certificate operations are becoming a benchmark for overall identity governance maturity.

From our research:

• 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.
• For a broader lifecycle lens, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that apply beyond certificates.

What this signals

Certificate lifecycle is becoming the clearest test of NHI maturity. With 57% of organisations lacking a complete inventory of their machine identities, the first failure is usually visibility, not cryptography. Teams that cannot enumerate certificates cannot enforce renewal discipline, and the result is avoidable operational debt.

The practical signal for readers is whether certificate operations already sit inside the same governance path as workload identity, secrets, and other machine identities. If they do not, the organisation is likely to discover that its renewal model was built for human-paced change, not machine-scale lifecycle.

Identity blast radius is the right concept for the 47-day era. Shorter certificate validity narrows abuse windows but expands the consequences of workflow failure, which is why lifecycle automation now matters more than isolated renewal tools. If your programme still depends on manual handoffs, the next expiry cycle is already a governance event.

For practitioners

• 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. Treat unmanaged and self-signed certificates as priority inventory gaps, not cleanup tasks.
• 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.
• Test revocation and rollback before expiry pressure hits Validate that revoking a retired certificate does not take the active endpoint down, and confirm the CRL or equivalent status path updates as expected.

Key takeaways

• The 47-day certificate era turns certificate management into a continuous identity governance problem, not a periodic maintenance task.
• The main risk is operational failure, because expired or misprovisioned certificates can now trigger outages faster than manual teams can respond.
• Automated discovery, versioned renewal, and controlled revocation are the controls that separate manageable estates from recurring trust incidents.

Key terms

• Certificate Lifecycle Management: Certificate Lifecycle Management is the governed process of discovering, issuing, provisioning, renewing, versioning, and revoking certificates across an estate. It turns certificates from manually tracked files into controlled machine identities with ownership, auditability, and predictable replacement paths.
• Machine Identity: A machine identity is any non-human credential or trust artifact used by a workload, service, or system to authenticate and communicate. In certificate programs, that identity is expressed through issuance, expiry, rotation, and revocation rather than through user login flows.
• 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.
• Versioned Renewal: Versioned renewal creates a new certificate version instead of overwriting the old one, so teams can track what is live, what is retired, and what can be rolled back. For workload identities, versioning is the difference between controlled rotation and blind replacement.

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

👉 The full Akeyless post includes the live demo commands, version history, and revocation checks.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance in your organisation, it is worth exploring.