Cross-account persistence is a condition where a compromised identity uses policy changes or delegated access to retain operational reach from another account after the initial foothold is lost. In cloud and AI pipelines, it can preserve write access to data or context without ongoing access to the original principal.
Expanded Definition
Cross-account persistence describes a foothold that survives the loss of the original compromised principal by shifting control into another account, role, or delegated path. In NHI and cloud identity operations, that usually means the attacker has modified trust relationships, token grants, IAM policies, or automation permissions so access can continue from a different identity surface.
This term is narrower than ordinary persistence because the surviving access is not just another session on the same account. It is a control-plane problem: the adversary uses identity federation, service-to-service trust, or delegated administration to keep write capability over data, secrets, or model context. That makes it especially relevant to machine identities, pipelines, and agentic workloads, where authority is often inherited rather than explicitly re-approved. Guidance varies across vendors, but the security meaning is consistent: if the original account is cleaned up while the secondary path remains active, persistence has not been removed.
The most common misapplication is treating the account reset as full remediation, which occurs when hidden grants, role trust, or cross-account tokens are left untouched.
For control expectations, NIST SP 800-53 Rev 5 Security and Privacy Controls is the most useful baseline for access governance and account management, while Zero Trust concepts help frame the need to revalidate every cross-boundary request.
Examples and Use Cases
Implementing cross-account persistence detection rigorously often introduces more identity telemetry and change-review overhead, requiring organisations to weigh faster automation against tighter trust controls.
- A compromised CI/CD service account adds itself to a cross-account role trust policy, then continues deploying after the original key is revoked.
- An AI agent is granted delegated write access to another workspace, allowing it to keep modifying prompts or retrieval context even after the first token is disabled.
- A cloud admin account creates a backup break-glass path in a separate account and the attacker later abuses that path to preserve operational reach.
- A secrets rotation workflow updates the primary credential, but a secondary account still has permission to mint new tokens from the old trust chain.
- During investigation of the Salt Typhoon US telecoms breach, the broader lesson for defenders is that stolen credentials are often only the starting point when delegated access remains available.
These patterns are well-aligned with the access-review and policy-enforcement expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls. They also mirror the identity sprawl and persistence risks discussed in the Ultimate Guide to Non-Human Identities.
Why It Matters in NHI Security
Cross-account persistence is dangerous because it defeats the usual cleanup sequence. Teams may rotate a key, terminate a session, or disable the visible account, yet the attacker still retains control through a second identity path. In cloud and AI environments, that can mean continued access to pipelines, model orchestration, logs, feature stores, or secret material even after the incident appears contained.
This is one reason NHI governance must focus on trust relationships, not just credentials. NHI Mgmt Group data shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after notification, which creates a long window for secondary access to survive. The risk is amplified when identities are overprivileged or poorly inventoried, as described in NHI Mgmt Group’s NHI research.
In practice, defenders should inspect role chaining, delegated grants, service principals, token minting paths, and cross-account automation after any suspected compromise. A second useful control lens is NIST SP 800-53 Rev 5 Security and Privacy Controls, which supports systematic review of authorization boundaries and account lifecycle handling. Organisations typically encounter the real impact only after an incident response reveals that the attacker was never dependent on the original account at all, at which point cross-account persistence becomes operationally unavoidable to address.
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 CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Covers excessive permissions and trust relationships that enable NHI persistence. |
| NIST CSF 2.0 | PR.AC-1 | Addresses identity and credential management across access boundaries. |
| NIST SP 800-63 | Defines digital identity assurance principles relevant to delegated access handling. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification across accounts and workloads. | |
| NIST AI RMF | AI risk management includes controlling identity-driven access to models and data. |
Validate every cross-account trust relationship and revoke paths that outlive the original principal.
