Who is accountable when cloud access is not revoked after someone leaves?

Why This Matters for Security Teams

When cloud access remains active after an employee leaves, the failure is rarely one team’s mistake. It usually means HR offboarding, IAM deprovisioning, cloud entitlement cleanup, and application owners did not complete the same control chain. That gap matters because lingering access often persists in service consoles, admin roles, API tokens, and delegated permissions long after the badge is disabled.

NHI Management Group has repeatedly documented that lifecycle discipline is where identity programs break down, especially when access spans many cloud services and teams. The NHI Lifecycle Management Guide frames this as a process problem, not just an access review problem. External guidance from the OWASP Non-Human Identity Top 10 reinforces the same point: unmanaged credentials and stale entitlements become an operational risk the moment identity state changes are not propagated everywhere.

For cloud environments, accountability needs to be explicit because “someone owns it” is not a control. A departure event should trigger removal or reassignment across identity stores, cloud IAM, privileged access workflows, and application-specific permissions. In practice, many security teams encounter lingering cloud access only after an audit finding, a billing anomaly, or an incident review, rather than through intentional offboarding controls.

How It Works in Practice

Effective offboarding assigns accountability across three layers: the identity owner, the cloud platform owner, and the application or system owner. Each layer has a distinct duty. Identity teams revoke the human account and associated tokens. Cloud teams remove role bindings, service account grants, and cross-account trust. System owners clear app-local permissions that sit outside centralized IAM. If any one layer is missed, access can survive through backdoor paths such as federated roles, cached sessions, or unmanaged API keys.

Practitioners usually reduce this risk by tying offboarding to a single authoritative event and then requiring validation at each downstream system. The control should be time-bound and evidence-driven, not informal. That means confirming that:

• the HR departure event reached IAM without delay;
• cloud roles and group memberships were removed or re-assigned;
• active sessions, refresh tokens, and secrets were expired or rotated;
• application owners validated that local entitlements were removed;
• exceptions were recorded with an expiry date and a named approver.

This is where the Ultimate Guide to NHIs is useful as a practical reference for lifecycle discipline, while the 52 NHI Breaches Analysis shows how stale identity artifacts often outlive the person who created them. For policy alignment, the NIST Cybersecurity Framework 2.0 makes clear that access control is a governance responsibility, not a technical afterthought. These controls tend to break down when cloud privileges are granted outside a central identity process, because application owners can reintroduce access faster than deprovisioning workflows remove it.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance revocation speed against service continuity and account recovery needs. That tradeoff becomes visible when the departing user owns shared systems, emergency break-glass roles, or long-lived integrations that were never documented.

Current guidance suggests that accountability should shift with the access model. For standard human access, HR, IAM, and the relevant system owner are all accountable for completion. For privileged cloud access, the cloud platform owner usually needs explicit verification duties because role propagation and federation can create hidden residual access. For contractor or vendor access, procurement or vendor management may also be part of the control chain. There is no universal standard for this yet, but best practice is to name one control owner for the offboarding workflow and separate approvers for each domain.

This is also where exception handling matters. If a user leaves but a shared mailbox, automation account, or support integration must remain active, the account should be converted, re-owned, and revalidated rather than left in the departed person’s name. The Guide to the Secret Sprawl Challenge is relevant here because stale access often persists through secrets and tokens that bypass the normal user-deactivation path. For structured accountability, the right question is not just who disabled the account, but who signed off that all cloud paths were actually closed.

Related resources from NHI Mgmt Group

• Who is accountable when user access remains active after offboarding?
• Who is accountable when Jira offboarding leaves access behind?
• Who is accountable when revoked sessions keep working after access should end?
• Who is accountable when an application keeps access after a user leaves the directory?