Last updated: April 29, 2026
Cloud accounts are the unit of blast radius. Organizations use separate accounts/subscriptions/projects for different environments (prod, staging, dev) or different teams. But workloads often need to cross accounts — a production app reading from a shared data lake, a logging pipeline collecting from many accounts. These cross-account integrations create attack paths.
Why this happens
The alternative to cross-account access is either (a) one giant account (terrible security boundary) or (b) duplicating everything per account (operationally miserable). So cross-account access is the practical middle ground. It works via trust relationships — account A’s IAM trusts account B’s principals to assume specific roles.
Mistakes:
- Trust policy uses
"Principal": {"AWS": "*"}— ANY AWS account can assume - Trust policy uses broad account (e.g., the partner’s entire account) instead of specific role
- Trust without External ID condition (enables confused-deputy attacks)
- Role grant broader than needed (Owner when ReadOnly suffices)
- Cross-account CloudTrail not unified; attacker crosses but detection doesn’t follow
Custom team training + practitioner advisory
Beyond the free academy — we run private workshops, vCISO advisory, and red-team exercises tailored to your stack. For Indian SMBs scaling past their first hire.