7 Pitfalls to Consider When Configuring IAM:PassRole

Nobody breaks into AWS by logging in as root and announcing themselves. They start with something small, such as a leaked key. IAM:PassRole is the kind of permission that creates a clean privilege-escalation path if you’re not watching it closely.

The problem is that IAM:PassRole slips through because it’s not obviously “admin.” It’s a capability that allows an identity to borrow someone else’s privileges, especially when teams scale, and machine identities are granted standing permissions to keep things moving. 

These non-human identities (NHIs) often hold persistent PassRole permissions that manual audits cannot track. When you misconfigure PassRole, you are essentially building an invisible attack path for privilege escalation. But, with credential abuse appearing in 22% of analyzed breaches as the top initial attack vector, you can’t afford to cut corners. 

What is IAM:PassRole? A Quick Overview for AWS Users

IAM:PassRole allows a principal to “pass” an IAM role to an AWS service, such as EC2, Lambda, or ECS.

AWS services don’t automatically get permission to touch your resources. So, you have to give them a role to work with. If you launch an EC2 instance that needs to write to an S3 bucket, you don’t give the EC2 service those permissions directly. You attach an IAM role with S3 access and pass that role to the instance at launch.

It’s vital to distinguish PassRole from AssumeRole:

• AssumeRole is when an identity takes on a role to inherit its permissions directly. 
• PassRole is when an identity assigns a role to a service, allowing the service to perform tasks.

It is a core part of identity and access governance in AWS because you’re defining who can delegate privileges to workloads. Everyday use cases of IAM:PassRole include assigning execution roles to ECS tasks, allowing Lambda functions to access backend resources, or enabling CI/CD pipelines to launch new workloads.

Why are IAM:PassRole misconfigurations a common attack vector?

Misconfigured PassRole permissions are a target because they determine which roles can be used by which workloads. If you don’t scope this correctly, you can unintentionally grant escalated privileges to developers, pipelines, or compromised NHIs.

Most attackers don’t go straight for your most valuable server. They go for the easy win through a low-privilege identity that has both pass roles and launch compute. With IAM:PassRole, plus something like ec2:RunInstances, attackers can create a new instance, attach an admin-level role, and pull the credentials from the instance metadata service.

Machine identities make this easier because they’re often always-on and rarely watched as closely as human users. Furthermore, even a well-scoped PassRole permission can be undermined if the trust policy on the target role is too permissive, allowing unauthorized services to assume it.

PassRole abuse is so difficult to prevent with periodic reviews or static guardrails alone. By the time a risky delegation is discovered, the permission has often already been exercised by a bot or compromised token long before a human ever notices.  At scale, you need automated access control systems that can spot PassRole use outside normal deployment patterns and shrink the window for misuse.

7 Pitfalls to Consider When Configuring IAM:PassRole

1. Granting PassRole Permissions Too Broadly

Broad permissions involve using “Resource”: “*” in a policy instead of naming specific Role ARNs. It is common in “Developer” managed policies designed for speed, where engineers are given a blank check to attach any existing role to a new resource. By failing to specify resources, you allow the user to utilize every identity in the account as a potential stepping stone.

Implications:

• A principal can pass any role in the entire account to a service.
• If the user can launch compute, they can grant themselves AdministratorAccess by passing the most powerful role to a resource they control.
• It removes the primary guardrail meant to stop a single compromised credential from taking over the account.

2. Allowing Roles That Can Escalate to Admin Privileges

Sometimes the problem is that the user can pass a role that has too many permissions. If they can pass roles with AdministratorAccess or PowerUserAccess, they don’t need admin permissions directly. Even with a locked-down user policy, they can still hand an admin role to a service.

Implications:

• The user effectively becomes an administrator because they can create a resource with those powers.
• It creates a bypass for restrictive identity policies that were intended to limit access for that specific user.
• It expands the blast radius of a compromised account to include the entire cloud environment.

3. Misconfigured Trust Policies That Open the Door to Abuse

Misconfigurations occur when a target role has a trust policy (the AssumeRolePolicyDocument) that is too wide, such as trusting an entire account ID or using a wildcard Principal. This stage is where traditional IAM reviews and static policies often fail, especially when most of the identities involved are non-human.

While your PassRole policy may appear secure on the surface, a loose trust policy on the role itself means the receiving end of the delegation remains unprotected. When this architectural gap exists, your security logic effectively stops halfway. You might have restricted the delegation process, but the role’s entry point remains dangerously exposed.

Implications:

• Restricting who can pass the role becomes irrelevant if a weak trust policy allows any authorized service in the account to assume it.
• It invites “confused deputy” scenarios where a legitimate service is tricked into acting on behalf of an unauthorized user.
• The essential security handshake between the delegator and the role is broken, leaving the delegation open to exploitation.

4. Overlooking NHIs Using PassRole

Pipelines and bots often have PassRole access to ensure automation continues smoothly. Because these are not people, they usually miss out on regular security audits and identity lifecycle reviews. These automation accounts often reside in the shadows, holding permanent, high-impact permissions that are vulnerable to exploitation if a secret is ever leaked from a code repository or build environment. 

From an attacker’s perspective, NHIs are the most reliable access brokers in the environment. If your CI/CD secrets aren’t tightly controlled, secret management becomes central to your IAM strategy. 

Implications:

• NHIs lack MFA protection, making them a path of least resistance for attackers.
• A leaked CI/CD token provides a persistent “access broker” for horizontal movement.
• Attackers can use these identities to pass admin roles without triggering standard “new user” alerts.

5. Relying on Long-Lived Credentials With PassRole Permissions

IAM:PassRole shows up in real life in the worst places. It looks like old scripts nobody maintains or credentials on a developer’s laptop. Once PassRole is tied to long-lived credentials, it becomes a permanent privilege. The attacker can return tomorrow, next week, or at any time, and continue passing roles until you shut it down. And, if the key was exposed through a compromised dev tool or dependency, you’re dealing with supply chain risk plus standing privilege. 

Implications:

• Leaked keys provide an indefinite window for an attacker to escalate privileges.
• Unlike session-based access, these keys don’t expire and require manual revocation.
• It increases the presence of “dormant” privileged access on forgotten servers.

6. Not Restricting Which Roles Can Be Passed to Which Services

Failing to restrict roles happens when a policy lacks the iam:PassedToService condition key. It allows a role to be passed to any service principal in the account rather than just the one it was built for. Without this constraint, a role designed with specific guardrails for a Lambda function could be repurposed by an attacker for an EC2 instance, where they have much more interactive control.

Implications:

• A role meant for a restricted Lambda function could be passed to an EC2 instance instead.
• Attackers can move ephemeral permissions into an interactive environment where they have shell access.
• It bypasses the governance of short-lived environments, allowing roles to be used on unauthorized resource types.

Source

7. Lack of Monitoring for Role Use, Abuse, or Drift

As headcount and automation increase, your original access model rarely survives unchanged. If you want to close the gap created by IAM drift, you need detection that flags any PassRole activity that doesn’t match your usual deployment behavior. Otherwise, an attacker can blend in and use PassRole to move laterally without much resistance. Monitoring is one of those areas where teams have to automate processes, as manual reviews won’t catch off-hours role passing reliably.

Implications:

• Leaving permissions “always on” turns a functional tool into a permanent vulnerability.
• Attackers often wait for off-hours to pass roles, knowing detection is less likely when the team is offline.
• You lose the ability to enforce strict deployment windows, which are vital for limiting when role passage can actually occur.

Table 1: PassRole Pitfalls at a Glance

Pitfall	What goes wrong	Why it’s dangerous
1. PassRole is too broad	“Resource”: “*” lets a principal pass any role.	A compromised identity can attach high-privilege roles and escalate fast.
2. Passable roles include admin power	Admin/PowerUser roles are in the “passable” set.	Users/pipelines can indirectly gain admin via a service they control.
3. Trust policy is too permissive	The role trusts wide principals/accounts/services.	PassRole controls are bypassed if the role can be assumed too freely.
4. NHIs aren’t governed	Pipelines/bots keep PassRole with little review.	Stolen tokens become reliable, low-noise escalation paths.
5. Long-lived creds have PassRole	Static access keys retain PassRole indefinitely.	Leaked keys enable persistent privilege escalation until revoked.
6. No iam:PassedToService restriction	Roles can be passed to unintended services.	Attackers can move roles into EC2 for interactive control.
7. No monitoring for PassRole use	PassRole events aren’t tracked or alerted on.	Abuse can happen off-hours or outside deploy windows undetected.

How to Configure IAM:PassRole Safely

Anywhere you see “Resource”: “*”,  assume attackers will eventually abuse it and replace it with specific Role ARNs. Then, you can ensure that staging environments can’t pass or assume production roles, even if someone mis-clicks. 

Keeping an inventory of which humans and NHIs truly need PassRole is a crucial step in getting stricter about trust policies. Of course, you’ll need to delete anything stale. Once you’ve verified that PassRole is time-bound and monitored, it should appear during known workflows, such as break-glass events. The more you can standardize those workflows with clear owners, approvals, and workflow integrations, the harder it is for risky role passing to hide in the noise. If it appears outside of these patterns, especially from NHIs, hit the alarms.  

It’s important to note that Zero Trust isn’t a one-and-done configuration. You can build all these controls with IAM, but enforcing them consistently (especially for NHIs) becomes operationally heavy without automated access control systems.

From IAM Hygiene to Identity-First Control

IAM:PassRole creeps because it’s used for a quick fix, then becomes too convenient. Eventually, it’s a default dependency, especially for automation use cases. Over time, these privilege escalation paths become increasingly difficult to distinguish until attackers target them. 

Apono takes always-on delegation off the table and replaces it with Just-In-Time access. With Apono, access comes hand-in-hand with context and is approved in the workflow and time-bound by default. You’ll get the control and auditability you need for production environments without turning engineering into a ticket queue.

Not sure how much standing privilege still exists in your environment? Start with the Zero Standing Privilege (ZSP) Checklist for a quick self-assessment.Then, when you’re ready to go deeper, download the Apono Privilege Discovery & Remediation Datasheet to see how teams identify and eliminate risky access across both human and non-human identities.