Cross-account access is a trust relationship that allows a principal in one account to reach resources in another account. It is often necessary for operations, but without tight scope and review it becomes one of the most common paths for unintended NHI exposure.
Expanded Definition
Cross-account access is a trust model that lets a principal in one account reach resources in another account without duplicating identities or credentials. In NHI security, that principal is often a service account, workload identity, API key, or agent. The model is essential for multi-account operations, but it also expands the trust boundary and can turn a routine integration into persistent lateral movement if scope is too broad.
Definitions vary across vendors, especially when account-to-account trust is implemented through cloud-native role assumption, federated identity, or delegated authorization. The common thread is that the accessing entity does not become “local” to the target account; it is granted a path across a boundary. That makes policy design, session duration, and resource scoping more important than the raw mechanism. OWASP’s OWASP Non-Human Identity Top 10 treats over-privileged machine access as a core risk pattern, and the same logic applies here.
The most common misapplication is treating cross-account access as a convenience feature, which occurs when teams grant broad trust to a whole account instead of narrowly binding the specific NHI, workload, or role.
Examples and Use Cases
Implementing cross-account access rigorously often introduces policy complexity and review overhead, requiring organisations to weigh operational speed against tighter blast-radius control.
- A build system in a central tooling account assumes a role in a production account to deploy artifacts, with time-bound permissions and logs reviewed after each release.
- A data-processing service in one account reads encrypted objects from another account through a narrowly scoped trust policy and KMS permission set.
- An AI agent in a sandbox account calls an internal ticketing or observability service in a shared services account, but only after explicit approval and conditional access checks.
- A third-party monitoring integration accesses read-only telemetry across multiple accounts, with separate entitlements and revocation tied to vendor offboarding.
- A disaster recovery workflow uses cross-account trust so a secondary account can restore data during an incident, but only under a break-glass procedure.
For practical guidance on how NHI sprawl affects these patterns, see the Ultimate Guide to NHIs and the related Ultimate Guide to NHIs — Key Challenges and Risks. For implementation discipline, cross-check role trust and federation patterns against the OWASP Non-Human Identity Top 10.
Why It Matters in NHI Security
Cross-account access is where a well-intended integration often becomes an enterprise-wide exposure point. Once trust crosses account boundaries, weak scoping, stale roles, or forgotten automation can create hidden paths that bypass normal access reviews. This is especially risky for NHIs because they are frequently over-privileged and under-inventoried; NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, which directly increases the chance that cross-account trust can be abused.
Governance should focus on who can assume the trust, what conditions must be met, how long access lasts, and how quickly it can be revoked. The right control pattern usually combines least privilege, session limits, explicit resource allowlists, and continuous review of trust relationships. That approach aligns with the operational direction described in the 52 NHI Breaches Analysis and with zero-trust expectations in modern identity programs. Practitioners should also align the model with OWASP Non-Human Identity Top 10 guidance on secret exposure and privilege minimisation.
Organisations typically encounter the consequences only after an incident review or cloud audit reveals an old trust path, at which point cross-account access becomes operationally unavoidable to fix.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Cross-account trust often amplifies improper secret and privilege handling. |
| NIST Zero Trust (SP 800-207) | SA-4 | Zero trust requires explicit verification for every cross-boundary access path. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control directly governs account-to-account trust relationships. |
Treat each cross-account request as untrusted until policy, identity, and context are validated.
