Who is accountable when a non-human identity is never offboarded?

Why This Matters for Security Teams

Un-offboarded non-human identities are not just housekeeping failures. They are standing access paths that survive team changes, application rewrites, and incident response windows. Once a service account, API key, or workload token is left active without ownership, it becomes impossible to prove who can still use it or why it exists. That undermines accountability, auditability, and recovery, which are core expectations in the NIST Cybersecurity Framework 2.0.

NHI Management Group research shows the scale of the problem: only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after the target organisation is notified. Those gaps turn “temporary” access into long-lived exposure, especially when the credential has no clear business owner. The operational risk is usually discovered during cleanup after an incident, not during design, which means the organisation is already reacting to a privilege that should never have remained active. See also the Ultimate Guide to NHIs and Top 10 NHI Issues.

How It Works in Practice

Accountability for an NHI that was never offboarded should follow the same lifecycle logic as any other identity: creation, assignment, review, rotation, deactivation, and revocation. The owning engineering or platform team is accountable for the identity’s business purpose and retirement, while IAM and security define the control model, logging, and enforcement. That division matters because technical administration is not the same as ownership.

In practice, organisations should require each NHI to have a named owner, a documented purpose, an expiry or review date, and a revocation path. The controls should be tied to inventory and change management so that credentials are not left active after a service is deleted, a pipeline is retired, or an application is replaced. The Lifecycle Processes for Managing NHIs guidance is useful here because offboarding is not a single event; it is the final step in a governed lifecycle. NIST also frames this as a governance and continuous monitoring issue in CSF 2.0, where accountability must be traceable to a role, not just a system.

• Map each NHI to an owning team, system, and approver.
• Set revocation triggers for service retirement, role change, and incident response.
• Review orphaned credentials against logs, vault records, and deployment pipelines.
• Escalate unresolved ownership as a governance exception, not a technical ticket.

These controls tend to break down when credentials are embedded in CI/CD tooling or code repositories, because ownership becomes distributed across delivery chains rather than a single system record.

Common Variations and Edge Cases

Tighter offboarding control often increases operational overhead, requiring organisations to balance fast delivery against stronger identity hygiene. That tradeoff is real, especially for platform teams managing ephemeral workloads, shared build systems, or third-party integrations. Current guidance suggests that the answer is not to weaken ownership requirements, but to make them lighter-weight and automated wherever possible.

Some NHIs are intentionally long-lived, such as infrastructure service accounts or vendor integrations, but they still need explicit ownership, periodic review, and a retirement trigger. In shared-service environments, accountability may sit with a platform team while application teams remain responsible for the credentials they request. Where there is no consensus yet is the exact review cadence for every category of NHI; best practice is evolving, so organisations should align review frequency to risk, privilege, and blast radius rather than use one universal interval.

This is why lifecycle governance is critical. The Ultimate Guide to NHIs shows that NHIs outnumber human identities by 25x to 50x in modern enterprises, which means orphaned credentials scale faster than manual review processes can handle. In practice, teams get into trouble when they rely on informal knowledge of “who owns that key” instead of a tracked offboarding workflow tied to revocation evidence.

Related resources from NHI Mgmt Group

• Who is accountable when a non-human identity is over-privileged?
• Who is accountable when an inactive non-human identity is still present after business use has ended?
• Who is accountable when a privileged non-human identity causes a security incident?
• Who is accountable when a non-human identity deletes production data through a valid token?