How to Enable MFA for the AWS Root Account and IAM Users (Security Hub IAM.9, IAM.6, IAM.5)

[IAM.9] means the AWS account root user can sign in with a password but has no MFA device, and [IAM.5] flags IAM users who have a console password but no MFA. To fix both, enable MFA on the AWS root account with a passkey or security key, then add MFA for each console user or delete unused console passwords.

Neither check looks at a server. The work is one console session as root, a credential report, and a decision about each password-only IAM user.

What the scanner is actually detecting

These findings come from AWS Security Hub CSPM (the name the AWS documentation now uses for the Security Hub control checks), a cloud security posture management service; if the category is new to you, see what CSPM is and what it checks. Each control is backed by an AWS Config managed rule, so the “asset” in the report is an account ID or a user ARN, not a host.

IAM.9 and IAM.6 evaluate the AWS::::Account resource and pass when the account has no root user credentials at all, which is the normal state of member accounts after centralized root access removes them. IAM.6 is stricter: it fails if hardware MFA is not enabled or if any virtual MFA device is still permitted for root sign-in. IAM.5 evaluates each AWS::IAM::User.

Microsoft Defender for Cloud raises the same checks on connected AWS accounts as MFA should be enabled for the “root” account, Hardware MFA should be enabled for the “root” account (both rated Low) and Ensure multifactor authentication (MFA) is enabled for all IAM users that have a console password (Medium), so expect severities to differ between the two tools.

Real-world risk, stated honestly

The root user has complete access to every service and resource in the account. If its password is phished, reused elsewhere, or reset through a compromised mailbox, MFA is the only remaining barrier. An IAM console user without MFA is the same problem, bounded by that user’s permissions. For proportion:

• AWS now requires MFA for the root user of standalone, management and member accounts, and users must register a device within 35 days of their first console sign-in attempt. A root user nobody signs in as can still fail IAM.9.
• MFA protects console sign-in. It does not protect root access keys (a separate control, IAM.4) or IAM user access keys used by the CLI.
• Authenticator app codes can be phished. AWS recommends passkeys and security keys because they resist phishing.
• MFA limits who can sign in, not what they can do afterwards. Pair it with an audit of over-permissioned IAM roles.

How to confirm it in your account

Run these with credentials that can read IAM. IAM is global, so no Region flag is needed.

Root user (IAM.9 and IAM.6)

aws iam get-account-summary 
  --query "SummaryMap.[AccountMFAEnabled,AccountPasswordPresent]" --output text
aws iam list-virtual-mfa-devices --assignment-status Assigned 
  --query "VirtualMFADevices[].[SerialNumber,User.Arn]" --output text

AccountMFAEnabled is 1 when root has an MFA device; AccountPasswordPresent shows whether root still has a password. In the second output, a row whose ARN ends in :root is an authenticator app on the root user, and IAM.6 keeps failing while it is registered.

Console users without MFA (IAM.5)

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > cred-report.csv
awk -F, 'NR>1 && $2 !~ /:root$/ && tolower($4)=="true" && tolower($8)=="false" {print $1, $5}' cred-report.csv

Repeat the generate command until it returns COMPLETE. In the CSV, column 4 is password_enabled, column 5 is password_last_used and column 8 is mfa_active, so the awk line prints each user with a password but no MFA, plus when the password was last used. IAM builds a new report at most once every four hours; inside that window you get the previous one.

How to fix it

Root user: IAM.9 and IAM.6

A passkey or security key for root can be enabled from the AWS Management Console only, not from the AWS CLI or API, and only while signed in as root.

1. Check the root email address and phone number in the account contact settings. If the MFA device is lost, AWS verifies your identity with those.
2. Sign in as root, choose your account name on the navigation bar, then Security credentials.
3. Under Multi-factor authentication (MFA), choose Assign MFA device, enter a device name, choose Passkey or Security Key, then follow the browser prompts.
4. Register a second device and store it separately. Root and each IAM user can have up to eight MFA devices of any type.
5. For IAM.6, use a physical FIDO security key or a hardware TOTP token, then remove any authenticator app device from root.
6. Sign out, delete root access keys if any exist, and stop using root for daily work.

AWS Organizations member accounts

Instead of keeping MFA devices for every member root user, you can centralize root access from the management account:

aws organizations enable-aws-service-access --service-principal iam.amazonaws.com
aws iam enable-organizations-root-credentials-management
aws iam enable-organizations-root-sessions

The management account, or a delegated administrator for IAM, can then delete member root passwords, access keys and signing certificates and deactivate their MFA from Root access management in the IAM console. New member accounts have no root credentials by default.

IAM users: IAM.5

• A person who needs the console: in the IAM console open Users, the user, Security credentials, then Assign MFA device. Prefer a passkey or security key; an authenticator app is the fallback.
• No console use: delete the console password with aws iam delete-login-profile –user-name build-bot. Access keys are not affected.
• Many human users: consider moving people to IAM Identity Center and removing their IAM users, since IAM.5 only evaluates IAM users.

Require MFA with aws:MultiFactorAuthPresent

To stop console users from working before they register MFA, attach the IAM User Guide example policy “Allows MFA-authenticated IAM users to manage their own MFA device on the Security credentials page” to their group. Its core statement denies everything except device self-registration unless the session used MFA:

{
  "Sid": "DenyAllExceptListedIfNoMFA",
  "Effect": "Deny",
  "NotAction": [
    "iam:CreateVirtualMFADevice",
    "iam:EnableMFADevice",
    "iam:GetUser",
    "iam:ListMFADevices",
    "iam:ListVirtualMFADevices",
    "iam:ResyncMFADevice",
    "sts:GetSessionToken"
  ],
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
  }
}

Use the complete example, which adds the Allow statements users need. Keep BoolIfExists: the key is absent from requests signed with long-term access keys, and AWS warns that a plain Bool test does not deny those requests.

How to verify the fix and rescan

• Rerun get-account-summary and confirm AccountMFAEnabled is 1. For IAM.6, confirm no virtual device row ends in :root.
• After the four-hour window, regenerate the credential report and rerun the awk filter. It should print nothing.
• Check the control state in Security Hub CSPM:

aws securityhub get-findings --filters '{"ComplianceSecurityControlId":[{"Value":"IAM.9","Comparison":"EQUALS"}],"RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}]}' 
  --query "Findings[].[Compliance.Status,Resources[0].Id]" --output text

All three are periodic controls, and Security Hub CSPM runs periodic checks within 12 or 24 hours of the previous run, so a finding can stay FAILED for a day after the fix. AWS Config also notes that re-evaluating mfa-enabled-for-iam-console-access within four hours of its first evaluation has no effect. In Defender for Cloud, wait for the next assessment of the AWS connector.

What can break and how to roll back

• Lost root MFA device: sign-in falls back to identity verification through the root email and phone number, which is why you check them first. A second registered key avoids this.
• The deny-without-MFA policy: AWS warns that BoolIfExists also denies requests made with access keys, so scripts and CI jobs running as those users will fail. Attach it only to a human console group, or have scripts call sts get-session-token with an MFA code. Roll back by detaching the policy.
• Deleted console password: the user can no longer sign in. Restore it with aws iam create-login-profile –user-name build-bot –password ‘<temporary>’ –password-reset-required. To cut a user off completely, deactivate their access keys too.
• Wrong or abandoned device: run aws iam deactivate-mfa-device –user-name alice –serial-number <arn>, then aws iam delete-virtual-mfa-device –serial-number <arn> for a virtual device.
• Centralized root access: if a task later needs a member root user, allow password recovery for that account, then delete the credentials again when done.

Common false positive reasons

• IAM.6 fails although root has MFA: the root device is an authenticator app, or an app is still registered next to a hardware key. This is expected behavior, not a scanner error.
• Fixed, but still FAILED: the periodic check has not run since the change.
• The same IAM user in several Regions: IAM users are global. AWS says that if you record global resources in a single Region, you can disable IAM.5 in every other Region. One fix clears all copies.
• Member root flagged after cleanup: IAM.9 and IAM.6 pass when root credentials are absent, so a failure means credentials were recovered and never deleted again.

FAQ

Can I enable root MFA with the AWS CLI or infrastructure as code?

No. AWS documents passkey and security key setup as console only, not the CLI or API, so API-based tools cannot do it.

Why does IAM.6 fail when IAM.9 passes?

IAM.9 accepts any MFA type. IAM.6 requires hardware MFA and fails while any virtual device is permitted for root.

How many MFA devices can one user have?

Up to eight, in any combination of types, for the root user and for each IAM user. AWS recommends registering more than one.

Does MFA protect IAM user access keys?

Not by itself. Requests signed with access keys carry no MFA context. Only a policy using aws:MultiFactorAuthPresent with BoolIfExists, plus sts get-session-token with an MFA code, makes CLI and API use require MFA.

Tracking this finding across many accounts

Across dozens of AWS accounts, most of the effort is bookkeeping: which root users are done, which IAM users still have passwords, and which exceptions were approved. SITEY is a self-hosted vulnerability management platform that imports findings from 16 scanners, merges duplicates per scanner (not across scanners), and uses AI triage to suggest false positives with evidence for a human to decide. Check whether your cloud posture tool is one of its supported imports before planning around it.

Sources

• AWS: Security Hub CSPM controls for IAM (IAM.5, IAM.6, IAM.9)
• AWS IAM User Guide: Multi-factor authentication for the AWS account root user
• AWS IAM User Guide: Generate credential reports for your AWS account
• AWS IAM User Guide: Global condition context keys (aws:MultiFactorAuthPresent)
• Microsoft Learn: Defender for Cloud identity and access recommendations