Who should be accountable for machine identity offboarding?

Accountability should sit with the system or application owner, with identity operations enforcing the control. If no one owns retirement, service accounts and keys outlive the process that created them and continue to expand the attack surface long after their use case ends.

Why This Matters for Security Teams

Offboarding machine identities is not a clerical cleanup task. It is the control that determines whether a retired application, pipeline, or integration keeps holding valid access long after ownership has shifted or disappeared. When accountability is unclear, secrets remain valid, service accounts linger in vaults, and access reviews become a paper exercise instead of a lifecycle control. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why retirement gaps persist even in mature environments.

This is a governance problem, not just an IAM problem. The system or application owner is best positioned to confirm when a workload is no longer needed, while identity operations can enforce revocation, disablement, and audit logging. That split matters because machine identities often outlive deployment teams, ticket queues, and even the systems that created them. Current guidance aligns with the NIST Cybersecurity Framework 2.0 emphasis on ownership, access control, and continuous risk management. In practice, many security teams discover stale service accounts only after an incident review exposes them as quietly active long after application retirement.

How It Works in Practice

Operational accountability should follow the machine identity lifecycle, not the infrastructure team chart. The application owner should be responsible for declaring end of life, validating downstream dependencies, and approving decommissioning. Identity operations should execute the control set: revoke tokens, disable service accounts, rotate or destroy keys, remove vault entries, and confirm that automation no longer authenticates with the retired identity. This aligns with the lifecycle framing in NHI Lifecycle Management Guide, where offboarding is treated as a defined stage rather than an afterthought.

In practice, strong offboarding usually includes:

• an owner field that maps each NHI to a named application or system custodian
• a retirement trigger tied to change management, service catalog closure, or CI/CD decommissioning
• automated revocation for API keys, certificates, OAuth clients, and service account credentials
• evidence capture showing when access was removed and where lingering dependencies were found

Security teams should also require periodic reviews of dormant identities, because offboarding often fails when asset inventories and secret stores are disconnected. The threat is not theoretical. The 52 NHI Breaches Analysis and the NHI Mgmt Group research corpus repeatedly show that weak lifecycle control turns a retired integration into a standing attack path. The best practice is evolving toward automated deprovisioning tied to workload identity signals, but there is no universal standard for this yet. These controls tend to break down in sprawling microservice environments where one application uses dozens of shared identities and no single team can prove which credential is still in production.

Common Variations and Edge Cases

Tighter offboarding control often increases coordination overhead, requiring organisations to balance revocation speed against the risk of breaking live dependencies. That tradeoff is most visible in shared service accounts, legacy batch jobs, and third-party integrations, where the wrong removal sequence can interrupt business processes. In those cases, best practice is to assign accountability to the system owner for business confirmation while requiring identity operations to enforce a controlled, auditable shutdown window.

There are a few edge cases where responsibility can be shared more explicitly. For vendor-managed workloads, the internal business owner still owns the risk, even if a supplier performs the technical cleanup. For platform-native identities, such as CI/CD runners or managed cloud roles, the platform team may execute the offboarding steps, but the consuming service owner should approve the retirement. Where multiple teams share one identity, current guidance suggests breaking that pattern as part of remediation, because shared credentials make it impossible to prove which workload still needs access. The issue is consistent with the broader NHI risk patterns highlighted by NHI Mgmt Group and the control expectations in NIST Cybersecurity Framework 2.0 and Top 10 NHI Issues.

Where organisations lack an owner-of-record model, offboarding becomes a no-owner exception queue and secrets survive indefinitely. That is usually the point where identity hygiene stops being preventive and starts being forensic.

Related resources from NHI Mgmt Group

• How can organisations reduce the risk of stale API keys and machine tokens?
• Who is accountable when a machine identity exposes cardholder data?
• Who should be accountable for machine identity assets that have no clear owner?
• Who is accountable when machine identity controls fail in critical infrastructure?