CIS AWS Foundations v1.2 1.13: MFA should be enabled for the root user

To meet the cis aws foundations v1.2 1.13: mfa should be enabled for the root user requirement, you must enable multi-factor authentication (MFA) on the AWS account root user and prove it stays enabled. Operationally, that means selecting a supported MFA method, registering it to the root user, restricting root use to break-glass scenarios, and continuously monitoring for drift via AWS Security Hub’s CIS mapping.

Key takeaways:

• Root MFA is a baseline guardrail for catastrophic account takeover risk and is explicitly mapped in AWS Security Hub (Control IAM.9). ¹
• Auditors will ask for both current state evidence (root has MFA) and operating evidence (monitoring, break-glass process, and periodic verification). ²
• Your fastest path is: enable root MFA, lock down root access paths, and automate detection/response for any root MFA disablement. ¹

Root credentials are the keys to the kingdom in AWS. They bypass most of the controls you rely on day-to-day, including permission boundaries, SCPs, and many IAM governance patterns. CIS AWS Foundations v1.2 control 1.13 exists because the most damaging failures are “account-level” failures: if an attacker gets root, they can change billing, delete logs, remove security tooling, and cut off your team.

This requirement is straightforward to implement, but it’s easy to fail in audits for one reason: teams enable root MFA once and treat it as “done,” without building evidence, monitoring, and break-glass discipline around it. AWS Security Hub maps this expectation in its CIS AWS Foundations benchmark integration, so you can operationalize the control as a continuously tested baseline rather than a one-time checkbox. ¹

This page tells a Compliance Officer, CCO, or GRC lead exactly what to require from Cloud/IAM teams, how to verify it, what evidence to retain, and how to roll it out across multi-account environments without slowing operations. ²

Requirement: CIS AWS Foundations v1.2 1.13 (Root user MFA)

Goal: Ensure MFA is enabled for the AWS account root user and keep it enabled as an operating control. ²

Security Hub mapping: This requirement is assessed via AWS Security Hub’s CIS AWS Foundations mapping (commonly surfaced as control IAM.9 in that mapping). ¹

Regulatory text

Excerpt (provided): “Implement CIS AWS Foundations Benchmark v1.2 requirement 1.13 as mapped in AWS Security Hub.” ³

Operator interpretation: You are expected to (1) enable MFA for the root user of each in-scope AWS account, and (2) manage it like a control: define ownership, prevent accidental removal, monitor continuously (or near-continuously), and retain evidence that it is configured and stays configured. ³

Plain-English interpretation

• The AWS root user must have MFA turned on.
• Root should be used only for tightly controlled, exceptional actions (break-glass), and your process must preserve MFA rather than bypass it.
• You must be able to show an auditor: “root MFA is enabled” and “we would detect and respond if it were disabled.” ²

Who it applies to

Entities

• Any organization operating AWS accounts where CIS AWS Foundations alignment is required by policy, customer commitments, or internal baseline standards. ²

Operational context (where teams get tripped up)

• Multi-account AWS Organizations: You must cover every account, including shared services, sandbox, and acquired environments.
• M&A / inherited accounts: Root MFA is frequently missing because the root owner is unclear.
• Emergency access patterns: If break-glass is informal, teams “temporarily” weaken root access and fail to restore it.

What you actually need to do (step-by-step)

Step 1: Assign accountable owners

1. Assign a control owner (usually Cloud Security/IAM) and a control tester (GRC or Security Assurance).
2. Define escalation for lost MFA device scenarios (who engages AWS Support, who approves identity verification steps).

Deliverable: Control statement and RACI for root credential custody and MFA lifecycle. ²

Step 2: Confirm root user status per AWS account

For each AWS account:

1. Identify where root email inbox access is controlled (shared mailbox vs. ticketed access).
2. Confirm whether root has MFA enabled using AWS-native signals (console view, IAM credential report, or Security Hub finding for the mapped control). ¹

Tip for GRC leads: Require a per-account attestation from Cloud Security plus machine-produced evidence (see “Evidence” section) rather than screenshots alone.

Step 3: Enable MFA on the root user

1. Sign in as the root user (this should be a controlled, ticketed activity).
2. Register an MFA factor for root (hardware or virtual, per your security standard).
3. Record the MFA device identifier/serial (where applicable) in your secure inventory.

Control intent: Root authentication requires something beyond the password, reducing account takeover risk from credential theft. ²

Step 4: Implement “root is break-glass” operating rules

Write and enforce operational rules that make the control durable:

• Root use requires an approved ticket and documented business justification.
• Root sessions must be time-bounded and followed by post-use review.
• Root credentials (password reset, MFA reset) require dual approval and documented identity verification steps.

This is where audits are won: you show that enabling MFA is not a one-time event; it’s governed. ²

Step 5: Turn on continuous detection using AWS Security Hub

1. Enable AWS Security Hub where you manage security posture.
2. Enable the CIS AWS Foundations benchmark checks in Security Hub.
3. Route findings for the mapped control (IAM.9 in the CIS mapping) into your ticketing/incident workflow with clear SLAs and owners. ¹

Practical requirement: Treat “root MFA disabled” as a high-urgency security misconfiguration, even if your CIS severity rating is “medium,” because the blast radius is account-wide. ²

Step 6: Set periodic verification and drift response

Create an operating cadence:

• Re-verify root MFA status on a scheduled basis.
• After any root credential event (password reset, email change, device replacement), re-verify root MFA and document the outcome.
• Track exceptions (for example, accounts in transition) with an approved remediation plan and a target date.

Your goal is audit-ready consistency: every account, same control, same evidence format. ²

Required evidence and artifacts to retain

Auditors typically want configuration evidence plus operating evidence.

Configuration evidence ⁴

• Security Hub compliance status/export showing the CIS mapping result for the root MFA control. ¹
• IAM Credential Report entry indicating root MFA status (retain the report output or exported fields relevant to MFA).
• If you must use screenshots, pair them with machine-produced exports to reduce screenshot-only risk.

Operating evidence

• Written policy/procedure: “Root user access and MFA management standard.”
• Break-glass runbook and approval workflow (tickets, change records).
• Evidence of monitoring: Security Hub integration settings, alert routing rules, and sample tickets created from findings. ¹
• Exception log with approvals and closure evidence.

Evidence retention tip

Keep evidence per account, per period, and map it directly to “CIS AWS Foundations v1.2 1.13.” This reduces audit friction when sampling starts. ²

Common exam/audit questions and hangups

1. “Show me root MFA is enabled in all accounts.” Expect sampling across accounts, including non-prod.
2. “Who can access the root email inbox?” If the inbox is uncontrolled, MFA can be reset by the wrong party.
3. “What happens if the MFA device is lost?” Auditors look for a documented recovery process with approvals.
4. “How do you know it stays enabled?” You need monitoring (Security Hub findings, alerting, ticketing). ¹

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails audits	Fix
Enabling root MFA once, no monitoring	No operating evidence; drift goes undetected	Enable CIS checks in Security Hub and route findings to tickets. 1
Root email in an unmanaged mailbox	Email takeover enables password/MFA resets	Put root email under controlled access with strong identity governance
Break-glass is “whoever needs it”	Root use becomes routine; approvals missing	Require tickets, approvals, post-use review, and logged justification
Evidence is screenshots only	Hard to prove completeness and timing	Store Security Hub exports/credential report outputs plus change records

Enforcement context and risk implications

No public enforcement cases were provided in the supplied sources for this specific CIS requirement, so you should not position it as a direct “regulatory penalty trigger.” What you can state precisely: CIS AWS Foundations is a widely used security baseline, and AWS Security Hub exposes automated checks for it; failure to meet baseline controls commonly becomes an audit finding in customer assessments, SOC reports, and internal security reviews. ³

Risk-wise, root MFA gaps are high-impact because root can irreversibly change account security posture (including disabling monitoring and altering access controls). Treat this as an account integrity control, not an IAM housekeeping task. ²

Practical 30/60/90-day execution plan

Days 0–30: Establish and remediate the obvious gaps

• Inventory AWS accounts in scope and confirm which have root MFA enabled (use Security Hub where available). ¹
• Enable root MFA for all accounts that are accessible and owned.
• Publish the root access + MFA management procedure and assign owners. ²

Deliverables: Account inventory, root MFA status register, approved procedure, initial evidence pack.

Days 31–60: Operationalize monitoring and break-glass

• Enable CIS benchmark checks in Security Hub and confirm IAM.9 findings appear and route correctly. ¹
• Build ticket templates for “root MFA disabled” with required remediation notes.
• Run a tabletop exercise for lost MFA device / root credential recovery and update the runbook.

Deliverables: Alert-to-ticket workflow, break-glass runbook, tabletop notes and action items.

Days 61–90: Prove control operation and reduce audit friction

• Perform a formal control test: select a sample of accounts, pull evidence, reconcile discrepancies, and document results.
• Tune exception handling and ensure every exception has an owner and closure criteria.
• Add this control to your ongoing compliance calendar and evidence repository (so audits become retrieval, not scramble). ²

Deliverables: Control test report, exception log, repeatable evidence collection process.

Where Daydream fits (without slowing you down)

Most teams fail this requirement in documentation and repeatability, not in the actual MFA click-path. Daydream helps you standardize the requirement narrative, map it to Security Hub evidence pulls, and keep a clean audit trail of periodic verification across accounts so your team stops rebuilding the same evidence pack each audit cycle. ⁵

Frequently Asked Questions

Does this requirement apply if we never use the root user?

Yes. The control is about preventing catastrophic misuse if root credentials are compromised or needed for break-glass. “We don’t use root” is a good practice, but auditors still expect root MFA to be enabled. ²

Is AWS Organizations SCP enough to satisfy root MFA?

No. SCPs don’t replace root MFA because root authentication happens before most authorization controls matter. The requirement is explicit: enable MFA for the root user. ²

What evidence is strongest for an audit: screenshots or exports?

Machine-produced evidence (Security Hub CIS check results and IAM credential report outputs) is stronger and easier to sample across accounts. Keep screenshots only as supplemental context. ¹

How do we handle lost or replaced root MFA devices?

Treat it as a controlled recovery event with approvals, identity verification steps, and immediate re-enrollment of MFA. Retain the ticket/change record and post-change verification evidence. ²

Can we centralize this control across many AWS accounts?

You can centralize monitoring through Security Hub, but MFA enrollment still happens per account’s root user. Design a repeatable enrollment runbook and a single evidence format across accounts. ¹

What is the fastest way to detect drift?

Turn on CIS AWS Foundations checks in Security Hub and route failures for the mapped control into your incident/ticket workflow so “root MFA not enabled” creates visible work. ¹

Related compliance topics

• 03.01.18: Access Control for Mobile Devices
• 03.01.19: Withdrawn
• 03.01.20: Use of External Systems
• 03.01.21: Withdrawn
• 03.01.22: Publicly Accessible Content

Footnotes

1. AWS Security Hub CIS AWS Foundations mapping table

2. CIS AWS Foundations Benchmark

3. CIS AWS Foundations Benchmark; Source: AWS Security Hub CIS AWS Foundations mapping table

4. AWS account

5. AWS Security Hub CIS AWS Foundations mapping table; Source: CIS AWS Foundations Benchmark