Notifications
Clear all
Topic starter
18/08/2026 2:31 pm
TL;DR: AWS IAM incident response remains vulnerable when containment depends on mutable managed policies, because attackers can race policy detachment during eventual consistency windows, according to OFFENSAI. Using AWS Organizations SCPs to protect a quarantine policy closes that gap and keeps identity-level isolation enforceable. The practical lesson is that incident response must assume an active attacker can fight back inside the account, so enforcement has to sit outside their control plane.
NHIMG editorial — based on content published by OFFENSAI: AWS IAM Incident Response: IAM Containment That Survives Eventual Consistency
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: What breaks when IAM containment relies on a managed policy attached to the compromised identity?
A: The containment can be raced.
Q: Why do AWS incident response playbooks need an outer enforcement boundary for NHI quarantine?
A: Because the compromised principal may still be able to change the very policy meant to contain it.
Q: How should teams know whether their quarantine process actually works against an active attacker?
A: They should test the runbook in a lab with a live adversary simulation, not just by confirming that the policy attaches successfully.
Practitioner guidance
- Protect quarantine policies with AWS Organizations SCPs Create an SCP that blocks iam:DetachUserPolicy, iam:DetachRolePolicy, iam:DeletePolicy, iam:CreatePolicyVersion, and iam:SetDefaultPolicyVersion for the quarantine policy ARN, except for a designated incident response role.
- Pre-stage a member-account quarantine policy Deploy a standard IR-QuarantinePolicy in every member account so containment reduces to one action during an incident rather than emergency policy creation under pressure.
- Isolate break-glass authority from the compromised account Keep the incident response permission set in a management domain the member account cannot modify, and restrict assumption to a small set of named responders with MFA and alerting.
What's in the full article
OFFENSAI's full article covers the operational detail this post intentionally leaves for the source:
- The exact SCP statements used to protect the quarantine policy from detachment, deletion, and overwrite.
- The full validation sequence showing how the attacker monitor behaved before and after SCP enforcement.
- The break-glass permission set model in IAM Identity Center and the trust-path constraints behind it.
- The account and management account boundary conditions that determine when this containment pattern can and cannot be used.
👉 Read OFFENSAI's analysis of AWS IAM containment that survives eventual consistency →
AWS IAM quarantine policies: are your incident response controls holding?
Explore further
18/08/2026 3:19 pm
Containment that can be detached by the attacker is not containment. This article exposes a governance assumption that many incident response playbooks still inherit from static IAM design: that a deny policy is effective as soon as it is attached. In AWS, eventual consistency breaks that assumption because the compromised principal may still act before the control takes effect. The implication is that incident response must be judged by who can still modify the enforcement object, not by whether the response has been issued.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: Who should be accountable for breaking glass during an AWS containment event?
A: Accountability should sit with a named incident response function, not with the compromised account owner. The break-glass role should be tightly restricted, separately governed, and monitored as a high-severity event because its use indicates that normal access boundaries have already failed. That makes the response auditable and prevents emergency authority from becoming a hidden backdoor.
👉 Read our full editorial: AWS IAM containment gaps persist without SCP-backed quarantine
