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.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Close the Cloud Identity Gap with Orca and AWS IAM Access Analyzer”.
By the numbers:
- 78% of organisations have at least one IAM role that hasn’t been used in over 90 days, according to Orca Security's 2025 State of Cloud Security Report.
- Excessive permissions caused 31% of cloud-related breaches among organisations that experienced a breach, according to CSA’s State of Cloud and AI Security 2025 survey report cited by Orca Security.
- Inconsistent access controls caused 27% of cloud-related breaches among organisations that experienced a breach, according to CSA’s State of Cloud and AI Security 2025 survey report cited by Orca Security.
Key questions
Q: Where do cloud IAM controls fail when access findings lack context?
A: They fail at prioritisation.
Q: Why do standing privileges increase breach impact in cloud and enterprise environments?
A: Standing privileges enlarge the attacker’s options because one exposed administrative path can be reused for lateral movement, persistence, or broad operational control.
Q: What are the signs that non-human identity governance is failing in cloud environments?
A: Common warning signs include credential sprawl, long-lived API keys, unrotated certificates, unclear ownership, and workloads with more access than they need.
Practitioner guidance
- Map unused access to business ownership Tie every unused IAM role or credential to an accountable owner and a current business justification before deciding whether it stays active.
- Prioritise internal trust paths on sensitive assets Rank internal access findings by the sensitivity of the attached resource, not by the raw number of findings in the account.
- Join access findings to asset inventory Review external, internal and unused access findings alongside asset metadata so remediation decisions reflect actual blast radius.
Bottom line: Cloud IAM sprawl creates a governance gap when access changes faster than teams can review ownership, intent and scope.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
12/06/2026 11:52 pm
Cloud IAM visibility is now a prioritisation problem, not a discovery problem. Security teams already have findings, but they do not always have the resource context needed to decide which access paths actually matter. That shifts the governance question from “what is exposed?” to “what exposure changes blast radius?” and makes context the deciding control variable for cloud identity programmes.
A question worth separating out:
Q: How should teams reduce blast radius from internal AWS access?
A: Start by classifying internal trust paths by the sensitivity of the resource they reach, then remove or narrow access that is not required for the current business function. Internal access is not safe by default, and cloud least privilege only works when trust paths are reviewed as actively as external exposure.
👉 Read our full editorial: Cloud IAM visibility still lags behind access sprawl
This post was modified 3 days ago by NHI Mgmt Group