Who should own decisions when unused cloud identities are disabled or removed?

Security, cloud platform, and application owners should share accountability. Security teams can identify risk and propose action, but business and engineering owners must confirm whether an identity is tied to production, testing, or recovery. Clear ownership prevents accidental outages and stops stale identities from lingering because no one feels responsible for them.

Why This Matters for Security Teams

Deciding who can disable or remove unused cloud identities is really a question of ownership, not just access hygiene. When that decision sits only with security, teams may miss whether an identity still supports production jobs, recovery workflows, or automation. When it sits only with engineering, stale access can linger indefinitely. The practical risk is service disruption, hidden privilege, and confusion over who signs off on removal.

Current guidance suggests that unused identity cleanup should be treated as a shared control between security, platform, and application owners, with security driving risk detection and the business owner confirming operational dependency. That separation matters because cloud identities often outlive the system that created them, especially in multi-account and multi-cloud estates. NIST SP 800-53 Rev 5 Security and Privacy Controls frames this as a control ownership and review problem, not a pure technical deletion task, and NHIMG research shows that 88.5% of organisations acknowledge their non-human IAM practices lag behind or are merely on par with human IAM in maturity, which helps explain why these reviews fail in practice.

In practice, many security teams only discover an identity was still needed after a deployment, backup job, or recovery run has already failed.

How It Works in Practice

The cleanest operating model is a three-way decision path. Security identifies unused or high-risk identities through telemetry, access reviews, and secret inventory. Cloud platform owners validate where the identity exists, what it touches, and whether it maps to a shared service, workload, or account-level integration. Application owners or service owners then confirm whether the identity is still tied to a live dependency, a dormant recovery process, or a decommissioned component.

This is where ownership must be explicit. Security can recommend action, but it should not unilaterally remove identities that support business services. The operational question is whether the identity is truly unused, and only the system owner can answer that with confidence. NIST SP 800-53 Rev 5 Security and Privacy Controls supports this model through account management, access review, and least-privilege expectations. For NHI environments, NHIMG research on the 2024 Non-Human Identity Security Report shows how common the maturity gap is, which is why ownership workflows need to be documented, not informal.

• Security flags the identity based on last-use data, secret age, or anomalous privilege.
• Platform teams confirm scope, environment, and blast radius.
• Application or service owners approve disablement, rotation, or removal.
• Change management records the decision so future reviews have a clear owner.

This same pattern is critical in incident-driven cleanups, especially after exposures like the Snowflake breach or the JetBrains GitHub plugin token exposure, where identity sprawl and stale secrets make attribution harder. These controls tend to break down when identities are embedded in legacy automation or recovery tooling because no single team can prove safe removal quickly.

Common Variations and Edge Cases

Tighter identity cleanup often increases coordination overhead, requiring organisations to balance operational safety against speed of remediation. That tradeoff becomes sharper in environments with shared service accounts, cross-account automation, or disaster recovery credentials that are used only a few times a year.

Best practice is evolving, but current guidance is clear on one point: if no named owner can confirm business dependency, the identity should not be left active by default. Some teams use a staged approach, first disabling the identity, then monitoring for breakage before permanent removal. That is safer than immediate deletion in environments where access paths are poorly documented. In other cases, temporary break-glass or recovery identities may require separate approval logic, because their value is precisely that they are rarely used.

NHIMG research on the Azure Key Vault privilege escalation exposure and the 230M AWS environment compromise illustrates why hidden privilege and unclear ownership are dangerous together. Where the answer is uncertain, the decision should move to the service owner with security retaining veto authority on risk, not the other way around. There is no universal standard for this yet, but organisations that document ownership and approval paths consistently remove stale identities with far fewer outages.

Related resources from NHI Mgmt Group

• Why do unused cloud identities often become a larger risk than teams expect?
• 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?
• How should security teams prioritise NHI remediation in cloud environments?