Cross-Account Access Without Regret: Patterns That Don’t Become a Security Incident

External IDs: What They Solve

The External ID condition prevents the confused deputy problem: a scenario where a third-party service that you trust uses your trust relationship to access another customer’s account. If you grant a SaaS vendor a role in your account, and that vendor also serves your competitor, the External ID ensures the vendor can only use the role when acting on your behalf.

Use External IDs for every third-party trust relationship. For internal cross-account access (your accounts, your principals), External IDs are optional but add a defence layer. They cost nothing to implement and make role assumption explicit.

Role Chaining and Session Duration

Role chaining occurs when a principal assumes role A, then uses role A’s credentials to assume role B. AWS limits chained sessions to one hour regardless of the role’s configured maximum. This catches teams off guard—a deployment that takes 90 minutes will fail mid-way when credentials expire.

The fix is to avoid unnecessary chains. If your CI system needs access to both Account A and Account B, create separate roles in each account that trust the CI principal directly, rather than chaining through an intermediate role. Fewer hops means longer sessions and simpler debugging when something fails.

Permission Boundaries

Permission boundaries cap the maximum permissions that an IAM entity can have, regardless of what policies are attached to it. Use them on cross-account roles to ensure that even if someone attaches AdministratorAccess to a cross-account role, the boundary limits the effective permissions to what you intended.

Decision Framework

For each cross-account access need, define: who needs access (specific principal ARN), what they need to do (scoped IAM policy), and for how long (session duration). Document every trust relationship in a registry—a simple spreadsheet is fine. Review quarterly. Stale trust relationships are the access patterns that become security incidents.

Failure Modes

Trusting an account root instead of a specific principal is the most common mistake. It turns one role into an access path for every user, role, and service in the trusted account. The second failure: using * in the role’s permission policy because “we will scope it later.” Later does not arrive until after the audit finding.

Cross-account access is necessary infrastructure. Treat every trust relationship as a firewall rule: document it, scope it, review it, and remove it when it is no longer needed. The access you forget about is the access an attacker finds.