Skip to main content
emnode
Sign up
Compliance Critical severity

AWS Security Hub · IAM

IAM.9: The root user can sign in without MFA

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub IAM.9 check?

IAM.9 fails when root user credentials exist but no MFA at all is enabled for the root user; any MFA type, including a virtual MFA device, makes it pass. Requiring an unphishable hardware MFA device for root is a separate, stricter control (IAM.6), which additionally fails when only virtual MFA is permitted.

Why does IAM.9 matter?

Root with only a password is one credential-stuffing or phishing event away from total account compromise. Because root bypasses IAM policies and SCPs, MFA is the single most important control protecting it. Hardware MFA is strongly preferred so the second factor cannot be phished or SIM-swapped.

How do I fix IAM.9?

  1. Sign in as root and enable MFA from My Security Credentials.
  2. Prefer a hardware security key (FIDO2) or a dedicated hardware TOTP device over a phone app for the root user.
  3. Store the device securely and document the recovery process so root stays usable without weakening it.

Remediation script · bash

# Root MFA has no CLI equivalent: register it in the console while signed in as root
# (Security credentials > Multi-factor authentication > Assign MFA device).
# Then verify a device is bound to the root ARN and the summary flag flips to 1.
aws iam list-virtual-mfa-devices --assignment-status Assigned \
  --query 'VirtualMFADevices[?ends_with(SerialNumber, `:mfa/root-account-mfa-device`)].SerialNumber'
aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'

# Enforce MFA on human IAM users with a conditional-deny policy keyed on the MFA flag.
aws iam attach-group-policy --group-name HumanUsers \
  --policy-arn arn:aws:iam::123456789012:policy/RequireMFAForUsers

# Require MFA pool-wide on a customer-facing Cognito pool.
aws cognito-idp set-user-pool-mfa-config --user-pool-id eu-west-1_aB3cD4eFg \
  --mfa-configuration ON --software-token-mfa-configuration Enabled=true

Full walkthrough (console steps, edge cases and verification) in the lesson Enable MFA for root and IAM users.

Is IAM.9 a false positive?

Genuine false positives are rare here, because the check only fails when root sign-in credentials actually exist without MFA. The flip side is the bigger gotcha: IAM.9 also passes when no root user credentials are present at all: the intended state for member accounts under centralised root access in AWS Organizations, where root is locked away entirely. So a PASSED finding does not always mean someone enabled MFA; it can mean root has no usable password to protect. Treat a pass as confirmation only after checking that root credentials either don't exist or do have MFA, and note that IAM.9 is satisfied by any MFA type: if you require an unphishable hardware key for root, track that through IAM.6 rather than relying on IAM.9 to enforce it.

Full lesson Enable MFA for root and IAM users Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for IAM controls ↗ Check your own account for IAM.9 →
Part of the learning path Lock down access

More IAM controls

  • IAM.1 A policy grants full "*" administrative privileges
  • IAM.2 Policies attached directly to users do not scale or audit cleanly
  • IAM.3 Long-lived access keys have not been rotated
  • IAM.4 The root user still has long-lived access keys
  • IAM.5 Console users without MFA are one phish from compromise
  • IAM.6 The root user is not protected by hardware MFA
  • IAM.7 The IAM password policy is too weak
  • IAM.8 Unused IAM keys and passwords are waiting to be leaked
  • IAM.10 IAM user password policies should be strong (PCI DSS)
  • IAM.19 MFA should be enabled for all IAM users
  • IAM.21 Wildcard permissions grant far more access than intended
  • IAM.22 IAM credentials unused for 45 days should be removed