Felippe Motta: audit cross‑account trusts weekly
- AWS security guidance around cross-account IAM roles keeps converging on the same point: trust policies drift quietly, so teams need a frequent review loop. - The concrete risk sits in the trust relationship itself — broad principals, missing `ExternalId`, and absent org conditions can leave stale paths open. - What makes this matter is scale: multi-account AWS setups normalize role chaining, so one forgotten trust policy can become a lateral-movement shortcut.
Cross-account IAM roles are one of those AWS features that feel clean on paper and messy in real life. They let one account assume a role in another account, which is exactly how modern multi-account setups are supposed to work. But the dangerous part is the trust policy — the small JSON document that decides who is allowed to assume the role in the first place. That is why the recent push to audit cross-account trusts weekly lands as practical advice, not just security theater. ### What is a cross-account trust, exactly? A cross-account trust is the rule on an IAM role that says which principal from another AWS account can assume that role. AWS treats that trust policy as a resource-based policy on the role itself. Access only works when two things line up — the trusting account allows assumption, and the trusted principal also has identity permissions to make the request. That sounds strict, but it also means the trust policy becomes a high-value control point. (docs.aws.amazon.com) ### Why does this drift so easily? Because these roles tend to outlive the project that created them. A vendor integration gets set up, a migration finishes, an incident role stays behind, or an internal platform team leaves a broad principal in place “for now.” AWS’s own IAM best practices tell teams to regularly review and remove unused roles, permissions, and credentials, which is basically an admission that IAM sprawl is normal unless somebody keeps pruning it. (docs.aws.amazon.com) ### What usually goes wrong in the trust policy? The classic failure is a role that trusts too much. That can mean trusting an entire external account when only one role needed access, skipping conditions that narrow when assumption is allowed, or leaving third-party access without an `ExternalId`. AWS explicitly calls out default trust without conditions, reused external IDs, and long-term credentials for third parties as anti-patterns. In plain English — the front door is technically locked, but too many keys still work. (docs.aws.amazon.com) ### Why does `ExternalId` matter so much? Third-party access is where confused-deputy problems show up. AWS’s guidance is to have the third party give you its account ID and a unique external ID, then require that value in the trust policy when the role is assumed. That extra condition makes the role harder to abuse by someone who merely knows the role ARN and sits in the same vendor account structure. It is a small field, but it does real work. (docs.aws.amazon.com) ### What should teams check every week? Start with the principal list — who can assume this role right now? Then check the conditions — is there an `ExternalId`, an organization boundary like `PrincipalOrgId`, or some other narrowing control? Then check whether the role still needs to exist at all. AWS also recommends verifying public and cross-account access with IAM Access Analyzer, which continuously identifies outside access paths and can surface findings before or after policy changes. (docs.aws.amazon.com) ### Why weekly, not quarterly? Because trust relationships change faster than formal IAM reviews. New accounts get added, vendors rotate, engineers create temporary roles during incidents, and nobody remembers to clean them up later. In a multi-account AWS environment, one stale trust can become the bridge from a compromised account into a more sensitive one. Weekly review is basically a way to shorten the half-life of forgotten access. (docs.aws.amazon.com) ### Does this replace least privilege? No — it is the part people forget. Least privilege usually focuses on what a role can do after assumption. Cross-account trust review focuses on who can get in at all. You need both. AWS’s own guidance pairs temporary credentials, federation for humans, least-privilege permissions, and analysis of cross-account exposure for exactly that reason. (docs.aws.amazon.com) ### Bottom line? Weekly audits of cross-account trusts are not a new AWS feature. They are a discipline. And in practice, that discipline is what stops old integrations, broad principals, and forgotten roles from turning your account map into an attacker’s shortcut. (docs.aws.amazon.com 1) (docs.aws.amazon.com 2)
