Who should own expired certificate cleanup in identity and security programmes?

Ownership should sit with the team responsible for certificate lifecycle and trust-store hygiene, not only with the team that issued the certificate. Cleanup must be treated as a tracked operational task because expired intermediates can continue to affect validation until every copy is removed.

Why This Matters for Security Teams

Expired certificate cleanup is not a narrow housekeeping job. It is part of trust-store hygiene, service reliability, and identity risk reduction. When ownership is unclear, the issuing team may retire the certificate while a stale copy remains in a keystore, container image, load balancer, or embedded application bundle. That leaves validation paths active longer than expected and creates avoidable outages or trust failures.

Current guidance treats certificates as lifecycle assets, not one-time issuance artifacts. The same logic appears in the Ultimate Guide to NHIs, which stresses that operational cleanup matters as much as creation and rotation. The governance gap is often bigger than teams expect: only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after notification, which shows how slowly remediation can stall when ownership is diffuse.

Security teams often assume that expiry removes risk automatically, but validation chains, cached trust stores, and copied artifacts can keep the certificate effective in practice long after the date on the file has passed. In practice, many security teams encounter expired-certificate exposure only after a production failure or a trust incident has already happened, rather than through intentional lifecycle governance.

How It Works in Practice

The operational answer is to assign ownership to the team that manages certificate lifecycle and trust-store hygiene, with clear support from the platform, application, and issuing teams. That owner is responsible for discovering where the certificate or intermediate is used, confirming where trust is anchored, and removing or replacing stale copies. The NHI Lifecycle Management Guide is the right model here: issuance, distribution, rotation, revocation, and cleanup should be treated as one control loop, not separate ticket queues.

Practically, the workflow should include:

• Inventory all certificate consumers, including apps, gateways, CI/CD systems, containers, embedded appliances, and shared keystores.
• Map trust paths so expired intermediates can be removed from every trust store, not just from the issuing CA.
• Track expiry, revocation, and cleanup as separate tasks, because expiry alone does not guarantee removal.
• Use automation for discovery and validation, but keep a named operational owner for final sign-off.
• Escalate through incident management when expired certificates still appear in active validation chains.

This approach aligns with the OWASP Non-Human Identity Top 10, which treats unmanaged credentials and lifecycle failures as security defects rather than admin chores. It also fits the NHI evidence that poor rotation and weak offboarding are common failure points, especially when secrets and certificates are spread across many systems. One useful organisational signal is the NHI confidence gap documented in The State of Non-Human Identity Security: 1 in 4 organisations are investing in dedicated NHI security capabilities, with another 60% planning to do so within the next twelve months.

These controls tend to break down in container-heavy or federated environments because certificates are copied into images, sidecars, and local trust stores that outlive the original issuance record.

Common Variations and Edge Cases

Tighter certificate cleanup ownership often increases operational overhead, so organisations must balance fast remediation against the need for reliable discovery and change control. There is no universal standard for who owns every cleanup step, but best practice is evolving toward a single accountable lifecycle owner with shared execution from platform and application teams.

Edge cases matter. In managed SaaS integrations, the app owner may not control the certificate store directly, so the cleanup task sits with the platform or IAM team while the service owner validates business impact. In third-party PKI or edge appliances, the issuing team may not even have access to the runtime trust store, which means ownership must follow control of the actual validation point, not the original request. The Top 10 NHI Issues and the OWASP Non-Human Identity Top 10 both reinforce the same lesson: lifecycle controls fail when responsibility is split between teams that do not manage the real exposure surface.

Expired intermediates also deserve special attention. Even when leaf certificates are replaced, stale intermediates can remain trusted in legacy clients, embedded systems, or long-lived service meshes. That is why cleanup should be tracked as an explicit operational task with evidence of removal, not assumed from expiry dates alone. For teams managing large estates, the hardest cases are legacy systems with hidden trust stores, because the certificate can be “expired” while the trust relationship remains active.

Related resources from NHI Mgmt Group

• Who should own certificate risk in DevOps and workload identity programmes?
• Who should own machine identity and cryptographic readiness programmes?
• Who is accountable for certificate and key lifecycle failures in modern identity programmes?
• Who should own compliance decisions across identity and certificate programmes?