Who should be accountable for certificate revocation when services are retired?

Why This Matters for Security Teams

Certificate revocation after service retirement is not just housekeeping. It is the moment a trust relationship should be formally ended, because a valid certificate can continue to authenticate something that no longer exists in production. That creates residual trust, audit blind spots, and a path for misuse if DNS, load balancers, or stale automation still recognize the old identity. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, a warning sign for adjacent identity lifecycles such as certificates. The governance issue is simple: the team that owns the service understands when the trust relationship should end, while a generic platform function often sees only the mechanism, not the business context. That distinction matters for both risk reduction and accountability mapping under the NIST Cybersecurity Framework 2.0. In practice, many security teams discover stale certificates only after retirement work has already finished, rather than through intentional offboarding.

How It Works in Practice

Accountability should be assigned to the service owner, with the platform or PKI team acting as the executor of a controlled process. The service owner knows the retirement date, the consuming systems, and whether any adjacent dependencies still require a temporary trust bridge. The platform team usually manages the technical revocation action, but it should not own the decision to revoke unless it also owns the service.

A practical revocation workflow usually includes:

• Service owner confirms end-of-life and identifies all certificate instances tied to the workload.
• PKI or platform operations revokes the certificate, removes it from trust stores, and verifies CRL or OCSP propagation.
• Infrastructure owners remove references from load balancers, service meshes, CI/CD jobs, secrets stores, and backup automation.
• Security or risk functions verify evidence of completion and retain an audit trail.

This division of labour aligns with the broader machine identity patterns described in The Critical Gaps in Machine Identity Management report, especially where ownership gaps and manual tracking are common. It also reflects the identity governance model in NIST CSF 2.0, where asset, identity, and recovery responsibilities must be explicit. When certificate retirement is tied to service decommissioning, revocation should be part of the shutdown checklist, not a separate afterthought. These controls tend to break down when ownership is split across cloud, application, and infrastructure teams because no single team sees the full trust chain.

Common Variations and Edge Cases

Tighter revocation controls often increase coordination overhead, requiring organisations to balance faster shutdowns against the risk of breaking dependent services too early. That tradeoff is real in environments with external partners, embedded devices, or long-lived batch integrations where immediate revocation can interrupt legitimate traffic.

Current guidance suggests a few common exceptions. For example, if a platform team operates a shared certificate authority, it may execute revocation on behalf of service owners, but the service owner should still remain accountable for the retirement decision. In regulated environments, some organisations require dual approval from service and security teams before revocation is finalized. Where certificates are embedded in edge devices or unmanaged appliances, the offboarding process may need a compensating control such as network isolation, because revocation alone may not be enough if the device cannot check status reliably.

The Sisense breach is a reminder that machine trust and secrets lifecycles can become material security issues when ownership is unclear. Best practice is evolving, but the most defensible model remains clear service ownership, delegated technical execution, and documented evidence that certificate trust has actually been removed.

Related resources from NHI Mgmt Group

• Who is accountable when a certificate expires and enables a breach?
• Who should be accountable for certificate trust decisions across identity programmes?
• Who is accountable when prolonged internet pressure disrupts identity-dependent services?
• Who is accountable for quantum readiness in financial services?