IAM Access Analyzer finds unused access, but enforcement stays manual

At a glance

What this is: This analysis explains why IAM Access Analyzer is useful for finding unused AWS access, but does not close the enforcement gap because it stops at detection.

Why it matters: IAM and cloud security teams need more than visibility: unused permissions remain risk until there is a controlled way to revoke them, preserve workflows, and restore access when justified.

Context

IAM Access Analyzer can identify dormant AWS access, including unused roles, access keys, passwords, and role permissions, but the tool does not remove them. That leaves teams with a visibility signal, not an enforcement mechanism, which is why least-privilege programmes often stall at the dashboard stage.

The governance problem is not discovering unused access. The problem is safely acting on findings across large environments where permissions may still support rare jobs, vendor workflows, or break-glass use cases. In that setting, the identity lifecycle issue is enforcement at scale, not detection at scale.

Key questions

Q: What fails when unused AWS permissions are only detected and not enforced?

A: The control fails at remediation. A finding tells you where dormant access exists, but it does not remove the permission or stop it from being used. Until revocation happens, the exposure remains active, which means visibility alone does not reduce least-privilege risk.

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 security teams get wrong about unused access cleanup?

A: They often assume a finding backlog can be cleared role by role without breaking production. In practice, each removal needs ownership, cross-team coordination, and a rollback path, so manual cleanup becomes slower than the rate at which new dormant access appears.

Q: What is the difference between access visibility and access enforcement?

A: Access visibility tells you what users can do, while access enforcement changes that state in the target systems. A graph can expose effective permissions without being able to remove them, and a governance workflow can revoke access without showing the full entitlement picture. Practitioners need both layers, but they solve different problems.

Technical breakdown

Why unused access findings do not equal least privilege

IAM Access Analyzer reports on unused permissions by comparing observed activity against a configurable window, then recommends a tighter policy. That makes it a useful discovery control, but it is still only a signal. The tool does not know future use, undocumented dependencies, or whether a role exists to satisfy a rare operational requirement. Because the finding is informational only, teams must review, validate, approve, and apply every change themselves.

Practical implication: treat findings as inputs to governance, not as proof that access has been reduced.

Why manual permission removal stalls at enterprise scale

Unused permissions are hard to remove because the risk of breaking a workflow is real, while the ownership required to approve removal is often unclear. A role may belong to a quarterly job, a disaster-recovery process, or an integration no one actively monitors. When every change requires cross-team coordination and a reliable rollback path, remediation throughput collapses and backlogs grow faster than review capacity.

Practical implication: measure remediation capacity separately from discovery capacity, because the two are not the same control.

Why central blocking is safer than editing every role

A safer enforcement pattern is to block unused privileged permissions centrally while preserving the identity itself. That keeps the role structure intact, avoids destructive per-role policy rewrites, and allows a fast restore path when a legitimate need appears. The architectural point is that enforcement should be reversible and org-wide, not dependent on manual edits to thousands of identities.

Practical implication: move from role-by-role cleanup to org-level enforcement with a controlled restore workflow.

Threat narrative

Attacker objective: The objective is to exploit residual, unused AWS permissions before they are manually reviewed and removed, turning dormant access into active control over cloud resources.

1. Entry occurs through normal AWS access that is technically valid but no longer operationally required, such as a role, key, password, or permission left unused. The exposure exists because the credential remains live even when the activity pattern has gone dormant.
2. Credential abuse happens when those dormant permissions are still available to a compromised identity or an insider with access to the account. The attacker does not need a new privilege if the old one is still present and unrevoked.
3. Impact comes from the standing permission remaining exploitable until a human team manually reviews and removes it. The longer the backlog sits, the longer unused access can be used for data access, configuration changes, or privilege expansion.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Visibility without enforcement is not least privilege: The central lesson here is that discovery tools do not reduce risk unless they are connected to a safe revocation path. Access Analyzer can identify dormant permissions, but the governance burden stays with the team that must decide what to remove and what to preserve. That makes enforcement capacity the real control variable, not the number of findings surfaced.

Manual remediation is a governance bottleneck, not an operational detail: The hard part is not knowing that a permission is unused. The hard part is proving it is safe to remove across rare jobs, vendor dependencies, and break-glass scenarios. In practice, this creates a standing privilege window that lasts until human review catches up, which is why backlog size matters as much as exposure size.

Org-level blocking is the right enforcement model for unused access: The article exposes a control design problem: per-role cleanup makes least privilege too fragile to execute at scale. Blocking unused privileged permissions centrally while preserving the identity changes the risk equation because the restore path becomes controlled and reversible. The implication is that least privilege needs a policy layer that can act faster than review queues.

Unused privilege is a lifecycle failure, not a snapshot problem: The article shows that access can be technically valid, operationally stale, and still exploitable. That is a lifecycle governance issue, because the permission remains in place after its business purpose has faded. Practitioners should read this as evidence that entitlement review must be tied to enforceable revocation, not periodic visibility reports.

Identity programmes need an action plane, not just an audit plane: The most important named concept here is the visibility-to-enforcement gap. That gap describes the distance between a finding and a safely remediated permission, and it is where most cloud least-privilege programmes stall. Practitioners should design for enforceable closure, not dashboard completeness.

From our research library:

• 91% of organisations say at least half of their privileged access is always-on, and only 1% have fully implemented just-in-time privileged access, according to a CyberArk study.
• Read next: AI Agent Authorisation Guide

What this signals

The visibility-to-enforcement gap is the real control failure in unused-access programmes. Discovery tools can surface dormant AWS permissions, but if revocation stays manual, the finding backlog becomes a risk backlog and least privilege never fully lands.

Visibility-to-enforcement gap: This is the point where identity governance stops being informational and becomes operational. Teams should treat reversible blocking, restore approval, and identity preservation as core design requirements, not as implementation refinements.

For practitioners

• Define an unused-access enforcement path Map which dormant AWS permissions can be blocked centrally, which must remain available, and which require explicit restore approval before they can be re-enabled.
• Separate detection from remediation ownership Assign one team to surface unused access and another to approve and execute revocation so findings do not remain stranded in the review queue.
• Preserve identity structure while revoking privilege Prefer org-level blocking for unused privileged permissions so the role stays intact and restoration does not require re-engineering the identity.
• Validate rare-use dependencies before removal Treat quarterly jobs, disaster recovery roles, vendor workflows, and AI agent triggers as candidate exceptions that need explicit business-owner sign-off.
• Measure remediation throughput against finding volume Track how many findings are closed per review cycle and compare that to the rate at which new unused permissions appear across accounts.

Key takeaways

• Unused AWS access is a governance problem when teams can see dormant permissions but cannot remove them safely at scale.
• The article shows that manual remediation is slowed by ownership, coordination, and rollback constraints rather than by lack of evidence.
• Least privilege becomes real only when organisations pair visibility with enforceable, reversible revocation.

Key terms

• Unused Access: Access that exists on an identity but has not been exercised within a chosen review window. In practice, unused access is not automatically safe, because rare workflows, break-glass use, and undocumented dependencies can keep dormant entitlements operationally relevant.
• Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
• Remediation Backlog: A remediation backlog is the accumulated queue of security issues that have been identified but not yet resolved. In file-centric environments, the backlog grows quickly because each object may require validation, ownership assignment, and a containment decision before risk is actually reduced.
• Org-Level Blocking: A central policy approach that prevents a permission from being used across accounts or identities without rewriting every role individually. It preserves the identity structure while reducing exposure, and it works best when paired with a fast, controlled restore path.

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 building or maturing an IAM programme, it is worth exploring.