AWS accounts whose root user has no MFA device
What does ZopNight detect here?
ZopNight flags an AWS account when `GetAccountSummary` reports `AccountMFAEnabled` as 0, meaning the root user has no MFA device. The root user has complete access to every service and resource in the account, including the power to close it. The check never fires just because a root user exists, and the finding carries a $0 saving.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1522 |
| Category | compliance |
| Severity | critical |
| Metric | none — pure configuration read |
| Threshold | AccountMFAEnabled = 0 |
| Source | ZopNight |
| Permissions used | iam:GetAccountSummary |
Why the root user needs a second factor more than anyone
The root user is the identity created with the account. It is not an IAM user, AWS describes it as having complete access to all services and resources, and it can close the account and restore access for everyone else. Anyone holding its email and password without MFA holds the account.
AWS now states that MFA is enforced for all account types for their root user, and the root user can register up to eight MFA devices. The account summary still reports whether a device is registered, and that value is what this check reads.
Checking root MFA from the CLI
aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'1 means the root user has MFA; 0 means it does not. In the credential report, the row for
<root_account> shows the same fact in its mfa_active column.
What ZopNight reads
ZopNight treats the root user as its own resource per account and records the MFA flag from the account summary. The rule fires only when that flag is explicitly false. It is not an IAM user check, and it never fires merely because a root user exists.
When the rule says nothing
If the account summary call failed during discovery, the flag is missing and no finding is raised. The same happens when the flag says MFA is on.
In AWS Organizations, you can centrally manage root access for member accounts and delete their root passwords and MFA devices so nobody can sign in as root at all. A member account in that state may report no MFA even though root sign-in is impossible; treat such a finding as informational.
Why it is rated critical with no saving
The saving is $0. Severity is critical because a root takeover hands over the whole account, and it often means losing every resource in it.
Securing the root user
- Sign in to the console as the root user with the account email address.
- Open Security credentials from the account menu and assign an MFA device. A hardware security key or passkey gives the strongest protection.
- Register a second device and store it separately so a lost key does not trigger account recovery.
- Delete any root access keys; the root user should never have them.
- Stop using root for daily work; create an administrative identity in IAM Identity Center instead.