Root Account Has No MFA: Why It Matters and How to Fix It

The root user is the original account created when you first sign up for AWS. It owns the account, can close it, can change billing, and can override almost any IAM policy you put in place. When this check fires, it means that account is protected by a password alone. That single factor is the only thing standing between an attacker and total control of your environment.

This is one of the few findings that almost every security framework treats as non-negotiable. CIS AWS Foundations, PCI DSS, SOC 2, and AWS's own Well-Architected guidance all call it out explicitly. If you fix one thing today, make it this.

---

What this check detects

The account_rootmfa check inspects your AWS account credential report and the account summary to confirm whether the root user has an MFA device registered. It returns a failing result when:

• The root account has zero MFA devices attached, or
• The AccountMFAEnabled field in the IAM account summary reads 0

You can reproduce the same check manually with the AWS CLI:

aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'

A return value of 0 means root has no MFA. A value of 1 means it does. You can also pull the credential report, which includes a mfa_active column for the root account:

aws iam generate-credential-report
aws iam get-credential-report \
  --query 'Content' --output text | base64 -d | grep '<root_account>'

---

Why it matters

Root credentials bypass the guardrails you spend so much effort building. IAM permission boundaries, service control policies, and resource policies do not constrain the root user the way they constrain IAM principals. If root is compromised, your blast radius is the entire account.

Consider what an attacker can do with root and no MFA in the way:

• Change the account email and lock you out of recovery
• Create new admin IAM users and access keys for persistence
• Disable CloudTrail and delete logs to cover their tracks
• Spin up expensive compute for cryptomining and rack up a five-figure bill overnight
• Exfiltrate every S3 bucket and database snapshot in the account
• Close the account entirely

Password-only authentication fails against the most common attack vectors: credential stuffing from reused passwords leaked in unrelated breaches, phishing, and brute force. AWS root credentials show up in these attacks constantly because attackers know how valuable they are. A single factor that a human chose and might have reused elsewhere is not enough.

---

How to fix it

You must perform this from the AWS Management Console signed in as the root user. MFA cannot be enabled for root through the CLI or IAM API, because there is no way to authenticate as root programmatically for this operation.

Step 1: Sign in as root

1. Go to the AWS sign-in page and choose Root user
2. Enter the root email address and password

Step 2: Open the security credentials page

1. Click the account name in the top right, then choose Security credentials
2. Find the Multi-factor authentication (MFA) section
3. Click Assign MFA device

Step 3: Choose a device type

AWS supports three options. Pick based on your security posture:

• Hardware security key (FIDO2) such as a YubiKey. The strongest choice and resistant to phishing. Recommended for root.
• Virtual authenticator app such as Authy, 1Password, or Google Authenticator. Good and widely accessible.
• Hardware TOTP token, a physical key fob that displays codes.

Step 4: Register and verify

For a virtual authenticator, scan the QR code with your app, then enter two consecutive codes to confirm. For a hardware key, follow the browser prompt and touch the key. Once verified, MFA is active immediately.

Step 5: Confirm the fix

aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'
# Expected output: 1

---

How to prevent it from happening again

Because MFA enrollment for root is a manual console action, you cannot enforce it through IaC at the moment of creation. What you can do is detect drift continuously and fail fast when it appears.

Detect with a scheduled check

Run a daily check across every account in your organization. A simple version with the CLI:

#!/usr/bin/env bash
set -euo pipefail

mfa=$(aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled' --output text)

if [ "$mfa" != "1" ]; then
  echo "FAIL: root account has no MFA enabled"
  exit 1
fi
echo "PASS: root MFA enabled"

Enforce across an AWS Organization

AWS Config ships a managed rule, root-account-mfa-enabled, that you can deploy as an organization conformance pack so every member account is evaluated automatically:

{
  "ConfigRuleName": "root-account-mfa-enabled",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "ROOT_ACCOUNT_MFA_ENABLED"
  },
  "MaximumExecutionFrequency": "TwentyFour_Hours"
}

Pair this with an EventBridge rule that routes non-compliant findings to Slack or PagerDuty so the gap surfaces the same day it appears.

Bake it into account vending

If you use AWS Control Tower or a Landing Zone, add a manual MFA enrollment step to your account onboarding runbook and gate the account's promotion to production on that step being signed off. Treat root MFA the same as any other launch checklist item.

---

Best practices for the root account

Enabling MFA is the first move, not the last. The goal is to make root an account you essentially never touch.

• Stop using root for daily work. Create IAM users or, better, federate through IAM Identity Center with named roles. Root should only handle the handful of tasks that genuinely require it, like changing the account name or closing the account.
• Delete any root access keys. Root should have no programmatic credentials at all. Check with aws iam get-account-summary --query 'SummaryMap.AccountAccessKeysPresent' and remove any that exist.
• Use a strong, unique password generated by and stored in a password manager, not reused from anywhere else.
• Lock down the recovery email. Use a shared mailbox or distribution list that itself has MFA, not one person's individual inbox that leaves when they do.
• Alert on root usage. Set up a CloudWatch alarm on the CloudTrail event for root sign-in so any login generates an immediate notification.

Here is a quick CloudWatch metric filter for root logins, assuming CloudTrail logs flow to a log group:

aws logs put-metric-filter \
  --log-group-name "/aws/cloudtrail/logs" \
  --filter-name "RootAccountUsage" \
  --filter-pattern '{ $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }' \
  --metric-transformations \
      metricName=RootAccountUsageCount,metricNamespace=CloudTrailMetrics,metricValue=1

Treat the root user like the emergency master key to your building. You keep it in a safe, you log every time it leaves the safe, and you require two people and two factors to take it out. You do not carry it around on your keyring.

Enabling MFA on root takes about three minutes and closes off one of the highest-impact attack paths in your entire AWS footprint. There is no good reason to leave it open.