Notifications
Clear all
Topic starter
24/06/2026 11:17 pm
TL;DR: IAM:PassRole can turn a low-privilege AWS identity into an escalation path when broad resource scope, permissive trust policies, or standing NHI permissions let attackers attach higher roles to workloads, according to Apono. The real failure is assuming delegation is harmless when it can outlive review windows and bypass human-paced IAM controls.
NHIMG editorial — based on content published by Apono: 7 Pitfalls to Consider When Configuring IAM:PassRole
By the numbers:
- 22% of analyzed breaches used credential abuse as the top initial attack vector.
Questions worth separating out
Q: How should security teams restrict IAM:PassRole in AWS environments?
A: Security teams should restrict PassRole to explicit role ARNs, pair it with service-specific conditions, and keep the target role trust policy narrow.
Q: Why do standing NHI permissions make PassRole abuse more dangerous?
A: Standing NHI permissions make PassRole abuse more dangerous because the access path stays available after the workflow that justified it has changed.
Q: What breaks when AWS trust policies are too permissive?
A: When AWS trust policies are too permissive, the role’s receiving side no longer controls who can assume it.
Practitioner guidance
- Tighten PassRole to named role ARNs Replace wildcard resource scope with explicit role ARNs and separate staging from production delegation so a compromised identity cannot attach high-value roles by default.
- Bind roles to specific services Use iam:PassedToService conditions so a role created for Lambda cannot be reused on EC2 or another more interactive service that gives an attacker a richer control surface.
- Review trust policies with the same rigor as PassRole policies Check the role trust boundary for broad account IDs, wildcard principals, and over-permissive service trusts because the receiving side can undo an apparently strict pass policy.
What's in the full article
Apono's full analysis covers the operational detail this post intentionally leaves for the source:
- Specific PassRole policy examples showing how broad resource scope creates escalation paths in AWS.
- Practical guidance on using iam:PassedToService to keep delegation tied to the intended workload type.
- Examples of how trust policies and PassRole policies can fail together in confused deputy scenarios.
- Discussion of how automation accounts and standing credentials turn PassRole into a persistent risk.
👉 Read Apono's analysis of IAM:PassRole pitfalls in AWS →
IAM:PassRole and hidden escalation paths in AWS environments?
Explore further
25/06/2026 8:03 am
PassRole is not a convenience permission, it is a delegation boundary. The article shows that the control only stays safe when both the delegator and the target role are tightly constrained. Once either side is broad, PassRole becomes a route for privilege inheritance rather than a bounded workflow step. For IAM teams, that means treating delegation scope as an enforceable security property, not an administrative detail.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
A question worth separating out:
Q: How do teams know whether PassRole is being abused?
A: Teams know PassRole is being abused when role-passing activity appears outside normal deployment patterns, comes from unexpected identities, or creates workloads that later request stronger access. Monitoring should focus on unusual service combinations, off-hours delegation, and workloads that inherit more privilege than their normal job requires.
👉 Read our full editorial: IAM:PassRole misconfigurations create hidden privilege escalation paths
