Notifications
Clear all
Topic starter
12/06/2026 9:39 pm
TL;DR: Cloud IAM permissions often accumulate faster than teams can audit them, and the article argues that this makes access context, not finding volume, the real control gap, according to Orca Security. The practical issue is that standing permissions, unused roles, and internal trust paths create blast-radius risk that conventional scans do not prioritise well.
NHIMG editorial — based on content published by Orca Security: cloud IAM visibility, Access Analyzer, and context-rich access insights
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Link IAM findings to asset ownership and sensitivity Do not allow external, internal, or unused access findings to sit outside the asset record.
- Separate internal trust review from perimeter review Inspect trust paths inside the cloud environment independently from internet-facing exposure checks.
What's in the full article
Orca Security's full article covers the operational detail this post intentionally leaves for the source:
- How Orca surfaces IAM Access Analyzer findings directly on the affected asset record
- The workflow for reviewing internal access, external access, and unused access findings in one interface
- Examples of how the AWS Console handoff works after prioritising a finding
- The specific asset-level views used to validate whether access was intentional
👉 Read Orca Security's analysis of cloud IAM visibility and Access Analyzer context →
AWS IAM Access Analyzer and cloud identity context gaps?
Explore further
12/06/2026 11:52 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Cloud IAM visibility still lags behind access sprawl
