Who is accountable when a departed user or service account still has access?

Why This Matters for Security Teams

When a departed user or service account still has access, the issue is not just cleanup. It is a governance failure across identity ownership, system ownership, and offboarding workflow design. That gap allows stale access to persist in directories, SaaS apps, cloud control planes, and secrets stores long after employment or service ownership has ended. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which makes lingering access a common operational risk.

This matters because residual access is often discovered only after an incident review, not during a planned review cycle. The Ultimate Guide to NHIs shows how frequently secrets and service accounts stay active far beyond intended use, while the OWASP Non-Human Identity Top 10 treats weak lifecycle control as a recurring exposure pattern. In practice, many security teams encounter unrevoked access only after a former owner leaves, a contractor ends, or a service is decommissioned and no one can prove who was responsible for disabling it.

How It Works in Practice

Accountability should be explicit across three roles: the identity owner, who is responsible for the account’s purpose and legitimate use; the system owner, who controls the application, environment, or secret store; and the process owner, who ensures offboarding and revocation actually happen. If any one of these roles is missing, access can survive because no one has both the authority and the operational mandate to remove it. This is especially important for NHIs, where service accounts, API keys, certificates, and automation tokens often outlive the people who created them.

Practical offboarding usually needs a defined chain of actions:

• Confirm the identity’s business purpose and owner.
• Revoke active sessions, tokens, API keys, and certificates.
• Remove entitlements from IAM, cloud, CI/CD, and SaaS platforms.
• Rotate downstream secrets that may have been exposed through the departed identity.
• Record who approved the revocation and who validated completion.

Current guidance suggests tying this to joiner-mover-leaver workflows, but for NHIs the better control is asset-level inventory plus lifecycle state tracking. The Ultimate Guide to NHIs — Key Challenges and Risks highlights how visibility gaps make it difficult to know which service accounts still exist, while standards work such as the OWASP Non-Human Identity Top 10 reinforces that lifecycle control is part of access control, not a separate housekeeping task. In environments with multiple directories, delegated admin teams, and unmanaged secrets stores, this guidance breaks down because no single system of record can enforce revocation end to end.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance rapid revocation against the risk of breaking dependent workloads. That tradeoff is real when a departed user still owns an automation chain, or when a service account is shared across jobs and integrations.

There is no universal standard for this yet, but best practice is evolving toward time-bound access, named ownership, and documented exception handling. For shared service accounts, the real accountability question becomes who approved the sharing model and who owns replacement planning. For machine identities embedded in CI/CD, the process owner may be the platform team, while the system owner remains responsible for rotation and retirement. The 52 NHI Breaches Analysis shows that over-retained access and poor offboarding are repeated themes in compromise paths, not one-off mistakes. The most reliable control is a documented owner for every identity, plus a mandated review date that forces closure before a departure becomes an exposure.

Related resources from NHI Mgmt Group

• Who is accountable when a service account or AI agent keeps access after offboarding?
• Who is accountable when a contractor still has privileged cloud access after departure?
• Who is accountable when a device still has access after administrators believe it has been revoked?
• When do service accounts become a higher risk than ordinary user accounts?