A partial containment policy that attaches deny rules to an IAM user while leaving the access key itself active. It reduces what the credential can do, but it does not invalidate the key or necessarily remove other permissions already attached to the identity.
What AWS key quarantine actually does
AWS key quarantine is a containment measure, not a true revocation. It adds deny rules to the IAM user so the access key can remain present while its effective permissions are sharply reduced, which can help slow further misuse during an incident.
The key point is that the credential is still live. If the identity has other permissions or if the attacker already established alternate access paths, quarantine may limit damage without fully ending the compromise.
Why quarantine is different from deactivation
Because the key itself stays active, quarantine is best understood as an emergency brake rather than a clean shutdown. It can be useful when responders need immediate containment but cannot yet remove the credential without risking operational disruption.
That distinction matters in AWS because access is resolved through the combination of the key, the user, and the attached policy set. Deny statements can override many actions, but they do not erase the credential, and they do not automatically unwind every permission source tied to the identity.
Where this control fits in incident containment
Quarantine is often used early in response when teams want to preserve the account for investigation while reducing blast radius. It can buy time for log review, scope validation, and owner coordination before a full credential rotation or identity cleanup is performed.
It is most useful when responders suspect active misuse but still need controlled access for forensic work or business continuity. In practice, it sits between monitoring and full revocation, which is why it should be treated as temporary containment rather than a final fix.
A broader response playbook for stolen cloud credentials is laid out in Leaked Credential and Secret Incident Response Playbook, which is the right next step when quarantine is being used as an interim control.
What organisations should verify after quarantine
Quarantine only helps if the environment is checked for the ways the key may already have been used. That means confirming where the key appears in the asset inventory, whether the associated IAM user has other active permissions, and whether the key has been used from unusual locations, workloads, or automation paths.
Teams should also review whether the same access pattern exists elsewhere, because attackers often reuse cloud credentials across multiple systems once they find them. In AWS incidents, the question is rarely only “is the key blocked enough?” but also “what else did this credential touch before containment?”
For a fuller view of cloud credential containment and follow-up investigation, see Cloud Credential Compromise Playbook and Leaked Credential and Secret Incident Response Playbook.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | AWS key quarantine is a credential-lifecycle containment tactic for an active authenticator. |
| AC-2 — Account Management | Quarantine changes what a user account can do while the identity remains present. | |
| AU-6 — Audit Review, Analysis, and Reporting | Quarantine should be paired with log review to confirm prior credential use and scope. | |
| Recommendation — Manage, rotate, and revoke access keys promptly when compromise is suspected. Review and constrain the user account until full remediation removes residual access. Analyze audit records to determine where the quarantined key was used before containment. | ||
| CIS Controls v8 | CIS-5 — Account Management | The term is about limiting account capability and handling compromised credentials safely. |
| Recommendation — Restrict or remove compromised cloud accounts and credentials without delay. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | A quarantined key is still present, so offboarding and full retirement remain relevant. |
| Recommendation — Retire the credential fully rather than leaving a live key in partial containment. | ||
Practitioner Guidance
Why practitioners should care: Quarantine is useful when you need immediate containment, but it should not be mistaken for revocation. If the identity still exists in a usable state, the safest assumption is that the compromise is only partially constrained until the key is rotated or the account is rebuilt.
What to watch for: Use quarantine as a short bridge while you verify usage, review attached permissions, and decide whether the right outcome is key deletion, user cleanup, or broader access redesign. If the same pattern keeps recurring, the underlying issue is usually weak secret lifecycle control rather than a one-off key event.
Practitioner takeaway: Treat quarantine as a containment step that supports investigation, not as a substitute for credential retirement.