Who should be accountable for cleaning up inactive identities across cloud platforms?

Why Inactive Identity Cleanup Becomes an Ownership Problem

Cleaning up inactive identities is not just an administration task. It sits at the intersection of access governance, cloud control ownership, and business continuity because stale accounts can survive long after the original user, service, or workload has changed. If no team is explicitly accountable, inactivity signals are noticed too late, exceptions are left open, and nobody is compelled to prove that the access is still required. NIST SP 800-53 Rev. 5 is useful here because it treats account management and access review as control responsibilities, not informal housekeeping. NIST SP 800-53 Rev 5 Security and Privacy Controls

In practice, many security teams encounter stale cloud identities only after an audit, a privilege review, or an incident has already exposed how long the access had remained untouched.

How Shared Accountability Works Across Cloud Platforms

For cloud identity cleanup, accountability should be divided by decision and execution, not by vague responsibility. Identity teams usually own the governance standard: what counts as inactive, how long inactivity can persist, how exceptions are approved, and how evidence is retained. Cloud security or cloud platform teams typically own the technical control layer: the scanners, reports, alerts, and enforcement paths that surface inactivity across tenants, subscriptions, projects, and accounts. Application and workload owners then own the business judgement: whether a dormant human account, role, token, or service identity is still needed for a system, a migration, a break-glass scenario, or a scheduled process.

That split matters because no single team can reliably answer both the access-risk question and the business-need question. Identity teams can see the policy, but they may not know whether a quiet account still supports a production job. Platform teams can automate detection, but they may not be able to approve removal when the identity is tied to a critical dependency. The right model is therefore a named owner for review, a named approver for exceptions, and a named remediation team for disablement or deletion.

• Identity governance defines inactivity thresholds and review cadence.
• Cloud security finds inactive identities across providers and centralises reporting.
• Application owners validate whether access is still required.
• Platform teams execute disablement, rotation, or removal where tooling allows.

Where this breaks down is in highly federated environments, because shared responsibility can become shared inaction if the organisation does not assign one accountable owner for the final decision.

When Cleanup Ownership Gets Messy in Real Cloud Environments

Tighter identity cleanup often increases coordination overhead, requiring organisations to balance faster removal against the risk of breaking legitimate access. The hardest cases are not ordinary human logins but service accounts, cross-account roles, temporary vendor access, and identities owned by another business unit. Those cases often create uncertainty about who can safely revoke access, especially when the identity is technically visible in one platform but operationally owned somewhere else.

There is also a genuine consensus gap around how much automation should be allowed. Most practitioners agree that inactivity detection should be automated, but there is less agreement on whether remediation should be automatic for all identity types. Human users are usually safer to automate than privileged service identities, where revocation can disrupt production and where the inactivity signal may be misleading if the account is used only during failover, maintenance, or batch windows.

The practical rule is that accountability should follow the entity that can answer the business necessity question. If that answer is absent, the organisation should treat the identity as a governance exception rather than allowing it to linger by default. That distinction matters most when access spans multiple cloud providers, because cloud-native duplication makes it easy for one stale identity to persist after another team believes the cleanup is already complete.

Practitioner Guidance

What to prioritise: Assign one accountable owner for the final inactivity decision, even when review and remediation are shared. If nobody can approve removal, the identity is not really being governed.

What to verify: Confirm that each inactive identity class has a clear path from detection to decision to action, with different handling for human users, service identities, and break-glass access. The main failure is assuming a report alone creates accountability.

Decision rule: If the identity owner cannot explain the ongoing business need, treat the access as removable unless a documented exception exists. If the identity supports production operations, require an explicit owner and review date rather than indefinite retention.

Practitioner takeaway: Effective cleanup depends less on who runs the scanner than on who is empowered to say yes, no, or remove access when inactivity is confirmed.

Related resources from NHI Mgmt Group

• Who is accountable for maintaining least privilege across human and machine identities in cloud platforms?
• How should security teams govern non-human identities in cloud environments?
• Why do access certifications become a control gap when identities move across jobs, systems, and cloud platforms?
• Who is accountable for reducing breach risk across cloud identities and entitlements?