Cloud persistence is the ability of an attacker to keep access after the initial compromise has been detected or partially remediated. In practice, it often relies on overlooked permissions, reactivated identities, policy edits, or newly created access paths that survive cleanup and let the attacker return later.
Expanded Definition
Cloud persistence is a post-compromise condition in which an attacker preserves a foothold inside a cloud environment after defenders believe the original entry point has been removed. It is broader than simple account compromise because the persistence can be tied to identities, access policies, API permissions, tokens, federation settings, automation, or privileged cloud roles.
In cloud environments, persistence often hides in places that are easy to overlook during cleanup: inactive but still-authorised accounts, long-lived credentials, delegated admin paths, service principals, conditional access exceptions, or infrastructure changes that recreate access on demand. The boundary that matters is not whether the attacker still uses the same password or instance, but whether they still have a reliable way back in.
This is a practical attacker objective, not just a cloud hygiene issue. Security teams often discover that removing one compromised asset does not eliminate the access relationship that made the compromise durable in the first place. That is why cloud persistence is best understood as a lifecycle problem across identity, configuration, and control plane governance.
Examples and Use Cases
Cloud persistence appears in several common operational patterns:
- An attacker adds a new federated trust or token issuance path so access survives password resets and account lockdown.
- A malicious actor creates an additional privileged role assignment or app credential, then waits until the original account is disabled.
- Automation or infrastructure-as-code is altered so deleted access is recreated when the next deployment runs.
- A compromised service principal is left active because the response effort focuses on human user accounts only.
- Conditional access, delegation, or tenant-level policy exceptions are edited to preserve a route back into the environment.
The tradeoff in cloud response is speed versus completeness. Rapid containment may stop visible activity, but durable persistence usually requires a deeper search across identity stores, permission graphs, orchestration layers, and audit trails. For that reason, cloud persistence is often missed when defenders focus on the obvious infected host or the first account that triggered the alert.
Security Implications
Cloud persistence matters because it turns a contained incident into a recurring one. If the attacker retains a hidden access path, remediation can appear successful while the environment remains quietly exposed. The visible symptom may be repeated logins, unexplained policy changes, new credentials that reappear after cleanup, or administrative actions that no one expects to still be possible.
The main failure mechanism is incomplete revocation. In cloud systems, access is rarely stored in one place, so cleanup that removes only the original compromise leaves behind the relationships that made continued access possible. This can widen blast radius over time, especially where one identity can mint tokens, alter policies, or provision new access paths for others.
For defenders, the practical consequence is loss of trust in the remediation outcome. If persistence is not fully removed, later activity may be misread as a fresh intrusion rather than a surviving foothold. That delays containment and makes incident scoping harder, because the attacker can return through a route that looks legitimate on paper.
Domain and Governance Relevance
Cloud persistence sits at the intersection of identity governance, cloud control plane security, and incident response. It is especially relevant where access is distributed across users, workloads, APIs, service accounts, and delegated administration. In those environments, the core governance question is not only who had access, but which access paths can outlive a cleanup action.
Where non-human identities are involved, the meaning becomes even sharper. A workload identity or service credential can preserve access even when a human operator account is disabled, so machine access must be inventoried and revoked with the same discipline as user access. That is a central NHI governance concern, not a secondary detail.
NHIMG treats cloud persistence as a reminder that recovery is not complete until the trust relationships are removed, revalidated, and monitored. In cloud and NHI settings, the real control objective is durable revocation, not just visible containment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1098 — Account Manipulation | Cloud persistence often relies on altered accounts, roles, or auth paths. |
| T1136 — Create Account | Attackers may create extra identities to survive cleanup. | |
| T1550 — Use Alternate Authentication Material | Tokens, keys, and federated material can outlast the original compromise. | |
| Recommendation — Hunt for modified accounts, roles, and auth settings that preserve attacker access. Review account creation activity and remove identities that were added for persistence. Revoke alternate authentication material and validate that stale tokens no longer work. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Persistence is often sustained through weak revocation and lingering access paths. |
| DE.CM — Security Continuous Monitoring | Persistent access is often exposed through unusual cloud control-plane activity. | |
| Recommendation — Strengthen access revocation and continuously validate that privileges no longer remain effective. Monitor cloud identities, roles, and policy changes for signs of surviving access paths. | ||
| CIS Controls v8 | 5 — Account Management | Cloud persistence frequently exploits unmanaged or reactivated accounts. |
| 6 — Access Control Management | Persistent access usually depends on permissions left in place after cleanup. | |
| Recommendation — Maintain authoritative account inventories and remove accounts that no longer need access. Restrict and periodically revalidate privileges so removed access does not remain usable. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Workload identities and machine credentials can become persistent access paths. |
| NHI-04 — Secrets and Credential Management | Secrets, keys, and tokens are common persistence mechanisms in cloud compromise. | |
| Recommendation — Inventory non-human identities and assign owners who can revoke them during response. Rotate and revoke exposed secrets, tokens, and keys to eliminate surviving authentication paths. | ||
Related resources from NHI Mgmt Group
- How do security teams know a cloud intrusion has moved beyond access into persistence?
- What breaks when browser-side persistence is used to keep access to cloud mailboxes?
- How should security teams reduce persistence risk from cloud permissions in multi-cloud environments?
- Why do over-permissioned cloud identities make persistence and lateral movement easier?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
