Cross-Account Access

Understand which AWS identities or resources are reachable across account boundaries and whether the trust is appropriately constrained.

Enterprise AWS architectures intentionally use multiple accounts. Cross-account access can support central security, shared services, deployment pipelines, backup, data platforms, vendors, partners and managed services. The security goal is not to eliminate cross-account access — it is to understand who is trusted, what they can reach, and whether the trust is appropriate.

Where to find Cross-Account Exposure

The current view is named Cross-Account Exposure. Depending on the finding and evidence, the view can help investigate context such as source account, target or external account, affected role, whether External ID protection is represented, whether an MFA-related trust condition is represented, and severity.

For deeper trust analysis, also use:

• Exposure → Trust Policies
• Exposure → Resource Policies
• Exposure → Federation

Cross-account trust

An AWS IAM role trust policy controls which principals may participate in assuming the role.

Account A
  │
  │ external principal
  ▼
Role in Account B

The role's trust policy may allow a principal associated with Account A. However, successful role assumption can still depend on the caller's own permissions and the conditions in the trust relationship.

Example: intended shared-services access

This may be entirely legitimate. A cross-account relationship becomes more concerning when:

• the external principal is unexpected
• trust is broader than necessary
• conditions are missing or weak
• a wildcard principal is used
• the role is highly privileged
• the relationship points to sensitive resources
• ownership of the external account is unclear

External principals

An external principal can be another AWS account, a role in another AWS account, or another supported external AWS principal. Security teams should establish whether the principal is:

Known and approved

For example, a central platform account, security account or approved vendor account. These relationships are expected and may not require remediation beyond periodic review.

Known but overly broad

The external relationship is legitimate but its permissions or trust scope should be narrowed. Common remediation is to add conditions or reduce the role's permission scope.

Unknown

The organization cannot readily explain why the trust exists. Unknown external trust deserves investigation before any decision is made.

External ID

External ID is commonly used in third-party cross-account role assumptions to help protect against the confused-deputy problem.

Customer Role Trust
  ↓
Expected External Principal
  +
Expected External ID
  ↓
STS AssumeRole request

Organization restrictions

AWS trust relationships can sometimes be constrained using organization-aware conditions such as organization identifiers. This can be useful when the intended trust boundary is “any approved principal from our AWS Organization” rather than “any AWS account.”

Where supported, Securitain can use organization-related trust context to help distinguish constrained relationships from broader exposure. Not every trust relationship must use the same organization condition.

MFA conditions

Some role-assumption workflows can require MFA-related conditions. This can be useful for specific human administrative workflows. However, workload-to-workload access generally cannot be evaluated using the same human MFA expectation. MFA should therefore be interpreted according to principal type and access purpose.

Wildcard principals

A trust or resource policy using Principal: "*" can create broad exposure depending on resource type, action, conditions, public-access controls and service behavior.

Cross-account role trust vs resource-policy access

Cross-account access can be created in different ways.

External Principal
  ↓ AssumeRole
Role
  ↓
Role permissions

External Principal
  ↓ Resource Policy
S3 / KMS / other resource

These should be analyzed separately. Use Exposure → Resource Policies when the cross-account access is granted directly by a supported resource policy rather than through role assumption.

Cross-account trust vs federation

Federation can also create external identity relationships. Examples include OIDC, SAML, IAM Identity Center and CI/CD identity providers. Use Exposure → Federation when the trust originates from an external identity provider rather than another AWS account principal.

Example: third-party vendor role

Suppose a vendor needs operational access. A simplified trust pattern may be:

A security review should ask:

• Is the vendor account known?
• Is the role scoped to the required resources?
• Does the trust include appropriate conditions?
• Is External ID appropriate for this relationship?
• Is the role more privileged than necessary?
• Is the relationship still required?
• Is there an owner?
• Is access reviewed periodically?

Securitain helps surface the technical trust so the organization can answer those governance questions.

Example: unknown external trust

Suppose:

Production Role
  ↓ trusts
Unknown AWS Account

The first response should not be to delete the trust immediately. Instead, investigate:

1. 1

   Identify the external account

   Determine ownership. The account ID may help map to a known vendor, internal team or partner.

2. 2

   Review the role

   Understand the role's effective permissions and blast radius. A broadly privileged role with unknown trust deserves urgent attention.

3. 3

   Review conditions

   Look for restrictions such as External ID, organization constraints, source conditions or MFA where appropriate.

4. 4

   Review activity

   Where activity evidence is available, determine whether the relationship is in use.

5. 5

   Confirm business purpose

   Identify the team, integration or vendor responsible for the trust.

6. 6

   Remediate or govern

   If unauthorized, remove or restrict the trust. If legitimate, document ownership and apply appropriate constraints.

Cross-account exposure and blast radius

Cross-account trust becomes more important when the target role has substantial capability.

This is why cross-account analysis should be connected to identity consequence rather than evaluated only as a binary trust-policy check. Use the IAM Blast Radius view to understand the potential consequence of the trusted role.

Cross-account exposure and attack paths

Cross-account relationships can also participate in broader attack paths. Multi-account environments can therefore create security paths that are difficult to understand account by account.

Use the Relationship Graph and Privilege Escalation views for deeper investigation when cross-account relationships may participate in an escalation path.

Investigating a cross-account finding

1. 1

   Identify the source and target accounts

   Establish ownership of both sides. The account IDs can help map to known teams, vendors or environments.

2. 2

   Identify the principal or resource

   Determine whether the relationship involves a role, a resource policy or another supported object.

3. 3

   Review trust conditions

   Look for the controls appropriate to the use case — External ID for third-party access, organization constraints for internal cross-account access.

4. 4

   Review role permissions

   Determine what the target role can actually do using Effective Permissions and Blast Radius.

5. 5

   Review resource scope

   Identify whether access is broad or appropriately constrained to the required resources.

6. 6

   Review business ownership

   Map the relationship to a team, vendor, application or environment. Unowned relationships require investigation.

7. 7

   Decide

   The relationship may be approved as-is, approved but needing constraints, unnecessary and removable, or unknown and requiring investigation.

Evidence and limitations

Cross-account analysis depends on available role trust policies, external principal information, resource policies, account identifiers, organization context, policy conditions and scan freshness. A detected external relationship is evidence of trust or resource exposure — it does not automatically prove successful use of that relationship.

Related guides