Why do cross-account roles increase privilege escalation risk in AWS?

Why This Matters for Security Teams

Cross-account roles are powerful because they turn trust into access, and that trust often spans security boundaries that were never designed to fail together. Once a principal from a weaker account can assume a role in a more sensitive account, the attacker no longer needs to break the stronger perimeter first. That is why cross-account design must be treated as a privilege escalation path, not just an administrative convenience.

This risk is especially visible in environments where secrets, CI/CD systems, automation jobs, or machine identities can reach role assumption APIs. NHIMG research on the Ultimate Guide to NHIs — Key Challenges and Risks shows how non-human trust relationships become a primary attack surface when identity sprawl outpaces governance. The OWASP Non-Human Identity Top 10 also treats over-permissive trust as a recurring failure mode, especially when roles can be chained without strong session controls.

In practice, many security teams discover the weakness only after a compromised workload, leaked token, or third-party account has already pivoted into production.

How It Works in Practice

In AWS, a cross-account role works through a trust policy that says which external principal may assume the role, usually via AWS STS AssumeRole. The trust policy is the gate, and the permission policy on the role defines what happens after entry. If the trusted account is compromised, the attacker can often reuse that trust relationship exactly as designed.

The escalation risk increases when the assumed role has permission to call sts:AssumeRole again, read secrets, pass roles to services, or access sensitive data stores. In that case, one foothold can become a chain of privilege expansion across accounts, especially if the attacker can enumerate role names or discover overly broad trust conditions. This is why AWS guidance on IAM roles and least privilege must be paired with explicit boundary design. NHIMG’s 230M AWS environment compromise and Codefinger AWS S3 ransomware attack coverage both illustrate how quickly exposed cloud trust can become an operational incident.

• Restrict trust policies to specific principals, not broad account-wide patterns.
• Use external ID, session tags, and conditions where applicable to reduce ambiguous trust.
• Limit the permissions on the role itself, because trust and permissions are separate controls.
• Continuously review whether the trusted account can itself be considered high risk.
• Prefer short session durations and monitor role chaining aggressively.

These controls tend to break down when organizations inherit large numbers of legacy roles with broad trust relationships and no reliable inventory of who can actually assume them.

Common Variations and Edge Cases

Tighter trust policies often increase operational overhead, requiring organisations to balance convenience against the need to prevent lateral movement. That tradeoff becomes especially sharp in multi-account platforms, managed service integrations, and vendor access patterns where teams want reusable access but need compartmentalization.

Current guidance suggests that the highest-risk edge case is not a single cross-account role, but a role that can be assumed by identities with weak lifecycle controls, such as long-lived access keys, CI/CD runners, or third-party automation. In those cases, the account that appears “less sensitive” may actually be the easiest path into the crown jewels. NIST’s Cybersecurity Framework 2.0 helps teams frame this as a governance and detection problem, not just an IAM configuration problem. The same pattern aligns with NHIMG’s Top 10 NHI Issues, where inherited trust and poor visibility repeatedly show up as escalation enablers.

There is no universal standard for this yet, but the practical direction is clear: treat every cross-account trust path as a potential blast-radius multiplier, validate it against real attacker paths, and retire any role that exists only because it was easier than designing a narrower control. In mixed cloud estates, this guidance breaks down when identity evidence is fragmented across teams and no one can prove which principals still need the trust relationship.

Related resources from NHI Mgmt Group

• Why do Salesforce integrations increase NHI risk?
• Why do delegated AI agent workflows increase privilege escalation risk?
• Why do Windows and Azure privilege-escalation bugs increase lateral movement risk?
• Why do delegated managed service accounts increase privilege escalation risk in Active Directory?