Secure Cross-Account Access is Tricky. Four Common Dangerous Misconceptions

The core of secure cross-account access in AWS is IAM role trust policies. Even technically correct trust policies can open dangerous gaps in an organization’s risk surface.

In this second part of a three-part series about IAM trust policies, we’ll dive deeper into cross-account trust policies, explaining four major misconceptions we repeatedly see in organizations, which often lead to the creation of cross-account trust paths from less secure accounts to more sensitive accounts, unintentionally creating critical privilege escalation pathways. In many cases, this exposes the organization’s most sensitive environments to risk.

Overview: How Cross-Account Access Works in AWS

In our previous blog post, we covered the fundamentals of AWS IAM trust policies and how they define who can assume a role - if you haven’t read it yet, we recommend starting there.

AWS IAM trust policies are the best-practice foundation for cross-account access, providing a secure and scalable way to manage cross-account permissions.

A trust policy specifies who can assume a role, and when it includes a principal from a different AWS account, it establishes a cross-account trust relationship. For example, the following trust policy for a role in AWS account 555555555555 allows another specific IAM role (dev-orchestrator) in 123456789012 to assume it, thereby allowing cross-account access from account 123456789012 to account 555555555555:

"Principal": {  
    "AWS": "arn:aws:iam::123456789012:role/dev-orchestrator"
}

If every AWS account had the same level of security, and all principals within each account were equally secure, cross-account trust wouldn’t be a major risk. But in reality, organizations do not and cannot secure all accounts and all principals equally.

So far, we've covered why cross-account trust inherently extends risk - but how does this play out in real AWS environments? The reality is that not all accounts are secured equally, nor should they be. Organizations prioritize security based on the impact of a compromise. Critical accounts like management and production are typically locked down, while development and sandbox accounts have fewer restrictions - both to facilitate testing and because they are considered lower priority for security. This creates a natural hierarchy of security:

• Management account – controls the entire AWS org, making it the most sensitive
• Production accounts – highly secured, running business-critical workloads
• Security and logging accounts – sensitive monitoring and audit data, typically with moderate security controls
• Development and sandbox accounts – least secure, used for testing and experimentation
• … etc.

Ideally, cross-account trust should align with this security hierarchy. However, in practice, trust policies are often driven by business needs rather than security concerns - sometimes intentionally for convenience, other times due to misconceptions about risk. This leads to trust relationships that contradict the natural security hierarchy, creating hidden privilege escalation pathways.

To understand why this happens, we’ll walk through the four key misconceptions that lead to these security gaps. Each of them builds upon the previous one, compounding the security risks of cross-account trust.

The Four Major Cross-Account Access Misconceptions

Misconception #1: A role trusting an external principal only creates extra risk for that role

Many assume that when a role in Account A allows an external principal from Account B to assume it, the risk is contained to that role. In reality, because roles operate within an account’s broader security model, compromising a single role can expose the entire account to risk.

Reality: A role trusting an external principal extends the risk of its entire account to include the external principal’s risks.

In AWS, roles are rarely isolated. A compromised role can often:

• Assume additional roles within the same account.
• Access sensitive data (S3 buckets, secrets, databases).
• Modify IAM policies, escalating privileges further.

If Account A (555555555555) trusts arn:aws:iam::123456789012:role/dev-orchestrator from Account B, then anyone who gains access to that external role can assume it and operate inside Account A. From there, they can pivot within all of Account A, exploiting additional IAM policies, enumerating permissions, and escalating privileges.

This means trusting an external principal doesn’t just put one role at risk - it can lead to compromise of the entire trusting account.

Misconception #2: Trusting a specific principal means extending the risk only to that principal

A common but dangerous assumption is that trusting a specific role or user in another account ensures risk is contained to just that principal. In reality, the trusting account has no actual way to enforce how that principal is secured within the trusted account - meaning that trusting a principal effectively means trusting the entire account it belongs to.

Reality: When you trust an external principal, you effectively trust their entire account.

When Account A allows arn:aws:iam::123456789012:role/dev-orchestrator from Account B to assume a role, it is implicitly relying on Account B’s security to enforce best practices for that role. If Account B has weak controls - such as permissive IAM policies, overprivileged users, or poor monitoring - then Account A has inherited those risks, whether it realizes it or not.

More critically, any principal in Account B that can assume dev-orchestrator effectively gains access to Account A. For example, if an attacker compromises a permissive identity in Account B, they could modify IAM policies to grant themselves access to dev-orchestrator, assume it, and then pivot into Account A. In many cases, the attacker doesn’t even need to modify any policies - the trusted role might already allow access from other principals in the same account by design. Compromising any one of those principals can be enough to pivot into the trusting account.

Because of this, organizations must assess not just which principals they are trusting, but how secure the entire trusted account is. A single compromised account with cross-account access to a sensitive environment can serve as an entry point for an attacker, enabling unexpected privilege escalation. This is why trusting a less secure account is inherently dangerous - you may be introducing an attack path without realizing it.

(For a deeper analysis of why trusting a principal effectively trusts the whole account, Ben Kehoe wrote two excellent posts about it)

Misconception #3: The “billing” account is mainly administrative and not that sensitive

One of the most critical security mistakes organizations make is underestimating the security importance of the management account. Because its main function is billing and organization-wide administration, many teams treat it as an administrative account rather than a high-risk security asset. I’ve heard the sentence, “It’s just the billing/payer account; production is more important," more times than I care to admit.

Reality: If the management account is compromised, an attacker can take control of every other AWS account in the org.

Since the management account has absolute control over the entire AWS organization, it is by design the most sensitive account. Yet, many organizations apply stricter security to their production accounts than to their management account, which is entirely backwards in terms of risk.

Misconception #4: Cross-account trust can safely flow in any direction

The final misconception, that builds on top of all the previous ones, is one of the most dangerous yet common mistakes organizations make: granting cross-account trust from less secure environments into highly sensitive accounts. This often happens for convenience - DevOps, IT, or automation teams set up cross-account access without fully considering the security implications of trust flowing in the wrong direction, thinking that as long as they specify a specific principal trusted in the trust policy, it’s safe. A single trust policy configured this way can be catastrophic.

Reality: Allowing a less secure account to assume a role in a more sensitive account creates an easy privilege escalation path for attackers.

For example:

• If a role in a dev account is granted access to a permissive role in production, then an attacker who compromises the dev account can pivot into production.
• If a role in the management account trusts a role in a lower-security account, a compromise in that lower-security account could lead to a full AWS org takeover.

This issue is compounded by the misconception that trusting a specific principal in a low-security account is safe. As covered earlier, trusting a principal means trusting the entire account - so if the lower-security account is compromised, an attacker can assume the trusted role and escalate into the sensitive account. I’ll show a powerful example of this in the next post.

Closing Thoughts

Cross-account security is a design problem, not just a configuration problem. Organizations must go beyond simply setting up trust policies correctly and think critically about where they are extending trust and how secure those accounts actually are, following two key rules:

1. The management account must be the most secure in the organization
2. Less secure accounts should never have cross-account access to more sensitive accounts - cross-account access should only be downstream in the security and sensitivity hierarchy of accounts.

Next up: a real-world example

In the next and last part of the series, we’ll share how even AWS themselves got secure cross-account access wrong in a tool they published. We’ll share how we discovered it, the security risks it introduced, how AWS fixed it quickly, and how affected organizations should remediate the issue.

‍