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

Why This Matters for Security Teams

Inactive identities are not just an inventory problem. In cloud environments, a dormant user, service principal, workload identity, or API credential can remain valid long after the business owner has moved on, the application has changed, or the platform has been repurposed. That creates a simple path for privilege accumulation, lateral movement, and unnoticed access drift across accounts and providers.

The governance failure is usually ownership, not tooling. Identity teams may own the policy, cloud security may see the exposure, and platform teams may understand the workload, but none of them can safely declare access unnecessary without shared accountability. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls treats access review and account management as control functions, but cloud adoption makes those functions distributed across domains. That is why dormant access persists after migrations, acquisitions, and team reshuffles.

NHIMG research on the 2024 Non-Human Identity Security Report found that 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI challenge, which is exactly where cleanup ownership tends to blur. In practice, many security teams discover inactive identities only after an access review, incident response, or audit finding exposes the gap.

How It Works in Practice

Effective cleanup requires a RACI that separates decision-making from execution. Identity governance should own the policy and review cadence, cloud security should define detection logic and monitor exposure, and platform or application owners should approve whether access is still required. That division matters because only the workload or system owner can confirm whether a service account, token, or role is tied to an active process.

Practically, teams should combine periodic certification with continuous signals from cloud telemetry, CIEM, and asset inventory. The objective is to identify identities that have no recent use, no active workload dependency, and no business justification. When possible, use short review windows and require explicit attestation for exceptions. The access decision should be recorded, time-bound, and tied to a named owner so cleanup is traceable.

For cloud environments, accountability should extend across the full lifecycle: discovery, classification, approval, and remediation. That includes:

• identities created by automation but never decommissioned
• roles inherited through nested groups or cross-account trust
• orphaned service principals after app retirement or migration
• overlooked secrets and tokens associated with old integrations

NHIMG’s 230M AWS environment compromise coverage and the Snowflake breach both reinforce the same lesson: stale access becomes dangerous when cleanup depends on informal handoffs rather than named owners and enforced revocation paths. These controls tend to break down in fast-moving multi-account environments because ownership metadata is incomplete and no single team can reliably prove whether access is still in use.

Common Variations and Edge Cases

Tighter cleanup processes often increase operational overhead, requiring organisations to balance reduced exposure against slower changes and more review work. That tradeoff is real, especially where many identities are ephemeral, automated, or owned by vendor-managed services.

Current guidance suggests treating high-risk identities differently from ordinary employee accounts. Long-lived cloud roles, break-glass access, cross-tenant trusts, and secrets used by production workloads deserve stricter ownership and faster review cycles. For these cases, best practice is evolving toward continuous validation rather than quarterly cleanup alone. In contrast, low-risk identities may be handled through standard recertification provided the business owner can still attest with confidence.

There is no universal standard for how to assign accountability across federated cloud operating models, but the practical answer is consistent: the team closest to the business purpose must approve retention, while the team operating the platform must execute removal. External auditors may ask who owns the control, but incident responders will care who can revoke the access immediately.

That is why cleanup responsibility should be documented by identity type, not just by department. Human users, service accounts, workload identities, and emergency access all age out differently, and treating them as one category usually leaves the most dangerous ones behind.

Related resources from NHI Mgmt Group

• 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?
• How should security teams prioritise NHI remediation in cloud environments?