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.
Editorial analysis by NHI Mgmt Group, based on content published by Apono: “7 Pitfalls to Consider When Configuring IAM:PassRole”.
By the numbers:
- Credential abuse appeared in 22% of analyzed breaches as the top initial attack vector.
Key questions
Q: What breaks when enterprise IAM roles are too broad?
A: Broad roles make access harder to justify, harder to audit, and easier to overuse.
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: How do trust policies and PassRole combine to create escalation paths?
A: PassRole controls who may hand a role to a service, while the trust policy controls whether the role can be assumed at all.
Practitioner guidance
- Tighten PassRole to named role ARNs Replace wildcard delegation with explicit role ARNs so a principal can pass only the roles needed for its service function.
- Bind roles to specific services Use the iam:PassedToService condition so a role created for one service cannot be repurposed by an attacker in another runtime.
- Inventory NHI credentials with delegation rights Identify pipelines, bots, and other machine identities that can pass roles, then remove any standing permission that is not actively required.
Bottom line: IAM:PassRole becomes dangerous when delegation scope is broad enough to let a low-privilege identity attach a more powerful workload role.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
25/06/2026 8:03 am
IAM:PassRole is a delegation control that becomes an escalation control when its scope is wider than the role it is meant to govern. The article shows that the real failure is not PassRole itself but the assumption that delegation is harmless if it is wrapped in familiar IAM syntax. In practice, a principal that can pass a powerful role to a service can shape workload privilege without ever holding that privilege directly. Practitioners should read PassRole as a control over privilege transfer, not a convenience feature.
A question worth separating out:
Q: Should IAM teams prioritise role scoping or monitoring for PassRole abuse?
A: They should do both, but role scoping comes first because it reduces the reachable privilege surface before detection has to work. Monitoring still matters because attackers can hide inside expected automation, especially when services are launched during normal deployment windows. The best outcome is narrow delegation with alerts on anything outside approved workflows.
👉 Read our full editorial: IAM:PassRole misconfigurations create hidden privilege escalation paths
This post was modified 1 day ago by NHI Mgmt Group