What should teams do when a certificate is nearing expiry?

Why This Matters for Security Teams

Certificate expiry is not just a housekeeping issue. It is a control failure that can interrupt trust between services, break external integrations, and expose brittle recovery paths. For machine identities, expiry often collides with unclear ownership, poor inventory, and manual renewal steps, which is why NHI Management Group highlights lifecycle management as a core risk area in its NHI Lifecycle Management Guide. Industry reporting also shows that certificate expiry is the leading cause of outages for 45% of organisations in SailPoint’s Critical Gaps in Machine Identity Management report.

For security teams, the practical issue is not whether a certificate can be renewed, but whether the renewal path is tied to the owning service, the dependency chain, and the fallback plan if renewal fails. The OWASP Non-Human Identity Top 10 treats weak lifecycle control as a major NHI risk because expired or unmanaged credentials can create both availability and trust failures. In practice, many security teams encounter expiry only after a service outage has already started, rather than through intentional lifecycle governance.

How It Works in Practice

The correct response starts with ownership, not reminders. Every certificate should be mapped to a service owner, a dependency owner, and an escalation path. When a certificate enters its renewal window, the team should verify whether the service can renew automatically, whether the new certificate can be deployed without interruption, and whether the change requires coordination with external parties. Current guidance suggests treating this as a workflow problem, not a calendar problem.

Operationally, that means:

• Inventory the certificate, its issuing authority, and every consumer that trusts it.
• Classify the certificate by blast radius: internal-only, customer-facing, or critical infrastructure.
• Use automated renewal where possible, with short validation steps before replacement.
• Require JIT approval or change control only when the service cannot safely renew in place.
• Verify fallback behaviour, including rollback, alternate endpoints, or temporary trust bridges.

This is also where machine identity governance matters. NHI Mgmt Group’s Ultimate Guide to NHIs in lifecycle processes stresses that renewal, rotation, and offboarding must be part of the same control plane. That aligns with the OWASP Non-Human Identity Top 10, which frames unmanaged machine credentials as a recurring exposure. If the organisation already uses workload identity patterns, renewal should be tied to the identity issuing process rather than to a human ticket queue.

Teams should also distinguish dynamic credentials from long-lived static ones. A certificate that supports a short-lived workload can usually be rolled automatically, while a certificate embedded in legacy middleware may require staged deployment and explicit verification. These controls tend to break down when ownership is shared across multiple platform teams because no single group is accountable for the final trust cutover.

Common Variations and Edge Cases

Tighter certificate controls often increase operational overhead, requiring organisations to balance resilience against deployment complexity. That tradeoff becomes sharper in hybrid environments, where certificates may terminate at load balancers, service meshes, API gateways, or third-party integrations. Best practice is evolving, but the current consensus is that the renewal process should follow the service dependency, not the certificate’s technical location.

Some certificates can be renewed automatically with no user impact. Others support external trust, such as partner connections or public-facing APIs, where expiry requires coordination with external systems that cannot be updated instantly. In those cases, teams should use documented overlap windows so both old and new certificates are accepted long enough to complete trust propagation. The Top 10 NHI Issues resource is useful here because it highlights how visibility gaps and weak ownership routinely undermine lifecycle execution.

There is no universal standard for certificate lead time across every environment. Highly regulated or safety-critical services may need renewal verification well before expiry, while lower-risk internal services may tolerate a narrower window if automation is reliable. The key is to define a fallback before the certificate reaches the deadline, not after. If the service cannot survive a missed renewal, the renewal process is already too late.

Related resources from NHI Mgmt Group

• How should teams reduce the risk of orphaned service accounts and stale tokens?
• How should teams govern certificate expiry across large service estates?
• How should security teams manage SSL certificate expiry before it causes outages?
• How should security teams govern FIDO2 credentials across their lifecycle?