Root Exemptions in SCPs Undo Every Deny Clause

The Trap

The Blanket Root Exemption Clause. AWS’s own guidance warns against writing an unconditional Deny SCP against iam:* because it can permanently lock an account out of root-only tasks. To satisfy that guidance, teams add a Condition block to their Deny statements matching aws:PrincipalArn against arn:aws:iam::*:root with StringNotEquals, exempting root from the Deny entirely. That exemption block then gets copied wholesale into every subsequent SCP the security team writes, regardless of what the statement is actually protecting.

The Default State

Landing zone baselines and hand-rolled guardrail libraries typically ship one root-exemption SCP for account-recovery reasons, then reuse its Condition syntax as boilerplate. A Deny statement targeting cloudtrail:StopLogging, guardduty:DeleteDetector, or organizations:LeaveOrganization gets the same StringNotEquals root exemption pasted in, on the assumption that “root always needs an escape hatch.” No one revisits which actions genuinely require that exemption versus which ones are simply carrying it forward unreviewed. The SCP evaluates correctly for IAM users and roles; it does nothing for root.

The Blast Radius

Root in a member account has no attached IAM policy to constrain it and, if MFA was never enforced on that credential, a password reset or a leaked long-term access key is enough. Once authenticated as root, the attacker calls organizations:LeaveOrganization to detach the account from the Organization outright, removing every remaining SCP in one step, or simply stays inside and calls cloudtrail:StopLogging and guardduty:DeleteDetector first. Every one of those actions was covered by a Deny SCP that exempted root by principal. Forensics collapse because the same session that exfiltrated data also disabled the logging that would have proven it.

The Lead Mechanic Fix

Stop treating the root exemption as reusable boilerplate. Restrict it to the literal set of tasks AWS documents as requiring root — closing the account, changing account settings, viewing tax invoices, restoring a locked-out IAM user, changing the support plan — and write those as one narrowly scoped SCP statement with an explicit ForAllValues:StringEquals action list, not a blanket NotAction. Every other Deny statement — organizations:LeaveOrganization, cloudtrail:StopLogging, cloudtrail:DeleteTrail, guardduty:DeleteDetector, iam:CreateAccessKey against root itself — must carry zero principal exemption. Better still, enable IAM’s centralised root access management from the management account, which deletes long-term root credentials in member accounts and routes emergency root actions through the management account, removing the need for a blanket exemption in the first place.