Certificate expiry is becoming a zero-touch identity problem

At a glance

What this is: This is an analysis of why certificate automation fails when renewal is treated as the finish line instead of part of a full lifecycle.

Why it matters: It matters because certificate operations are a machine identity governance problem, and identity teams need visibility into issuance, deployment, reload, and client-side verification, not just expiry dates.

By the numbers:

• 72% of organisations had at least one certificate outage in the previous 12 months.
• Only 38% have automated certificate lifecycle management in place.

👉 Read Infisical's analysis of certificate automation and expiry outages

Context

Certificate management is an identity lifecycle problem, not just an operations task. When a certificate renews but the service does not reload, the file on disk and the certificate presented to clients diverge, and the outage appears only when the old in-memory certificate expires. That failure mode becomes more severe as public TLS lifetimes shorten.

For NHI programmes, the lesson is simple: issuance, deployment, verification, ownership, and alerting must be governed as one workflow. If any step still depends on a person or a hand-rolled script, the control is fragile even when the renewal job itself looks successful.

Key questions

Q: What breaks when certificate renewal does not trigger a service reload?

A: The service keeps serving the certificate it loaded into memory, even if a new file exists on disk. That means renewal can report success while clients still receive an expired certificate. The failure is invisible if monitoring watches the job instead of the live endpoint, so the outage appears only when the old in-memory certificate expires.

Q: Why do short-lived certificates matter for machine identity governance?

A: Short-lived certificates matter because they are time-bound non-human credentials that define how systems prove identity to each other. When the validity period shrinks, certificate lifecycle becomes a continuous governance issue rather than a periodic maintenance task. That forces identity teams to manage issuance, renewal, and revocation with the same discipline they apply to other privileged credentials.

Q: What do teams get wrong about certificate automation?

A: They often treat it as a convenience upgrade instead of a resilience control. Automation is valuable because it shortens the gap between discovery and action, which is where outages and compliance failures begin. If the programme does not include policy, ownership, and alerting, the organisation still depends on manual intervention at the worst possible moment.

Q: How should organisations decide when to centralise certificate operations?

A: Centralise when certificate ownership is fragmented, validation credentials are spread across many hosts, or no one can confidently inventory what exists and when it expires. At that point, distributed manual handling is already the risk. A central lifecycle control plane gives you a single place to enforce policy and detect failure.

Technical breakdown

Why certificate renewal and service reload are separate controls

Renewal writes a new certificate to storage, but many services keep serving the old certificate until they are reloaded. nginx is a good example: it reads the certificate into memory at startup and will continue to use that copy even after the file on disk is replaced. The protocol or script that reissues the certificate does not automatically update the running process, so operational success can coexist with client-visible failure. That separation is the core reason expiry outages persist in mature environments.

Practical implication: Treat reload as a required control, not an optional post-step, and verify the certificate clients actually receive after each renewal.

How ACME changes machine identity lifecycle management

ACME automates certificate issuance by letting a client prove domain control to a CA, request a certificate, and renew it without a human in the loop. The protocol does not handle deployment or service reload, which means the identity lifecycle still has local operating steps outside the exchange itself. In practice, ACME reduces the manual burden only when it is paired with hooks, inventory, and monitoring that confirm the issued certificate is the one being served.

Practical implication: Use ACME for issuance, then connect it to deployment hooks and external validation so the lifecycle completes end to end.

Why shrinking certificate lifetimes expose hidden ownership gaps

As certificate validity windows shrink from months to weeks, every weak link in the workflow gets exercised more often. That makes ownership, validation method selection, DNS credential scope, and inventory quality part of the security model rather than administrative details. A certificate process that survives occasional manual intervention will not survive frequent reissuance across large fleets, especially when domain validation reuse windows also narrow.

Practical implication: Map each certificate to an owner, validation path, and deployment path before the next renewal interval gets shorter.

Threat narrative

Attacker objective: The impact is availability loss, whether the trigger is an expired certificate, a missed reload, or a silent renewal failure.

1. Entry occurs through a certificate lifecycle that renews successfully but never triggers a service reload, so the running process keeps using an expired in-memory certificate.
2. Escalation appears when monitoring watches the renewal job instead of the served endpoint, allowing stale certificate state to persist unnoticed across the fleet.
3. Impact follows when clients reach the service and receive an expired certificate, causing authentication failures and service outage.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

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 expiry is not a renewal problem, it is a lifecycle governance problem. Renewal can succeed while deployment, reload, and external verification fail, which means the identity control plane and the runtime service plane are no longer aligned. That gap is exactly why mature teams still suffer outages, and it is the point where ownership must extend beyond the CA interaction.

Hidden in-memory certificates create a runtime identity blind spot. The file on disk can be fresh while the process continues to serve an expired copy from memory. That makes endpoint validation and service reload verification part of certificate governance, not just ops hygiene, and practitioners should treat the served certificate as the authoritative state.

Public certificate lifetimes are forcing machine identity programmes toward zero-touch operation. When validity windows drop to 200 days, then 100 days, then 47 days, periodic human intervention stops scaling. The practical result is that teams need inventory, renewal, deployment, and alerting to behave as one governed machine identity workflow, or they will repeatedly rediscover the same outage class.

Manual certificate handling now produces trust debt. Each exception, missing hook, or unowned certificate creates a future outage obligation that accumulates silently until expiry forces it into production. The category is moving toward machine identity governance by necessity, and practitioners who still separate renewal from runtime verification are carrying avoidable risk.

What fails here is the assumption that renewal is the control. Renewal was designed for a condition where the certificate lifecycle ended at reissuance. That assumption fails when the actor is a workload identity embedded in a service, because the served certificate and the stored certificate can diverge after renewal. The implication is that certificate ownership must include runtime state, not just issuance state.

From our research:

• Only 38% have automated certificate lifecycle management in place, according to The Critical Gaps in Machine Identity Management report.
• 57% of organisations lack a complete inventory of their machine identities, which means many certificate estates remain partially invisible.
• That same lifecycle gap is why the NHI Lifecycle Management Guide matters for teams moving from renewal scripts to governed identity operations.

What this signals

Certificate automation is now a governance baseline, not a maturity badge. As certificate lifetimes keep shrinking, any team that still separates renewal from runtime verification will accumulate avoidable outage risk. The practical shift is toward inventory-led lifecycle control, where the served certificate, ownership, and reload state are all observable and enforced.

A useful named concept here is runtime certificate drift: the gap between what was renewed and what the service is actually presenting to clients. That drift is what converts a successful job into an outage, and it is the control gap practitioners need to eliminate across both public and private CA estates.

For practitioners

• Verify the served certificate, not just the renewed file Probe the live endpoint from outside the host and compare the certificate clients receive with the one written to disk after every renewal cycle. A successful renewal job is not evidence that the service picked up the change.
• Attach a reload hook to every renewal path Make service reload part of the same workflow that renews the certificate, whether you use certbot hooks, a controller, or a deployment agent. If the process does not reload after replacement, the old certificate can remain active until expiry.
• Inventory certificate ownership and validation method Record which team owns each certificate, whether it uses HTTP-01, DNS-01, or another validation path, and which credential can complete that validation. Ownership and challenge scope should be visible before the next renewal window arrives.
• Scope DNS credentials to validation only If DNS-01 is required, restrict the API token to the smallest possible zone or delegate _acme-challenge to a dedicated validation zone so the credential cannot modify unrelated records. Narrow scope reduces the blast radius if the token is exposed.
• Move high-volume estates to zero-touch lifecycle automation When hosts, certificates, or renewal cycles become too numerous for safe manual oversight, shift issuance, deployment, and alerting into a governed automation path. This is especially important when certificate validity windows keep shrinking.

Key takeaways

• Certificate outages usually come from lifecycle gaps, not from the absence of renewal logic.
• Shorter TLS validity windows make manual handling structurally unsustainable for machine identity estates.
• Teams need runtime verification, reload hooks, and ownership clarity before certificate lifetimes shrink further.

Key terms

• Machine identity lifecycle: Machine identity lifecycle is the full governance process for a non-human identity from creation to retirement. It includes provisioning, access scoping, rotation, renewal, offboarding, and auditability, and it fails when any one of those steps is handled manually or inconsistently.
• Certificate Drift: Certificate drift is the divergence between the certificate state an organisation believes it has and the state actually present in production. It usually appears when ownership, renewal, or validation processes are fragmented, and it increases the chance of outages, missed remediation, and audit failure.
• ACME: ACME is a protocol used to automate certificate issuance and renewal between a client and a certificate authority. For practitioners, it reduces manual renewal work, but it also introduces a dependency on correct client configuration, credential handling, and monitoring of the automation path.
• Domain Validation Reuse: Domain validation reuse is the period during which a certificate authority can accept a prior proof that an organisation controls a domain. When that window shrinks, proof of control must be repeated more often, which increases the need for automated validation and tighter credential scope.

What's in the full article

Infisical's full article covers the operational detail this post intentionally leaves for the source:

• The ACME and cert-manager configuration patterns used to automate issuance across Linux, Kubernetes, and private CA environments.
• The practical differences between HTTP-01, DNS-01, and TLS-ALPN-01 validation when infrastructure constraints change.
• The exact renewal hook patterns that reload nginx, HAProxy, or Apache after certificate replacement.
• The end-to-end workflow for centralising certificate profiles, inventory, and expiry alerting across a fleet.

👉 Infisical's full article covers ACME flows, validation choices, and reload hooks in implementation detail.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management 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 NHI governance programme, it is worth exploring.