Notifications
Clear all
Topic starter
06/07/2026 9:39 am
TL;DR: Cross-account AWS IAM trust policies can unintentionally create privilege escalation paths when organisations assume all accounts, principals, and trust directions carry equal risk, according to Token Security. The real control failure is not syntax correctness but misplaced trust boundaries that let lower-security accounts reach sensitive ones.
NHIMG editorial — based on content published by Token Security: Secure Cross-Account Access is Tricky. Four Common Dangerous Misconceptions
Questions worth separating out
Q: How should security teams govern AWS cross-account trust policies?
A: Security teams should govern AWS cross-account trust as a hierarchy problem, not a simple permission setting.
Q: Why do cross-account roles increase privilege escalation risk in AWS?
A: Cross-account roles increase privilege escalation risk because a trusted principal can become an entry point into the trusting account, and often into additional roles inside it.
Q: What do organisations get wrong about trusting a specific AWS principal?
A: They assume the trust is limited to one named role, when the effective trust boundary is the account that contains it.
Practitioner guidance
- Inventory every cross-account trust path Document which roles can be assumed across accounts, then classify each path by source account sensitivity, destination account sensitivity, and the business reason for the trust.
- Block upward trust into sensitive accounts Revise trust policies so that less secure accounts cannot assume roles in management or other higher-sensitivity environments unless there is an explicit, time-bound exception with compensating controls.
- Review trusted accounts as whole security domains Assess the security posture of the full trusted account, including its IAM policies, monitoring, and role assumption paths, before approving cross-account access from a more sensitive account.
What's in the full article
Token Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The specific AWS trust-policy examples used to illustrate each misconception.
- The step-by-step reasoning behind why a trusted principal often exposes the whole account.
- The account hierarchy patterns the vendor uses to separate management, production, logging, and development risk.
- The follow-on example promised by the vendor showing how AWS itself got cross-account trust wrong.
👉 Read Token Security's analysis of secure cross-account access misconceptions →
AWS cross-account trust policies: where do privilege paths break down?
Explore further
06/07/2026 9:54 am
Cross-account trust is an identity boundary problem, not a configuration problem. A trust policy can be syntactically correct and still create the wrong security outcome if the direction of trust violates the account hierarchy. The field often treats trust as a permissions object, but the real issue is whether one account is allowed to inherit the risk of another. Practitioners should evaluate cross-account access as delegated blast-radius design, not as a rule syntax check.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
A question worth separating out:
Q: Who should approve cross-account access into management accounts?
A: Only teams that own the highest-sensitivity AWS identity controls should approve that access, because the management account can affect the entire organisation. Any exception should require explicit business justification, compensating monitoring, and a review of the trusted account's posture before the trust is granted.
👉 Read our full editorial: Cross-account AWS trust policies create hidden privilege paths
