Role passing is the ability to assign an IAM role to another AWS service, such as EC2 or Lambda, so that service can act with the role’s permissions. It is a sensitive control because a caller may use a trusted service as a bridge to capabilities they do not directly hold.
What Role Passing Is
Role passing is an AWS IAM pattern where one service is allowed to assume a role so it can perform actions on behalf of the caller. The security significance is that the service becomes a delegated access path, not just a workload component.
How Role Passing Works
In practice, role passing links a caller, a trusted AWS service, and the permissions attached to the role. The caller does not need the permissions directly, but the service can act with them once trust and delegation are established.
This makes role passing different from simple role assignment in a console or user session. The key question is whether the service is truly meant to hold that authority, and whether the trust relationship is narrow enough to prevent unintended use.
Because the role is used by a service, the effective permission boundary is often shaped by the service trust policy, the attached permissions, and any constraints on how the service may invoke the role.
Why Role Passing Matters for Access Control
Role passing is a delegation mechanism, so it sits close to least privilege and separation of duties. If the wrong service can receive the role, the access model can shift from intended delegation to indirect privilege expansion.
That is why role passing is often evaluated alongside broader access-control design, including how permissions are scoped and how trust is established. NIST Cybersecurity Framework 2.0 is useful here because it frames governance, access protection, and recovery as connected control outcomes rather than isolated settings.
For services that call other services, the distinction matters: the delegated role should reflect only the work the service must do, not everything the caller might want to reach indirectly.
Common Failure Modes and Misuse Cases
The main failure mode is overtrust. If a caller can pass a powerful role to a broadly trusted service, the service becomes a bridge to permissions that were never meant to be widely reachable.
Another common issue is configuration drift, where a role starts narrow but later accumulates permissions while its trust path remains unchanged. That combination creates a quiet escalation path that may survive long after the original design intent has been forgotten.
Role passing also becomes risky when teams treat “trusted AWS service” as automatically safe. A trusted service can still be used in a way that enlarges effective access, especially if the role itself is overprivileged or the trust policy is too permissive. NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant because it ties authorization, privileged access, and control discipline to the broader access-control model.
Where It Fits in AWS Security Design
Role passing is most useful when automation needs bounded authority. A service such as EC2 or Lambda may need to call other AWS capabilities, and a role gives it an auditable way to do that without embedding long-lived credentials in the application itself.
That convenience does not reduce the need for design discipline. The role should be specific, the service trust should be explicit, and the permissions should be narrowly scoped to the service’s task. NIST Cybersecurity Framework 2.0 and CIS Benchmarks both reinforce the same practical idea: reduce unnecessary access paths and keep control settings aligned with intended use.
In mature environments, role passing is therefore not just an implementation detail. It is part of the broader access architecture that determines whether services can operate safely without becoming privilege shortcuts.
Risk and Threat Considerations
Role passing can create an indirect privilege-escalation path when a caller can route authority through a trusted service that has broader permissions than the caller should ever hold. The risk is greatest when trust policies are broad, roles are overprivileged, or service boundaries are poorly understood.
Failure mechanism: A service that is allowed to assume a role becomes an access bridge, and the caller can exploit that bridge to reach actions or resources that are otherwise out of scope.
Impact: Unauthorized data access, privilege expansion, and unintended control of downstream AWS resources can follow, especially when the delegated role can modify infrastructure or security settings.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Role passing depends on narrow delegated access and permission scoping. |
| GV.RM-01 — Risk Management Strategy | Role passing creates a trust and escalation risk that needs governance. | |
| Recommendation — Scope delegated service permissions to the minimum actions needed. Classify role-passing paths as risk-bearing trust relationships and review them. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Role passing can expand effective access beyond the caller's direct permissions. |
| IA-5 — Authenticator Management | Role passing relies on managed trust material and controlled delegation paths. | |
| Recommendation — Apply least privilege to every role that a service can assume. Protect and rotate the credentials and trust material that enable delegation. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Role passing is an access-control mechanism that must be provisioned and reviewed. |
| Recommendation — Review service-to-role grants and remove any unnecessary access paths. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Role passing is an IAM delegation pattern in cloud environments. |
| Recommendation — Define explicit trust and authorization boundaries for every delegated role. | ||
Practitioner Guidance
Governance implication: Treat role passing as a delegated-authorization decision, not a convenience feature. The role should be owned, reviewed, and scoped like any other privileged access path, with the trusted service and permitted actions kept tightly aligned to the business function.
What to watch for: Review any place where a service can receive a role that is more powerful than the initiating principal. If the service can act across accounts, manage infrastructure, or reach sensitive data, that delegation path deserves the same scrutiny as direct privilege assignment.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
