What do security teams get wrong when they review IAM risk in AWS?

Why IAM risk reviews in AWS need to follow the access path, not just the policy document

AWS IAM risk is rarely revealed by looking at one control object at a time. A policy that seems harmless in isolation can become dangerous once it is attached to a role reachable from an exposed workload, especially when the role can cross account or assume higher privilege than intended. The real question is whether an attacker, or an unintended workload path, can turn exposure into usable AWS authority.

The review therefore has to connect three things: where the workload is exposed, what role it can assume, and what that role can actually do. That is the difference between noticing a broad permission and understanding whether it is reachable in practice.

What gets missed when teams review IAM and network risk separately

Teams often inspect IAM policies as if privilege were static, then inspect network exposure as if it were only a perimeter issue. In AWS, those are linked. An internet-facing instance, container, or other workload may become the entry point, while the role attached to it determines how far the compromise can move inside the account or across accounts.

That is why role assumption and policy scope matter as much as the initial exposure. A restrictive-looking policy can still be risky if it includes powerful actions through a path the reviewer did not trace, such as pass role, assume role, or access to sensitive infrastructure and secrets.

For AWS-specific review work, that means thinking in terms of effective privilege rather than declared privilege. A role attached to a workload is only safe when its trust policy, permissions policy, and the workload's exposure all line up with the intended blast radius. The Cloud Workload Identity Guide is useful here because it shows how temporary credentials, role assumption, and keyless patterns change the risk picture. The same path logic also shows up in Cloud PAM and CIEM Guide, which focuses on effective permissions and privilege right-sizing.

What a better AWS IAM review actually checks

A useful review starts by asking whether the workload is reachable from outside the trust boundary, then asks which role it can obtain, then asks what that role can access if it is used exactly as designed. That sequence catches the common failure mode where teams approve a permission because it looks narrow, but ignore that the role is available from a publicly reachable system.

It also helps to separate intended access from inherited access. AWS environments often accumulate access through attachment, inheritance, or cross-account trust, so the practical review question is not "is this role allowed?" but "is this role available from a place I do not fully trust, and does it unlock more than that path should permit?"

Good review work often lands on one of three outcomes: reduce the exposure first, narrow the trust relationship, or shrink the role's permissions. The right order depends on which part of the path creates the biggest increase in reachable privilege. If the role cannot be assumed from the exposed system, the risk changes materially; if it can, policy cleanup alone may not be enough.

The AWS pattern is also reflected in broader identity governance work. The Identity Security Programme Guide and IAM and Identity Provider Buyer's Guide both reinforce the idea that governance must cover lifecycle, trust, and privilege together, not as separate review lanes.

Risk and Threat Considerations

When AWS IAM is reviewed in isolation, the main risk is underestimating attack path length. A reachable workload with a permissive role can let an attacker move from exposure to credentialed cloud action without needing to break the AWS control plane itself. That is why role trust, not just permission size, is the critical exposure point.

Failure mechanism: An externally reachable system obtains or is able to use an attached role whose permissions exceed the workload's real trust boundary, allowing privilege escalation, lateral movement, or broader account access.

Impact: The resulting blast radius can include data access, configuration tampering, cross-account movement, or persistence through cloud-native privileges that look legitimate on paper.

Where roles can pass through multiple layers of trust, the risk compounds. A single weak assumption in network exposure, role trust, or policy scope can turn a small foothold into broad AWS control, which is why exposure-to-privilege mapping is more reliable than policy review alone. The AWS-specific escalation path is also well illustrated in 230M AWS environment compromise, where exposed credentials became the entry point to cloud abuse.

Practitioner Guidance

What to prioritise: Start with workloads that are internet-facing or reachable from less trusted networks, then trace which roles they can assume and what those roles can do in the account and any linked accounts. That path-based review usually finds the highest-value fixes faster than a policy-by-policy scan.

What to verify: Confirm the trust policy, the attached permissions, and the workload's actual exposure all describe the same risk boundary. If any one of those three is broader than intended, treat the role as a candidate for restriction even if the individual policy statements look ordinary.

Practitioner takeaway: In AWS, IAM risk is usually a reachability problem disguised as a permissions problem. The best reviewers trace the route from exposure to assumed role to effective privilege, then decide what to cut at the point that most reduces blast radius.

Related resources from NHI Mgmt Group

• What do security teams get wrong when they treat CSPM as enough for application risk?
• What do security teams get wrong when they treat IAM conferences as awareness events instead of control design opportunities?
• What do security teams get wrong when they treat scanner output as a complete risk picture?
• What do security teams get wrong when they rely on authentication logs to understand identity risk?