Cross account roles let one identity in a source account assume a role in another account to access specific resources. In IAM, this is usually implemented with trust policies and temporary credentials, enabling controlled delegation across cloud boundaries while reducing long-lived secret exposure and supporting least privilege.
How Cross Account Roles Work
Cross account roles are a delegation pattern, not a permanent permission grant. One account keeps ownership of the role definition while a trusted principal from another account can assume it and receive temporary credentials for the allowed actions.
This design matters because the trust boundary is explicit. The source identity does not inherit broad standing access into the target account; instead, access is brokered through a role that can be constrained by trust policy, session duration, conditions, and the permissions attached to the target role.
Why Cross Account Roles Matter for Security
Cross account roles reduce the need to share long-lived keys across accounts and help keep access scoped to the specific resource or workflow. They are often used for platform operations, automation, incident response, and controlled third-party access where direct user accounts would be harder to govern.
Because the mechanism relies on trust between accounts, it can also create a high-value path if the trust policy is too broad or the role permissions are excessive. A mistake in either account can turn a narrow delegation path into a larger blast radius than intended.
Common Design Patterns and Failure Modes
The most common pattern is an identity in a source account assuming a target role through a service such as STS, then using temporary credentials until the session expires. The target account controls what that role can do, while the source account controls who may invoke the assumption path.
Failure usually comes from one of three places: overly broad trust, overly broad role permissions, or poor visibility into who is assuming which role and why. Role chaining, wildcard principals, and condition-less trust statements are frequent sources of unintended access expansion.
Cross account roles also intersect with identity governance because the effective access is distributed across two accounts. If the source identity is not reviewed and the target role is not monitored together, privilege creep can survive ordinary access reviews.
Where Cross Account Roles Fit in Cloud IAM
Cross account roles are one of the core building blocks of cloud delegation. They are used when teams want separate administrative domains, shared services, workload isolation, or controlled access between business units without merging accounts or duplicating credentials.
In practice, they sit alongside cloud permission analysis, trust relationship review, and least privilege design. The security outcome depends on how carefully the trust path is bounded, not just on the role policy itself. AWS IAM policies and roles provides a broader view of role trust, chaining, and permission boundaries, while Cloud PAM and CIEM Guide connects cross account trust to privilege right-sizing and cloud entitlement control.
Risk and Threat Considerations
Cross account roles can create an outsized trust risk when the target role is easier to abuse than the source identity is to compromise. Attackers often pursue role assumption because it can bypass static key theft, blend into normal cloud administration, and widen access across accounts once a trusted path is found.
Failure mechanism: Broad trust policies, weak conditions, or excessive target permissions let an attacker or mistaken operator convert one assumed role into durable cross-account reach, especially when sessions are not tightly constrained or monitored.
Impact: The result can be lateral movement between cloud accounts, unauthorized resource access, privilege escalation, and delayed detection because the activity looks like legitimate delegation rather than direct login abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cross-account roles are a cloud IAM delegation pattern. |
| Recommendation — Constrain cross-account trust paths and review delegated cloud access under IAM. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Cross-account roles should grant only the minimum actions needed after assumption. |
| IA-9 — Service Identification and Authentication | Temporary cross-account assumption depends on authenticated service-to-service or role-to-role trust. | |
| Recommendation — Limit assumed-role permissions to the smallest set of required actions. Use strong authenticated trust for role assumption and constrain the trust relationship. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Cross-account roles are an access-control mechanism that needs policy governance. |
| Recommendation — Define and review cross-account access rules as controlled access policies. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Cross-account roles affect account and privilege management across cloud boundaries. |
| Recommendation — Inventory and review delegated cross-account access paths and remove stale trust. | ||
Practitioner Guidance
Governance implication: Treat the source identity, the trust policy, and the target role as one control surface. Access reviews should ask not only who can assume the role, but also what the role can do after assumption and whether the trust path is still justified.
What to watch for: Reused cross-account patterns, role chaining, wildcard trust, and roles that outlive the original project or integration are common signs that delegation has outgrown its intended scope. Federation and trust relationships is useful for understanding how trust can persist and spread when relationship boundaries are not kept tight. Google Cloud IAM and Service Accounts Guide also shows how temporary credentials and impersonation fit into tighter delegation models.
Related resources from NHI Mgmt Group
- Why do cross-account roles increase privilege escalation risk in AWS?
- How should security teams prevent external identities from assuming AWS IAM roles without creating cross-account access risk?
- How should security teams investigate cross-account access paths when AWS API keys or assumed roles may reach production?
- What are common mistakes with cross-account roles?