Sign in as root and enrol a hardware MFA device under Security credentials (this step is console-only by design). Register a second hardware key as a backup and store both in separate secure locations. Lock root away behind a break-glass procedure and run day-to-day work through IAM roles instead. Add a CloudWatch alarm on root sign-in so any use becomes a paged incident.

Compliance Critical severity

AWS Security Hub · IAM

IAM.6: The root user is not protected by hardware MFA

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub IAM.6 check?

IAM.6 fails when the account root user does not have a hardware MFA device enabled. A virtual (software) MFA device is not enough to pass: the control specifically requires a hardware key.

Why does IAM.6 matter?

Root can do anything in the account, including actions no IAM policy or SCP can restrict, and it can't be deleted or scoped down. A compromised root password with no phishing-resistant second factor is an extinction-level event: the 2014 Code Spaces shutdown followed an AWS control-panel credential compromise, and an attacker who reaches root can wipe everything in minutes. A hardware key binds the second factor to a physical origin, so a fake login page captures the password but never a valid signature.

How do I fix IAM.6?

Sign in as root and enrol a hardware MFA device under Security credentials (this step is console-only by design).
Register a second hardware key as a backup and store both in separate secure locations.
Lock root away behind a break-glass procedure and run day-to-day work through IAM roles instead.
Add a CloudWatch alarm on root sign-in so any use becomes a paged incident.

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.6 a false positive?

The cleanest pass for this control isn't hardware MFA at all: it's an account whose root user has no login profile (no console password set), which Security Hub treats as PASSED because there are no root credentials to protect. Member accounts vended through AWS Organizations often land in exactly that state, so a FAIL there usually means someone set a root password without then enrolling a hardware key, and the right move is to enrol the key, not except the finding. The one genuine edge case is the gap while you wait for a hardware token to ship: a virtual MFA device fails this control by design even though it's better than nothing. Treat that as a documented, time-boxed exception with the purchase order attached rather than disabling the control, and clear the suppression the moment the hardware key is enrolled.

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

Part of the learning path Lock down access

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.7 The IAM password policy is too weak
IAM.8 Unused IAM keys and passwords are waiting to be leaked
IAM.9 The root user can sign in without MFA
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