Why do unused cloud identities often become a larger risk than teams expect?

Why This Matters for Security Teams

Unused cloud identities are not harmless leftovers. They are persistent access paths that often retain keys, tokens, permissions, and trust relationships long after the original workload or owner has changed. That makes them attractive to attackers because stale identities are easier to miss than actively used accounts, especially in environments with fast-moving infrastructure and weak ownership records. NHIMG’s Top 10 NHI Issues and the NIST Cybersecurity Framework 2.0 both point to the same operational problem: identities that are not actively governed still expand the attack surface.

This risk is larger than many teams expect because cloud identity sprawl scales quietly. A role created for a migration project, a service account for a short-lived pipeline, or a key embedded in automation can survive long after business value ends. In the 2024 Non-Human Identity Security Report, 88.5% of organisations said their non-human IAM practices lag behind or merely match their human IAM efforts, which helps explain why dormant identities are often overlooked until an incident exposes them. In practice, many security teams encounter stale cloud identities only after a breach review has already revealed them.

How It Works in Practice

Unused identities become dangerous when three things happen together: credentials remain valid, permissions stay broader than necessary, and no one is clearly accountable for cleanup. A cloud identity may look inactive in logs, yet still be able to authenticate through an old access key, assume a role, or use a token issued for an automation job that nobody decommissioned. Once an attacker finds one of these paths, they do not need the original workload to be alive. They only need the identity to remain trusted.

Operationally, this is why teams should treat identity inventory as an active control, not a periodic spreadsheet exercise. Current guidance suggests pairing detection with ownership and expiration rules:

• Track every non-human identity with a named owner, system purpose, and renewal date.
• Measure last use, not just existence, and flag identities with no recent authenticated activity.
• Prefer short-lived credentials and automated rotation over long-lived static secrets.
• Remove permissions when workloads change, not only when incidents happen.
• Use continuous review to detect roles that can still be assumed even after the original workload is gone.

NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it frames the issue as a lifecycle problem, while the NIST guidance reinforces least privilege and ongoing authorization review. Teams that adopt ephemeral credentials, workload-specific identity, and policy-based access decisions reduce the blast radius of stale accounts. These controls tend to break down when identity ownership is unclear across multi-cloud environments because no single team can reliably decide when an identity is truly safe to retire.

Common Variations and Edge Cases

Tighter identity cleanup often increases operational overhead, requiring organisations to balance reduced exposure against the risk of breaking legitimate automation. That tradeoff is real in environments with legacy batch jobs, shared platform roles, or partner integrations that do not map cleanly to a single service owner.

Some identities are technically unused but still reserved for disaster recovery, blue-green deployments, or compliance holds. Current guidance suggests documenting these exceptions explicitly rather than letting them remain “temporarily” active for months. Another edge case is federated access: a cloud role may appear dormant in one account while still being assumable from another system through trust policies that were never revisited.

This is why NHIMG coverage of incidents such as the Snowflake breach and the 230M AWS environment compromise matters: in both cases, identity exposure was not just about whether an account existed, but whether trust, credentials, and access paths were still viable. Best practice is evolving, but the direction is clear. If an identity cannot be justified, monitored, and quickly revoked, it should not remain trusted.

Related resources from NHI Mgmt Group

• Why do dual writes create more risk in centralized authorization systems than teams often expect?
• How should security teams govern non-human identities in cloud environments?
• Why do machine identities create larger lateral movement risk than teams expect?
• Why do access certifications become a control gap when identities move across jobs, systems, and cloud platforms?