TL;DR: IAM Access Analyzer surfaces unused roles, keys, passwords, and permissions in AWS, but it does not remove them, leaving remediation to security teams and creating a gap between detection and actual least-privilege enforcement, according to Sonrai Security. The operational bottleneck is not visibility but safe, scalable action.
NHIMG editorial — based on content published by Sonrai Security: Why IAM Access Analyzer Tells You About Unused Permissions But Won't Remove Them
Questions worth separating out
Q: How should security teams reduce unused IAM permissions without breaking workloads?
A: Use a staged model: discover unused permissions, validate business dependency, block the highest-risk access centrally, and keep a fast restore path for exceptions.
Q: Why do unused permissions remain a risk even after teams find them?
A: Because a finding is not a fix.
Q: What do teams get wrong about access review findings in cloud IAM?
A: They often treat the dashboard as evidence of control.
Practitioner guidance
- Implement org-level blocking for privileged unused access Use native cloud policy controls to suppress unused privileged permissions centrally while leaving the identity intact and preserving downstream dependencies.
- Create a fast restore workflow for legitimate exceptions Route temporary access through a task-scoped approval process so quarterly jobs, recovery activities, and uncommon workflows can be re-enabled without redesigning the role.
- Separate discovery findings from remediation decisions Assign explicit owners to review each unused-access finding, validate business dependency, and document whether the permission should be blocked, retained, or time-bound.
For cloud and NHI teams, that means cleanup backlog, restore speed, and central policy enforcement should be tracked as first-class controls, not implementation details?
👉 Read Sonrai Security's analysis of why IAM Access Analyzer stops at unused access findings →
Explore further
Visibility without enforcement is not least privilege. IAM Access Analyzer can identify unused permissions, but the control problem remains unsolved until those permissions are actually constrained or removed. In mature environments, dashboards tend to accumulate faster than remediation capacity, especially where service accounts and other non-human identities are created continuously. The practical conclusion is clear: least privilege must be enforced, not merely observed.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, which shows how sharply blast radius changes when access is scoped correctly.
A question worth separating out:
Q: When should organisations use central blocking instead of deleting a role?
A: Use central blocking when the identity may still be needed by rare, undocumented, or periodic workflows. Deletion is permanent and can break dependencies that appear only after the fact. Blocking lets the team reduce blast radius while keeping the recovery path simple.
👉 Read our full editorial: IAM Access Analyzer finds unused access, but enforcement stays manual