Cross-account AssumeRole requires two independent policy evaluations: the identity policy on the source principal must allow sts:AssumeRole on the target role ARN, and the trust policy on the target role must allow the source principal. When either evaluation fails, the action is denied. When both permit, the action succeeds — but the authorization boundary is only as strong as the weakest policy.The trust policy serves as the target account's explicit statement of which external principals it authorizes. This makes trust policy configuration a primary control that determines whether account boundaries provide meaningful isolation. When trust policies are too permissive or lack sufficient conditions, the account boundary weakens as a security control — though the actual exploitability of any given misconfiguration depends on additional factors including the source principal's own permissions, session policies, permission boundaries, and organizational controls.Organizations discover this gap when privilege escalation paths cross account boundaries through misconfigured trust relationships. An identity with limited permissions in one account can assume a highly privileged role in another account if the trust policy permits it and the source identity holds the necessary sts:AssumeRole permission — even when an equivalent escalation would be impossible within a single account's permission structure.
Trust policy as authorization boundary
The dual-policy model creates two distinct failure modes: identity policies that are too permissive, and trust policies that are too permissive. Standard IAM review focuses on identity policies — what permissions an identity has been granted. But cross-account access depends equally on trust policies — which external identities a role permits to assume it.Trust policy evaluation happens on the target side. When an identity attempts to assume a cross-account role, AWS evaluates the trust policy of that role to determine whether the calling principal is authorized. This evaluation is independent of the identity policy evaluation on the source side. Both must permit for the action to succeed.The authorization boundary shifts from identity-centric to resource-centric. Within an account, the question is "what can this identity do?" Cross-account, the question becomes "what external identities can assume this role?" The trust policy answers the second question — and when that answer is too broad, account isolation breaks down.Trust policies that specify broad principals create meaningful security gaps. A trust policy that allows "arn:aws:iam::ACCOUNT:root" does not grant assumption privileges to every identity in the external account unconditionally — rather, it delegates authorization back to that account's own identity policies, allowing any principal in that account that has been explicitly granted sts:AssumeRole on the target role ARN to attempt assumption. This distinction matters: the account root principal specification is permissive, but exploitation still requires the source principal to hold appropriate identity policy permissions. The practical risk is that the target account cedes control over which specific principals may assume the role, making the trust relationship contingent on the external account's internal access controls remaining sound.
How trust boundaries fail
Three configuration patterns create exploitable trust boundaries: overly broad principal specifications, missing condition keys, and stale external account references.Trust policies that reference account root rather than specific role ARNs allow any identity in the external account with appropriate sts:AssumeRole permissions to assume the target role. Organizations create this misconfiguration when they want to grant access to multiple identities in an external account and choose the broad "root" principal rather than listing specific role ARNs. The operational consequence: new identities created in the external account can inherit cross-account access without explicit re-authorization from the target account, provided they are granted AssumeRole in their own account's policies. Actual exploitability depends on how tightly the external account controls that grant.Trust policies without condition keys make the trust relationship exploitable by any principal that matches the principal statement and holds the required source-side permissions. Common missing conditions include IP address restrictions, MFA requirements, session duration limits, and external ID requirements for third-party access. Without conditions, the trust relationship provides access to any identity that matches the principal specification and has the required grants — regardless of how that identity was compromised or who controls it at any given time.Trust policies that reference external accounts that are no longer under organizational control create dormant access paths. When an external AWS account leaves organizational control through closure, transfer, or termination of a business relationship, trust policies referencing that account ID do not automatically update. It is worth noting that AWS account identifiers are not generally reused or re-registered by new parties in the way that domain names or IP addresses can be, which limits the scope of this risk compared to analogous problems in other contexts. However, the risk is real in scenarios involving account takeover or compromise of a transferred account, where an attacker who gains control of a previously trusted account inherits all trust relationships referencing that account ID. Organizations should treat account relationship termination as a trigger for trust policy cleanup regardless of assumptions about account ID permanence.The operational challenge: trust policy failures are invisible from standard identity-centric permission reviews. Identity policy analysis shows what permissions an identity holds within its account. It does not reveal which external accounts trust that identity or what permissions those trust relationships provide. A seemingly low-privilege identity may have cross-account access through trust policies that are not visible from identity-centric audit tools — though the effective access through those trust relationships is also constrained by session policies, permission boundaries, and SCPs that apply in context.
The confused deputy problem
The confused deputy attack exploits AWS services that act on behalf of external principals without sufficient verification of the principal's intent. When a third-party service holds cross-account role assumption privileges, a customer of that service who knows a target role ARN may be able to trick the service into assuming the role on their behalf — provided the trust policy lacks the appropriate safeguards.The attack structure: a security vendor is granted cross-account access to audit customer environments. The vendor's service assumes a role in each customer account using the vendor's AWS account as the trusted principal. Customer A configures a trust policy that allows the vendor's account to assume an auditing role. Customer B, who is also a customer of the same vendor, learns the ARN of Customer A's role and attempts to configure their own audit to target Customer A's account.If the trust policy lacks an external ID condition, the vendor's service may successfully assume Customer A's role on behalf of Customer B — granting Customer B unauthorized access to Customer A's environment. Whether this succeeds in practice also depends on how the vendor's service constructs its AssumeRole calls and whether it enforces its own controls on customer-supplied parameters.AWS documentation on IAM role trust policies identifies the external ID condition as the mechanism for preventing confused deputy attacks when granting cross-account access to third parties — noting that without an external ID condition, any customer of a third-party service that holds a role ARN could potentially cause the third-party service to assume the target role, gaining access the target account did not intend to grant to that customer (Source: docs.aws.amazon.com).The external ID functions as a shared secret between the target account and the third-party service. When configuring cross-account trust for third-party access, the target account generates a unique external ID and provides it to the third party. The trust policy includes a condition that requires the external ID to be present in the assume role request. This prevents other customers of the third party from successfully assuming the role because they do not know the required external ID.The vulnerability window: trust relationships configured without external IDs remain exploitable as long as the attack conditions — a shared third-party service and a discoverable role ARN — are present. Adding an external ID condition to an existing trust policy is a breaking change that requires coordination with the third party to update their assume role requests. Organizations often delay this remediation, leaving confused deputy vulnerabilities in place for extended periods.
Organization trust and SCP limits
Service Control Policies (SCPs) provide guardrails on cross-account trust by restricting which actions trusted identities can perform after assuming cross-account roles. SCPs apply to all principals within an organizational unit, including principals that assumed roles from external accounts. This creates a secondary control layer that can meaningfully reduce the impact of overly permissive trust policies — though SCPs are one of several relevant controls, alongside permission boundaries, session policies, and explicit deny conditions that together shape effective access.SCPs limit what trusted identities can do; they do not fix who the trust policy allows to assume the role. An SCP that denies iam:* actions prevents trusted cross-account identities from modifying IAM resources, but it does not prevent an overly broad trust policy from allowing unintended principals to assume the role within the SCP's allowed action set. The trust policy principal specification remains the primary authorization control for determining who can assume the role at all.The operational tradeoff: restrictive SCPs can significantly reduce the blast radius of cross-account trust misconfigurations and represent a meaningful defense-in-depth layer. However, SCPs designed to limit cross-account trust can also interfere with legitimate cross-account automation if not carefully scoped. The preferred approach prioritizes trust policy correctness — specific principal ARNs, appropriate condition keys, and regular review — rather than relying on SCPs as a primary compensating control for weak trust policies.SCP evaluation happens after successful role assumption. If a trust policy allows an unintended principal to assume a cross-account role, the SCP evaluation occurs within the context of the assumed role's permissions and the organizational unit's SCP constraints. This means SCPs can reduce the impact of trust policy misconfigurations but cannot prevent unauthorized role assumption itself.MITRE ATT&CK technique T1199 (Trusted Relationship) identifies exploitation of trusted third-party relationships as an initial access and lateral movement technique, noting that adversaries may use established trust relationships — including cloud cross-account access granted to security vendors, MSPs, or business partners — to access target environments without exploiting a technical vulnerability, instead abusing the trust that the target organization has legitimately extended (Source: attack.mitre.org). Practitioners should note that T1199 describes a class of techniques; specific exploitability in any environment depends on the combination of trust policy configuration, source principal permissions, and the organizational controls described above.
What cross-account visibility requires
Cross-account trust inventory requires querying IAM APIs across all accounts in the organization. Single-account permission analysis cannot reveal which external accounts trust a given identity or what permissions those trust relationships provide. Organizations with dozens or hundreds of accounts cannot manually audit trust policies — the governance program must include automated cross-account trust policy discovery and validation.The governance program must answer four questions about cross-account trust: which roles in each account trust external principals, what external accounts those principals belong to, whether those trust relationships are still intentional and correctly scoped, and whether trust policies include appropriate condition keys for the type of access granted.Trust policy inventory must include both IAM role trust policies and resource-based policies that grant cross-account access. S3 bucket policies, Secrets Manager resource policies, Lambda function policies, and other resource-based policies can grant cross-account access directly without requiring role assumption. These resource-based grants are evaluated independently of account IAM role policies and may not be captured by role-based trust policy audits, making them a common gap in cross-account access reviews.The operational validation requirements: trust policy principals should specify exact role ARNs rather than account root principals where feasible; third-party trust relationships should include external ID conditions; trust policies should include appropriate session conditions for IP addresses, MFA, and session duration based on the sensitivity of the access granted; and trust relationship cleanup should happen as part of standard offboarding when external accounts leave organizational control or when business relationships end.Organizations can implement continuous trust policy validation through automated scanning that flags overly broad principals, missing external IDs for third-party relationships, and trust policies referencing accounts not on an approved external account list. The automation should run across all accounts in the organization and alert when new trust relationships are created or when existing relationships violate established trust policy standards. Automated discovery surfaces the trust relationships that require human judgment about intent and continued necessity — it does not replace that judgment.
Cross-account trust failure modes
Trust failure
How it is created
What it enables
Why standard permission review misses it
Overly permissive trust principal
Trust policy allows "arn:aws:iam::ACCOUNT:root," delegating authorization to the external account's internal policies rather than specifying a particular role ARN
Any identity in the external account that holds sts:AssumeRole permissions on the target role can assume it, including identities created after the trust relationship was established
Identity-centric permission review shows what the external identity can do within its own account, not what cross-account roles it can assume through trust policies
Missing or unused external ID
Trust policy for third-party cross-account access lacks external ID condition, enabling potential confused deputy attacks where service implementation and customer knowledge of ARNs create the conditions
Under appropriate conditions, another customer of the same third-party service who knows the role ARN may be able to cause the service to assume the role on their behalf
Trust policy conditions are evaluated on the target account side and are not visible from source identity permission analysis
Trust policy references an external account no longer under organizational control
Misconfigured trust references an account that has been transferred, compromised, or otherwise left organizational control, and cleanup was not performed
An attacker with control of the external account can assume roles in the target account using identities in that account that hold the required AssumeRole permissions
External account ownership verification is not part of standard identity permission audits, which focus on internal account principals
Resource-based policy grants cross-account access without corresponding identity policy
S3 bucket, Secrets Manager, or Lambda grants access to an external principal directly
External principal can access the resource directly without assuming any IAM role, making the access invisible to role-based permission analysis
Resource-based policies are evaluated independently of IAM role permissions and are not captured by identity-centric audit tools