Cross Account Roles

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.

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?