AWS IAM containment gaps persist without SCP-backed quarantine

At a glance

What this is: This analysis argues that AWS IAM quarantine based on mutable managed policies can be undone during the propagation window unless the quarantine policy is protected by AWS Organizations SCPs.

Why it matters: IAM and cloud security teams need containment controls that remain effective under active attacker resistance, because incident response can fail if the attacker can detach or overwrite the very policy meant to isolate them.

Context

AWS IAM incident response depends on containment, but containment is only useful if it cannot be reversed by the identity that has already been compromised. In this article, the governance gap is not access discovery or credential revocation alone, but the fact that a managed policy attachment can remain mutable long enough for an attacker to fight back.

The operational question is whether quarantine is enforced by something inside the affected account or by a control plane the attacker cannot touch. For IAM teams, that distinction decides whether incident response is a reliable isolation control or only an advisory state change.

OFFENSAI's analysis focuses on the enforcement gap created by eventual consistency and shows why AWS Organizations SCPs change the containment model. The starting position is atypical in the sense that many playbooks assume policy attachment is immediately authoritative, when in practice it may not be.

Key questions

Q: What breaks when IAM containment relies on a managed policy attached to the compromised identity?

A: The containment can be raced. If the attacker still has enough privilege before IAM propagation completes, they may detach or overwrite the policy and keep access alive. That means the response is visible in the console but not yet durable in the control plane, so the quarantine state itself is not trustworthy until an outer boundary enforces it.

Q: Why do AWS incident response controls need to sit outside the compromised account?

A: Because any containment control that lives inside the account can be contested by the identity that was just compromised. An SCP at the Organizations layer changes the trust boundary so the attacker cannot modify the quarantine policy object itself. That makes isolation durable enough to survive active resistance rather than just passive compromise.

Q: How can security teams test whether quarantine really holds under attacker pressure?

A: Rehearse a scenario where an administrator tries to detach or overwrite the deny policy immediately after it is attached, then verify that the attempt is blocked before access can be restored. A valid containment test looks for durability under contest, not just policy presence. If the attacker can still undo the quarantine, the playbook is not ready.

Q: What is the difference between quarantine OU isolation and SCP-protected identity quarantine?

A: Quarantine OU isolation shuts down the whole account and is enforced at the organization level, while SCP-protected identity quarantine targets a specific principal but still uses organization-level enforcement to make the policy irremovable. The first maximises blast-radius control, the second maximises surgical response. Teams should choose based on impact tolerance and incident scope.

Technical breakdown

Why managed policy containment can be raced

In AWS IAM, identity-level containment often means attaching a deny policy, revoking sessions, and disabling keys. The problem is eventual consistency: the policy change is not authoritative everywhere at once, so a still-active principal may continue to make API calls or detach the new policy before the denial fully propagates. That makes containment dependent on timing, not just authorization. Once an attacker has elevated privileges in the account, they can watch for the quarantine attachment and remove it before the lockout takes effect. Practical implication: do not treat a managed policy attachment as immediately irreversible containment.

Practical implication: Treat policy attachment as a containment step that still needs an enforcement boundary the attacker cannot modify.

How SCP-backed quarantine changes the trust boundary

Service Control Policies sit at the AWS Organizations layer rather than inside the member account, so they govern what principals in that account can do to the quarantine policy itself. OFFENSAI's approach uses the iam:PolicyArn condition key to scope protection precisely to the quarantine policy, then denies detachment, deletion, and overwrite attempts by any principal except the designated incident response role. The technical shift is important: the attacker may still control the compromised identity, but they no longer control the policy that contains them. Practical implication: put the containment guardrail outside the compromised account when you need quarantine to survive active interference.

Practical implication: Use SCPs to protect the quarantine policy object, not just the compromised identity.

Why break-glass access must be isolated from member-account control

The exception path for incident response is a break-glass role or permission set, but that role only works if the attacker cannot assume it, edit it, or reach its trust boundary from the compromised account. OFFENSAI's design keeps the exemption in the management account or identity center control plane, which a member-account attacker cannot alter. That separation is what turns quarantine into a durable control rather than another managed policy they can contest. The same principle applies to automated incident response workflows that need privileged exemption. Practical implication: keep emergency access outside the blast radius of the compromise.

Practical implication: Isolate break-glass access in the management plane and alert on every assumption.

Threat narrative

Attacker objective: The attacker wants to defeat quarantine long enough to preserve access and continue operating from the compromised identity.

1. Entry occurs through compromise of an IAM identity that already has enough privilege to manage policies inside the account.
2. Credential and policy abuse follows when the attacker watches for the quarantine attachment and uses detachment rights before propagation completes.
3. Impact is the preservation of live access, which allows the attacker to keep operating even after defenders believe the account has been isolated.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity containment that depends on mutable managed policies is not containment yet: It is a best-effort state transition that can be reversed by the same privilege boundary it is meant to defeat. That is the core problem in AWS IAM incident response, because the attacker remains inside the control plane long enough to contest the quarantine action. Practitioners should treat reversibility as the design defect, not as an edge case.

Policy detachment resistance is now a governance requirement, not a tuning preference: The article exposes a structural gap between revoking access and making revocation durable. If a compromised principal can still detach or overwrite the denial that is supposed to contain it, the incident response model has not moved enforcement outside the attacker’s reach. The practical conclusion is that containment must be anchored in a control plane the compromised identity cannot modify.

Quarantine OUs and SCP-protected quarantine policies solve different problems: OU isolation is broader and more disruptive, while SCP-protected identity-level quarantine is narrower and faster. That distinction matters because many playbooks blur the two and assume any deny policy is equally enforceable. The better governance model is to choose the response based on blast radius, then make the chosen path resistant to attacker interference.

Break-glass access is only safe when the exemption path is outside the compromised account: A designated incident response role is not a technical afterthought, it is the control that preserves legitimate recovery while blocking attacker self-rescue. If that role can be reached or altered from the member account, the quarantine design collapses back into the same mutable control problem. Teams should design emergency access as an off-account authority boundary, not as another privilege inside the blast radius.

SCP-enforced quarantine is a useful named pattern for AWS incident response: The value is not the SCP label itself but the governance principle it represents, which is identity isolation enforced by an external policy plane. That pattern deserves to be treated as part of AWS IR runbook design, especially where eventual consistency creates a brief but exploitable enforcement gap. Practitioners should standardise on externally enforced quarantine when active opposition is expected.

What this signals

External enforcement is the real control boundary: In AWS incident response, the difference between a reversible and durable quarantine is where the enforcement lives. When the deny policy sits inside the compromised account, the attacker can contest it. When the guardrail sits in AWS Organizations, incident response becomes a control-plane decision the attacker cannot rewrite.

Policy detachment resistance should be built into playbooks: Teams that rely on mutable managed policies should assume active opposition, not just credential revocation. The practical programme change is to pre-stage quarantine controls and validate that the attacker cannot delete or detach the containment policy before propagation completes.

For practitioners

• Pre-stage SCP-protected quarantine policies Create the quarantine policy and the SCP guardrail in advance so the incident response step is only a policy attachment, not a design exercise during the incident.
• Separate break-glass authority from member accounts Keep the incident response role or permission set in the management plane, and make sure member-account principals cannot modify its trust boundary or permissions.
• Treat policy detachment as an attack path Assume a compromised administrator will attempt to remove the deny policy, overwrite it, or delete it before propagation completes, and test your runbook against that behaviour.
• Choose quarantine scope by blast radius Use account-level OU isolation when you need whole-account shutdown, and use identity-level quarantine only when an external guardrail makes the containment durable.

Key takeaways

• AWS IAM containment fails when the same compromised identity can still reverse the quarantine action before propagation completes.
• SCP-backed quarantine moves the enforcement boundary outside the member account, which is what makes the control durable under attack.
• Incident response teams should test containment against active policy detachment attempts, not just against credential revocation.

Key terms

• Eventual Consistency Window: The delay between an administrative change and the moment every relevant AWS control plane component reflects it. In incident response, that gap can allow a compromised identity to keep acting briefly after containment appears to be in place, which turns a simple policy attachment into a race condition.
• SCP-Backed Quarantine: A quarantine pattern that uses AWS Organizations Service Control Policies to protect an isolation policy from being detached, deleted, or overwritten by principals inside the affected account. It shifts enforcement outside the blast radius so the attacker cannot undo the containment from within.
• Break-glass Role: A break-glass role is a tightly controlled emergency access path used when normal administration is blocked. In cloud governance, it should be heavily scoped, monitored, and protected so it can restore control without becoming a standing privilege path.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or cloud security programme, it is worth exploring.