Unused cloud permissions are widening enterprise blast radius

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Sonrai Security's blog post: Unused cloud permissions are not benign hygiene debt but a direct expansion of enterprise blast radius, driven largely by inactive machine identities.

Why it matters: For IAM, PAM, and cloud security teams, the issue is that standing permissions on dormant identities increase attack surface, audit burden, and cleanup effort without improving operations.

By the numbers:

• 92% of all identities with access to sensitive permissions did not use them over 90 days.
• 87% of the unused-access group were machine identities.

Context

Unused cloud permissions become a security problem when the privilege model is based on provisioning time rather than runtime use. In that model, access accumulates across service accounts, pipelines, vendor integrations, and abandoned roles long after the business need has changed.

Sonrai Security's analysis frames this as a cloud governance gap, not a user discipline issue. The core problem is that most privileged identities are non-human, yet they are still managed with review and cleanup processes that were never built for cloud-scale machine access.

Key questions

Q: What breaks when cloud identities are over-permissioned?

A: Over-permissioned identities create a wider blast radius than the business intended. Once a credential is compromised, the attacker inherits every unused permission attached to it, including access to storage, control planes, or adjacent workloads. CIEM is designed to expose that gap so teams can remove standing access before it becomes an incident.

Q: Why do dormant cloud permissions create audit and compliance problems?

A: Because auditors need a defensible justification for sensitive access, and unused permissions are hard to explain when the original business need no longer exists. The problem is especially acute when roles were copied from older templates or inherited through integrations. That leaves teams repeatedly documenting access they cannot operationally defend.

Q: How can security teams tell whether permission cleanup is working?

A: Look for a shrinking gap between assigned entitlements and actual runtime use. Effective programmes should show fewer identities carrying sensitive permissions they never invoke, fewer standing high-risk grants, and a lower proportion of dormant access tied to machine identities. If those numbers do not move, the governance model is still mostly reporting, not enforcement.

Q: Should organisations remove unused cloud access or quarantine it first?

A: Quarantine is usually safer than deletion when the original purpose of an identity is not fully documented. It preserves the identity object, strips access, and allows rare legitimate use to be restored through approval if needed. That approach reduces blast radius without forcing teams to guess which dormant workloads are truly dead.

Technical breakdown

Why unused cloud permissions persist in cloud estates

Cloud permission sprawl starts with broad grants during deployment and persists because those grants are rarely removed after the task ends. Roles are copied from previous templates, service accounts inherit excess scope, and third-party integrations keep access long after the original justification disappears. The important technical point is that the policy document and actual usage data live in different control planes, so manual review cannot reliably infer whether a permission is still needed. At scale, that creates a standing discrepancy between intended and actual privilege.

Practical implication: measure permissions against runtime use, not just assigned policy, before deciding what to remove.

Why legacy PAM and visibility tools miss unused privilege

Traditional PAM assumes a small set of named human privileged accounts. Cloud estates do not work that way, because any identity with a high-impact permission is effectively privileged, including machine identities, APIs, and third-party access paths. Visibility tools may identify dormant or excess permissions, but they usually stop at recommendation. That leaves the operational burden of deciding what is safe to remove and proving that removal will not break production. The technical gap is enforcement, not detection.

Practical implication: treat dormant cloud permissions as an enforcement problem, not a reporting problem.

How JIT must shift from user access to permission access

Just-in-time access is often implemented as a gate on the user or operator, which still leaves the underlying role overpowered. If the permission remains standing on the role, a compromised credential can still invoke it whenever the role is active. Sonrai Security's argument is that JIT must apply to the permission itself, so sensitive access is absent by default and issued only for a specific task window. That changes the technical control point from login approval to entitlement issuance.

Practical implication: move JIT controls to the permission layer so privileged actions exist only for the task that requires them.

Threat narrative

Attacker objective: The attacker aims to turn one compromised cloud identity into access across a much larger set of workloads, data, and control paths.

1. Entry occurs when an attacker compromises any credential tied to an overprivileged cloud identity, including a machine identity or third-party integration.
2. Credential access is amplified because the identity holds permissions it never uses, so the attacker inherits reachable cloud actions that the legitimate workload does not need.
3. Lateral movement and escalation follow when those standing permissions extend to adjacent services, storage, or identity configuration paths.
4. Impact is broader blast radius, because the compromised identity can reach more cloud resources than runtime behaviour would suggest.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Scania insurance portal breach 2025: An attacker used an external user login, likely stolen by infostealer malware, to take insurance claim documents from a Scania portal.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Unused cloud permission is a blast-radius problem, not a permissions-count problem. The central risk is not how many identities exist, but how much reachable action remains attached to identities that no longer need it. When 92% of sensitive permissions sit unused, the enterprise is carrying a hidden expansion of the compromise domain. The practitioner conclusion is that blast radius must be governed as a first-class identity metric.

Machine identities are the dominant source of privilege drift. The article's own split shows that 87% of unused access sits with non-human identities, which means cloud governance failures are being concentrated in the part of the estate least likely to receive manual review. That is exactly where lifecycle processes, entitlement review, and access recertification break down. The conclusion is that machine identity governance cannot be treated as a side case of human IAM.

Permission-level JIT is the control model cloud estates actually need. Gating the person while leaving the privilege standing does not change exposure if the role still carries dormant power. The analysis here sharpens a useful concept: ephemeral privilege residue, meaning permissions that remain live after the operational need has ended. The conclusion is that standing privilege, not just standing users, is what needs to disappear.

Cloud access cleanup is constrained by production fragility, not by detection. Sonrai Security's framing makes clear that teams can identify dormant access quickly but struggle to remove it safely because manual cleanup can break workloads. That means the bottleneck is governance execution, not visibility. The conclusion is that least-privilege programmes fail when they cannot separate dormant access from active operational dependency.

Third-party and acquisition-driven access deserves its own entitlement review path. The article identifies vendor integrations and acquisitions as major sources of unused permission accumulation, which shows that standard joiner-mover-leaver thinking is too narrow for cloud estates. Those access paths often outlive the business relationship that justified them. The conclusion is that offboarding and integration cleanup have to be treated as cloud identity controls, not only procurement tasks.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Read next: Agentic AI Identity Maturity Model

What this signals

Ephemeral privilege residue: cloud estates now accumulate permissions that survive long after operational need has ended, and those permissions become the real attack surface when credentials are compromised. Programmes that still treat JIT as a login gate are leaving the high-risk entitlement intact, which means access governance must move to issuance time rather than recertification time.

The next control question is not whether a role exists, but whether it still needs the ability to act at all. That shift matters most for machine identities, third-party integrations, and acquired access paths, where runtime use is thin and standing privilege is the default.

For practitioners

• Audit unused sensitive permissions by runtime evidence Compare assigned entitlements with 90-day usage data for cloud roles, service accounts, and integrations. Prioritise permissions that remain standing on identities that never invoke them.
• Quarantine dormant identities before deleting them Strip access from identities that appear inactive, but preserve the identity object so occasional workloads can request access through an approval workflow when needed.
• Move JIT enforcement to the permission layer Ensure sensitive permissions are absent in steady state and granted only for a task window to the exact human, machine, or agent that needs them.
• Review third-party and acquisition inherited access Revalidate vendor, integration, and acquired-team permissions separately from normal recertification, because those access paths often persist long after the original business need ends.

Key takeaways

• Unused cloud permissions expand compromise impact even when they appear inactive, because the permissions remain usable the moment a credential is taken over.
• The article's own data point to a machine identity problem, not just a human review problem, with 87% of unused access tied to non-human identities.
• The practical fix is to govern entitlement issuance and cleanup at the permission layer, so dormant access no longer sits in the path of compromise.

Key terms

• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Dormant Identity: A non-human identity that is no longer actively used but still has valid access. Dormancy is risky because it looks harmless while preserving credentials, permissions, and trust relationships that can still be abused or accidentally triggered.
• Permissions-on-Demand: Permissions-on-Demand is a governance pattern that grants sensitive access only for a specific task and only for a limited period. It is especially useful in cloud environments because it reduces the value of compromised credentials while preserving a controlled path for legitimate elevation.
• Ephemeral Privilege: Ephemeral privilege is access that exists only for a short task or runtime window, then should disappear. In cloud and container environments, the challenge is not granting it, but proving it was created, used, and removed within the intended boundary before it becomes a lingering exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.