Cloud IAM visibility still lags behind access sprawl

At a glance

What this is: Orca Security argues that cloud IAM risk is driven less by missing findings than by missing context around who can access what and whether that access is still needed.

Why it matters: For IAM, NHI, and cloud security teams, the message is that access visibility only becomes actionable when it is tied to asset context, ownership, and actual usage.

By the numbers:

• 78% of organizations have at least one IAM role that hasn’t been used in over 90 days.
• Among organizations that experienced a cloud-related breach, excessive permissions accounted for 31% of the top identity-related causes.
• Use of stolen credentials was the top action of basic web application attacks at 88% of the breaches analyzed in the 2025 Verizon DBIR.

👉 Read Orca Security's analysis of cloud IAM visibility and Access Analyzer context

Context

Cloud IAM becomes hard to govern when permissions, trust relationships, and inherited roles expand faster than teams can review them. In dynamic environments, the primary keyword here is cloud IAM visibility, because without context on ownership, usage, and exposure, even accurate findings are difficult to prioritise.

The governance problem is not that organisations lack data. It is that access findings are often detached from the resource they affect, the business purpose they serve, and whether the privilege is still active. That gap matters across NHI, workload identity, and human-admin access because all three can create standing exposure when lifecycle controls lag behind infrastructure change.

Key questions

Q: Why do unused cloud IAM roles create so much risk?

A: Unused roles are dangerous because they often indicate standing privilege that no longer has an active business justification. When access remains available without recent use, it can still be abused by attackers, insiders, or misrouted automation. The risk is not just exposure. It is the persistence of privileges that no longer match operational need.

Q: How should teams prioritise IAM findings in cloud environments?

A: Teams should prioritise IAM findings by combining exposure type with asset sensitivity, ownership, and business impact. A finding on a low-value resource is not equivalent to the same finding on a production database. Prioritisation should answer three questions: who owns it, what does it protect, and is the access still justified?

Q: What do security teams get wrong about internal access in the cloud?

A: They often focus on external exposure and treat internal trust paths as lower risk. That misses lateral movement opportunities created by over-permissioned roles, inherited trust, and cross-account access. Internal access is not safe simply because it is inside the organisation. It must be reviewed with the same discipline as public exposure.

Q: Who should own remediation when an IAM finding appears in a cloud asset?

A: Remediation should sit with the team that owns the asset and understands the business purpose of the access. Security can triage and enforce policy, but the accountable owner must confirm whether the access is required. Without ownership, IAM findings remain unresolved and tend to harden into permanent privilege.

Technical breakdown

Why continuous IAM analysis matters in dynamic cloud environments

In fast-changing cloud estates, IAM analysis cannot rely on point-in-time review because permissions, trust policies, and resource relationships change continuously. AWS IAM Access Analyzer uses automated reasoning to evaluate resource policies and trust paths, then classifies findings such as external access, internal access, and unused access. The technical value is not just detection. It is mathematical consistency across a moving policy surface, especially for resources like S3, RDS snapshots, and DynamoDB tables where trust misconfiguration can be both subtle and persistent.

Practical implication: build continuous access analysis into the cloud control plane, not into periodic audit workflows.

External access, internal access, and unused access are different risk states

These three finding types represent different control failures. External access means a resource is reachable beyond the intended trust boundary. Internal access means trust paths or permissions exist inside the account or organisation that may exceed operational need. Unused access indicates a permission or role has remained active without evidence of recent use, which is often where standing privilege hides. Treating them as one bucket obscures remediation priority because each state implies a different blast radius, ownership question, and containment path.

Practical implication: triage findings by exposure type before assigning remediation work.

Why context-rich findings outperform raw finding volume

Raw IAM findings create noise when teams cannot tell whether an exposed resource contains sensitive data, who owns it, or whether the access path was intentional. Context turns a finding into an operational decision by linking policy exposure to asset metadata and business relevance. This is the difference between knowing a resource is reachable and knowing whether that reachability matters. For cloud security programmes, the mechanism is prioritisation, not simple visibility.

Practical implication: require asset context and ownership metadata before closing, escalating, or accepting any IAM exposure finding.

Threat narrative

Attacker objective: The attacker aims to turn dormant or poorly understood cloud access into actionable reach across sensitive data and workloads.

1. Entry occurs through accumulated IAM exposure, where inherited permissions, unused roles, or overbroad trust paths remain active long enough to be discovered and abused.
2. Escalation follows when internal access paths or standing permissions allow an attacker or insider to move from one reachable resource to a broader set of cloud assets.
3. Impact is produced by unauthorised access to data or workloads whose blast radius was never constrained by lifecycle review or context-aware prioritisation.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud IAM visibility is only useful when it is contextualised by asset value and ownership. A raw finding tells you that access exists, but not whether that access creates material risk or business impact. The article correctly distinguishes exposure from decision-making, which is where many cloud programmes still fail. Practitioners should treat context-rich access analysis as the control layer that turns findings into prioritised action.

Standing permissions are a lifecycle problem disguised as a detection problem. The article’s 78% unused-role figure points to a common governance failure: access persists because review and offboarding processes do not keep pace with cloud change. This is not just an IAM hygiene issue. It is the same lifecycle weakness that affects service accounts, inherited roles, and long-lived workload identities. Practitioners should stop treating unused access as a low-value cleanup task and start treating it as latent blast radius.

Internal trust paths are the blind spot that least-privilege programmes often under-assess. External exposure gets the most attention, but internal access can be equally dangerous because it enables lateral movement inside the cloud boundary. The article’s emphasis on trust relationships is important because internal reach often survives when teams only monitor perimeter-style exposures. Practitioners should evaluate internal trust as a first-class governance problem, not a secondary finding type.

Context-rich IAM analysis closes the gap between security tooling and governance intent. The strongest point in the article is that high-fidelity findings still need prioritisation logic tied to resource sensitivity, ownership, and usage history. That is the difference between a dashboard and a control system. Practitioners should align IAM telemetry with cloud asset inventory so that remediation is based on blast radius, not alert count.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
• For a broader governance baseline, see Ultimate Guide to NHIs , Key Challenges and Risks for the control gaps that make access sprawl persistent.

What this signals

Cloud identity programmes are moving toward continuous control validation, because periodic review cannot keep up with the pace of ephemeral infrastructure and inherited trust. When permissions age faster than audit cycles, the programme signal should shift from "who has access" to "which access still has a live owner and a current business purpose."

Identity blast radius: the real governance unit is no longer the individual permission, but the combination of trust path, asset sensitivity, and time since last use. That is the frame practitioners should use when deciding whether an IAM finding is merely technical debt or a live exposure.

With 72% of organisations already reporting or suspecting an NHI breach in the 2024 ESG dataset, cloud teams should assume that unmanaged access states will be exploited unless they are continuously linked to ownership, usage, and data context.

For practitioners

• Prioritise unused IAM roles by business-criticality Review roles that have not been used in over 90 days first in systems that hold regulated or production data. Confirm whether the role still maps to a live owner, then revoke or re-scope access before it becomes part of the standing privilege baseline.
• Link IAM findings to asset ownership and sensitivity Do not allow external, internal, or unused access findings to sit outside the asset record. Attach each finding to the workload, data classification, and accountable team so remediation can be ordered by actual exposure rather than by ticket volume.
• Separate internal trust review from perimeter review Inspect trust paths inside the cloud environment independently from internet-facing exposure checks. Internal permissions often create the lateral movement path that perimeter monitoring never sees, especially where inherited roles and cross-account trust persist.
• Use context to decide when a finding is truly high risk Require a decision on whether the affected resource contains sensitive information, whether access was intentional, and whether the permission is still needed. If those answers are missing, the finding should remain open until the owner provides evidence.

Key takeaways

• Cloud IAM risk is being driven by permissions that outlive their business purpose, not by a lack of telemetry.
• Unused roles, internal trust paths, and detached findings all increase blast radius when they are not tied to asset context and ownership.
• Practitioners should treat context-rich access analysis as a governance control, not just a better view of the same problem.

Key terms

• Standing Privilege: Access that remains in place after the original need for it has passed. In cloud environments, standing privilege often hides in unused roles, inherited trust, and long-lived permissions that nobody revisits. It matters because dormant access can still be abused even when no one is actively using it.
• Internal Access Finding: A policy or trust-path result showing that a resource is reachable from inside the account or organisation beyond the intended need. This is not the same as public exposure. It often reveals lateral movement risk, overbroad delegation, or permissions that were never revalidated after the environment changed.
• Context-Rich Access Insight: An access finding that is paired with asset metadata such as owner, data sensitivity, and workload purpose. Context-rich insight is more useful than raw exposure data because it helps teams decide whether a finding is a real risk, an accepted exception, or an artefact of normal operations.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: cloud IAM visibility, Access Analyzer, and context-rich access insights. Read the original.