# Root Account MFA Not Enabled

> 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.

Source: https://zop.dev/integrations/aws/recommendations/root-account-mfa-not-enabled
Updated: 2026-08-19

---

## 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

```bash
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.