Subscribe to the Non-Human & AI Identity Journal

Who is accountable when an orphaned machine credential is used after decommissioning?

Accountability should sit with the service owner, platform team, and identity governance process that failed to revoke access when the workload ended. If the credential outlived the machine, the problem is lifecycle control, not just secret hygiene. Automated offboarding and entitlement revocation are the only reliable way to close that gap.

Why This Matters for Security Teams

An orphaned machine credential is rarely just a forgotten secret. It is evidence that identity lifecycle control failed when the workload was retired, repurposed, or rebuilt. That makes accountability shared across the service owner, the platform team, and the identity governance process that should have revoked access. NHI Management Group has documented how secret sprawl and weak lifecycle control create durable exposure, especially when dynamic environments outpace manual offboarding, as discussed in the Guide to the Secret Sprawl Challenge. The risk is not theoretical: once a credential survives the machine, an attacker can use it long after the original asset is gone. Current guidance from the OWASP Non-Human Identity Top 10 treats stale NHI credentials as a direct governance failure, not a narrow IAM mistake.

In practice, many security teams only discover the problem after decommissioning has already happened and the credential is still valid in pipelines, scripts, or cloud metadata stores.

How It Works in Practice

Accountability starts with the control point that should have removed the credential, but operational ownership is usually distributed. The service owner should declare the workload end-of-life, the platform team should execute shutdown and entitlement cleanup, and the identity team should verify revocation across vaults, CI/CD systems, secrets managers, and cloud roles. This is why lifecycle evidence matters as much as secret storage. A credential that remains valid after decommissioning means the offboarding workflow did not reach every place the identity was trusted.

Practitioners should map the asset to its workload identity, then confirm the revocation path completed. That includes:

  • terminating active sessions and short-lived tokens, not just deleting a record
  • revoking API keys, certificates, and service account bindings at the source of trust
  • removing references from automation, build jobs, schedulers, and config templates
  • logging who approved shutdown and who verified revocation

This is where identity governance becomes operational rather than administrative. The 2024 Non-Human Identity Security Report notes that 59.8% of organisations see value in dynamic ephemeral credentials, which is relevant because stale long-lived credentials are harder to catch and easier to reuse. For control design, NIST SP 800-63 Digital Identity Guidelines reinforces the need for lifecycle-proof identity processes rather than one-time issuance. These controls tend to break down when decommissioning is handled in tickets but credentials are embedded in automation, images, or third-party integrations.

Common Variations and Edge Cases

Tighter offboarding control often increases operational overhead, requiring organisations to balance cleanup speed against automation complexity. That tradeoff becomes visible in hybrid estates, inherited environments, and long-lived integrations where no single team owns the full path from issuance to revocation. In those cases, accountability is still shared, but the failure may sit most heavily with the team that controlled the final trust relationship, such as the platform team for cloud-native workloads or the service owner for application-managed keys.

There is no universal standard for this yet, but current guidance suggests treating orphaned machine credentials as a lifecycle exception that must be detected, escalated, and closed with evidence. A common edge case is when a workload is decommissioned but the credential remains active in a backup job or external SaaS connector. Another is when the machine is deleted, but the secret persists in a vault with an indefinite TTL. NHI Management Group research on the Ultimate Guide to NHIs shows why static secrets are structurally harder to govern than dynamic ones, and the CI/CD pipeline exploitation case study illustrates how leftover automation trust can become a persistent exposure path. In real environments, these failures are usually found during incident response or post-decommission audit, not during the original shutdown review.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-03 Orphaned creds show failed lifecycle control and rotation discipline.
NIST CSF 2.0 PR.AC-1 Revocation after workload retirement is an access control failure.
NIST AI RMF Identity lifecycle governance supports accountable, reliable system behavior.

Verify every NHI has a defined owner, TTL, and revocation path before decommissioning.