AWS root accounts protected by nothing but a password
What does ZopNight detect here?
Root MFA state arrives on a dedicated iam-root-account resource because root is not an IAM user and never appears in user listings. ZopNight fires only when the producer explicitly reports mfa_enabled as false; a failed probe yields no finding. Severity is critical, because 1 password currently guards unrestricted account access.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1522 |
| Category | compliance |
| Severity | critical |
| Metric | none — pure configuration read |
| Source | root_account_mfa.go |
Why root needed its own resource type
The root identity is not an IAM user. It never shows up in user listings, carries no policies,
and cannot be constrained by them. That is precisely why an earlier version of this check,
which looked for a root-flagged IAM user, could never match anything. The discoverer now emits
a dedicated account-level resource (the arn:aws:iam::<account>:root identity) carrying the
MFA state from the account summary, and the rule keys on that type directly. The lesson
generalises: controls about root have to be modelled at the account grain or they silently
check nothing.
The blast radius of a root password
Root can close the account, delete every backup, strip every other admin, and change the billing contacts that would have alerted you. IAM permission boundaries, SCPs on member accounts, deny policies: none of them bind the payer-account root. A password alone standing in front of that is the single worst risk-per-fix-minute ratio in AWS, which is why this is one of the few findings ZopNight rates critical with no dollar amount attached.
Evidence handling
The producer stamps mfa_enabled from the account summary as a stringified boolean. The rule
fires only on an explicit “false”; if the summary call soft-failed and the field never arrived,
it abstains. Root MFA missing is never asserted from absence of data. A claim this serious is
made only on positive evidence.
Check it in five seconds
aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'1 means root has MFA; 0 fires this finding.
Doing the fix well
Enrolling any MFA clears the finding; doing it properly means a hardware FIDO2 key (root supports up to 8 MFA devices, so register a second key and store it separately, since a lost sole authenticator becomes its own incident), then stop using root at all. Reserve it for the short list of root-only tasks, leave day-to-day administration to IAM Identity Center users, and alert on any root sign-in via CloudTrail so the credential’s use is itself an event worth investigating.