IAM Access Analyzer finds unused access, but enforcement stays manual

At a glance

What this is: This analysis shows that IAM Access Analyzer is a visibility tool for unused AWS access, not an enforcement mechanism that removes dormant permissions.

Why it matters: For IAM and NHI practitioners, the core issue is that least privilege programs fail when findings outpace safe remediation and standing access remains in place.

👉 Read Sonrai Security's analysis of why IAM Access Analyzer stops at unused access findings

Context

Unused IAM access is easy to find and hard to remove safely. In AWS environments, the problem is not just dormant permissions, but the operational risk of changing roles that may still support rare, undocumented, or periodic workflows. That makes least privilege an IAM and NHI governance issue, not just a reporting problem.

Sonrai Security argues that teams already know where dormant access exists, but they lack a reliable way to act on findings without breaking production. In practice, that gap shows up when service accounts, vendor integrations, and other non-human identities keep accumulating permissions faster than human review can clear them.

Key questions

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. The key is to preserve the identity while suppressing standing privilege, so rare workflows can be re-enabled without rewriting the role.

Q: Why do unused permissions remain a risk even after teams find them?

A: Because a finding is not a fix. Until the permission is actually removed or blocked, the identity still carries standing privilege that an attacker can abuse. The risk persists when remediation depends on manual review, cross-team coordination, or slow rollback, which is common in large cloud environments.

Q: What do teams get wrong about access review findings in cloud IAM?

A: They often treat the dashboard as evidence of control. In reality, the dashboard only shows exposure. If the organization cannot safely validate, block, and restore access, the finding backlog becomes a record of unmanaged risk rather than a remediation plan.

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.

Technical breakdown

Why IAM Access Analyzer is a findings engine, not a control plane

IAM Access Analyzer identifies unused roles, unused access keys, unused passwords, and permissions that have not been observed in a configurable window. It also generates a tighter policy recommendation based on observed activity. That makes it useful for discovery, audit evidence, and cleanup planning. The limitation is structural: it does not change the policy state. In other words, it can tell you where dormant access exists, but it cannot remove that access or safely restore it if a workflow later proves dependent on it.

Practical implication: Treat Access Analyzer as an input to remediation, not as the remediation mechanism itself.

Why dormant permissions are harder to remove than they look

A permission that appears unused over 90 days may still support quarterly jobs, disaster recovery roles, vendor processes, or AI-driven workflows that activate only under specific conditions. The hard part is not identifying the stale permission. It is proving that removing it will not break an unseen dependency. At enterprise scale, ownership sign-off, cross-team coordination, and lack of rollback speed turn every cleanup into a change-management problem. That is why many organizations leave findings open even when they know the access is excessive.

Practical implication: Build a validation and rollback path before you start removing permissions at scale.

How org-level blocking changes the least-privilege model

Instead of editing every role directly, org-level blocking uses cloud-native policy controls to prevent use of privileged permissions while preserving the identity itself. That matters because the identity structure remains intact, downstream references keep working, and restoration becomes a controlled approval event rather than a policy rewrite. This is the technical difference between a visibility-only tool and an enforcement layer. The control target is not just unused access, but unused privileged access that can materially increase blast radius if compromised.

Practical implication: Use central policy enforcement to suppress standing privilege while keeping a fast restore path for legitimate exceptions.

Threat narrative

Attacker objective: The attacker wants to convert dormant but still valid permissions into a durable path for privilege escalation or data access.

1. Entry occurs through dormant cloud permissions that were never removed after the original use case ended.
2. Escalation happens when unused privileged access remains available on roles that can modify identity, data, or network settings.
3. Impact is the continued existence of standing privilege that expands blast radius and keeps exploit paths open.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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

NHI Mgmt Group analysis

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.

Privilege cleanup is really a change-risk problem disguised as an access problem. Teams often assume the obstacle is better detection, but the real blocker is the cost of being wrong. If a permission supports a quarterly job or a rare recovery workflow, an irreversible edit can create operational damage. That means remediation design must include ownership, validation, and a fast restore path before enforcement begins.

Identity blast radius is the right metric for dormant access programs. The question is not whether a permission is theoretically unused, but whether it meaningfully enlarges the damage an attacker can do if the identity is abused. That makes central blocking and task-scoped restoration more defensible than per-role cleanup in large cloud estates. Practitioners should measure how much blast radius remains after cleanup, not just how many findings were filed.

Shadow privilege accumulates wherever remediation depends on manual coordination. When security, cloud operations, and developers all have to agree before a change can ship, the backlog becomes the control. That pattern is especially risky for non-human identities because their owners, usage windows, and dependencies are often opaque. The governance lesson is to move from review-based cleanup to policy-based suppression with controlled exception handling.

Least privilege in cloud environments is a lifecycle discipline, not a one-time audit. Unused access will reappear as accounts, integrations, and workloads change. That is why org-level blocking, periodic recertification, and exception workflows should be treated as a single operating model rather than separate initiatives. The organizations that succeed will reduce standing privilege continuously, not in episodic cleanup campaigns.

From our research:

• 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.
• For a deeper view of how dormant access becomes exploitable, see 52 NHI Breaches Analysis for repeated patterns in credential misuse and overexposure.

What this signals

Identity blast radius is now the metric that matters most. When access review programs cannot turn findings into policy changes, the organization is left measuring visibility instead of risk reduction. 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.

The governance model is shifting toward continuous suppression with exception handling. That aligns with the broader reality that non-human identities, including service accounts and workload credentials, rarely fit a human-style review cadence. The most resilient programmes will treat dormant permission reduction as an operating rhythm, not a quarterly project.

With 69% of security leaders saying identity management must fundamentally shift to address agentic AI systems, the same pressure will eventually hit cloud IAM programmes that still rely on manual permission cleanup. Teams that invest now in control-plane enforcement and fast restoration will have a better path when the identity estate expands further.

For practitioners

• 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.
• Prioritise privileged permissions before broad cleanup Focus first on permissions that can modify identity, data, or network exposure, because those create the largest blast radius when left standing.

Key takeaways

• IAM Access Analyzer improves visibility, but it does not remove dormant permissions or close the enforcement gap.
• The hardest part of least privilege is safe remediation at scale, not finding unused access.
• Central blocking with controlled restoration is a stronger operating model than per-role cleanup in large cloud estates.

Key terms

• Standing Privilege: Standing privilege is access that remains continuously available instead of being granted only when needed. In cloud IAM and NHI governance, it creates avoidable exposure because unused permissions can still be abused unless they are blocked, time-bound, or tightly recertified.
• Findings Backlog: A findings backlog is the accumulation of discovered access issues that have not yet been remediated. It often becomes a governance failure signal when teams can identify unused permissions faster than they can safely validate and remove them across accounts, roles, and service identities.
• Identity Blast Radius: Identity blast radius is the amount of damage an attacker can cause if a given identity is compromised. For non-human identities, it is shaped by permission scope, lateral reach, and whether dormant access can still be activated without additional controls.

Deepen your knowledge

IAM least privilege and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is struggling to turn access findings into safe enforcement, it is worth exploring.

This post draws on content published by Sonrai Security: Why IAM Access Analyzer Tells You About Unused Permissions But Won't Remove Them. Read the original.