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

CIS AWS Foundations v1.2 control 1.14 focuses on a single high-impact identity: the AWS account root user. Root can bypass many guardrails because it holds privileges that typical IAM roles do not (for example, certain account-level actions and recovery workflows). If a root credential is compromised, your detective controls may alert you after the fact, but the prevention point is stronger authentication.

This requirement is straightforward but commonly fails audits for two reasons: (1) teams enable MFA on root, but use a virtual authenticator instead of a hardware factor, and (2) teams enable it once and stop collecting proof that it remains enabled across accounts. AWS Security Hub maps this expectation to IAM.6 in the CIS benchmark mapping, which gives you a scalable way to detect drift and generate evidence over time ¹.

Use this page as an operator’s runbook: who is in scope, how to implement it safely, what to save as evidence, what auditors ask, and how to roll it out in a controlled 30/60/90-day plan aligned to CIS AWS Foundations ².

Regulatory text

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

What that means operationally:

• You must enable a hardware MFA device for the root user of each AWS account in scope for the CIS AWS Foundations benchmark ².
• You must be able to demonstrate the control through AWS Security Hub’s CIS mapping (IAM.6) and/or equivalent verification methods that show the root user has MFA enabled and that it is specifically a hardware device ¹.
• You should run this as an ongoing control: implementation plus periodic verification and evidence retention, not a one-time setup.

Plain-English interpretation

Enable hardware-based multi-factor authentication for the AWS root user so that knowing the root password alone is not enough to sign in. Hardware MFA reduces the chance that a stolen password, phished token, or compromised endpoint leads to full-account takeover.

Who it applies to

Entities

• Any organization operating AWS accounts and measuring against CIS AWS Foundations Benchmark v1.2 ².
• This includes regulated and non-regulated environments when CIS is adopted as a security baseline.

Operational context (where it shows up)

• Single-account AWS environments where a small team still occasionally uses root.
• Multi-account AWS Organizations environments with many accounts, where root is rarely used but still exists per account.
• M&A or rapid account provisioning environments, where “new account” processes often forget root hardening.

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

Step 1: Define scope and owners ²

1. Inventory AWS accounts that must meet CIS AWS Foundations. Start from AWS Organizations, CMDB, or your cloud account registry.
2. Assign a named control owner for root credential custody and MFA lifecycle for each account (usually Cloud Platform or Security Engineering).
3. Decide where hardware MFA devices will be physically stored and who is authorized to access them (treat as break-glass material).

Practical tip: If you cannot name the human owner for each account’s root MFA custody, auditors will treat the control as fragile even if the setting is currently enabled.

Step 2: Acquire hardware MFA and document custody

1. Select an AWS-compatible hardware MFA type used in your environment.
2. Record device identifiers, custodian, storage location, and which AWS account root it maps to.
3. Establish a check-in/check-out process for the device (even a lightweight log) to show controlled access.

Step 3: Enable hardware MFA on the root user ²

For each AWS account:

1. Sign in as root only for the minimum time needed to enroll MFA.
2. Go to the root user security settings and register the hardware MFA device.
3. Confirm MFA is enabled and tested by performing a controlled re-authentication (without performing other administrative tasks).

Control intent: The requirement is specifically hardware MFA for root, not “any MFA.” If your process permits switching to a virtual authenticator later without approval, you have a drift path.

Step 4: Reduce root usage and build a break-glass workflow

CIS 1.14 is about MFA, but auditors will ask how root is used in practice. Put these guardrails around root:

• Use IAM roles for daily admin work; reserve root for limited account management tasks.
• Require a ticket/approval to access the hardware token (even for Security).
• Log and review root sign-in events as part of incident detection.

Step 5: Continuous monitoring with Security Hub (IAM.6) + periodic verification

1. Enable AWS Security Hub and the CIS AWS Foundations benchmark checks where you manage findings ¹.
2. Track the mapped control IAM.6 for each account and treat failures as incidents or high-priority findings ¹.
3. Add a periodic control check (monthly or quarterly, based on your risk tolerance) to confirm:
   • Root MFA is still enabled.
   • The MFA method is still hardware, not downgraded.

Where Daydream fits naturally: Daydream can track the requirement, map it to your AWS account control owners, and manage the recurring evidence requests and attestations so the proof remains audit-ready without recreating screenshots every cycle.

Required evidence and artifacts to retain

Retain evidence that proves: (a) root has MFA, (b) it is hardware, and (c) it remains enabled.

Minimum evidence set (recommended):

• Security Hub evidence: Exported findings showing CIS mapping status for IAM.6 per account and the timestamp of evaluation ¹.
• Per-account root MFA enrollment proof: A screenshot or configuration capture from the root security settings showing MFA enabled and device type indicated as hardware.
• Hardware MFA custody record: Device serial/identifier, assigned account, custodian, storage location, and access log.
• Break-glass procedure: A short SOP describing when root is allowed, how the token is retrieved, required approvals, and post-use review steps.
• Periodic verification log: Attestation records (who checked, date, result, exceptions).

Evidence quality rules that prevent audit pain:

• Evidence must be account-specific; “org-level” documents rarely satisfy root controls because root is per account.
• Evidence must be time-bound; a screenshot from long ago with no ongoing checks reads as “point-in-time compliance.”

Common exam/audit questions and hangups

Auditors and assessors tend to focus on these:

1. “Show me the root user MFA device type.” They want hardware, not just “MFA enabled.”
2. “How do you ensure this stays enabled?” Expect questions about monitoring (Security Hub IAM.6) and periodic checks ¹.
3. “Who can access the hardware token?” If many people can retrieve it without logging or approval, the control is weaker.
4. “Do all accounts meet this, including dev/sandbox?” If you scope out accounts, be ready to justify the boundary.
5. “What happens if the device is lost?” You need a replacement and recovery workflow with documented approvals.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	How to avoid it
Enabling virtual MFA (authenticator app) for root	Doesn’t meet “hardware MFA” expectation for CIS 1.14 2	Specify “hardware only” in your standard and validate device type in evidence
Treating AWS Organizations as “covering” root	Root exists per account regardless of org policies	Track implementation per account; keep an account registry with control status
No custody controls for the physical device	Token can be accessed casually; auditors question effectiveness	Use locked storage + checkout log + named custodians
One-time screenshot, no ongoing verification	Control drifts silently	Use Security Hub IAM.6 monitoring and periodic re-attestation 1
Root used for normal admin work	Expands exposure window	Enforce role-based admin; document break-glass only

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this specific CIS requirement. Practically, the risk is straightforward: root compromise is a high-blast-radius event. Hardware MFA is a compensating barrier that reduces the chance that a single stolen password leads to full control of the AWS account.

For governance, treat this as a baseline identity control tied to account takeover prevention. If this requirement fails in one account, assume the same process gap could exist elsewhere (new accounts, acquired environments, labs promoted to prod).

30/60/90-day execution plan

First 30 days (stabilize and cover the highest-risk accounts)

• Confirm which AWS accounts are in scope and identify each root credential custodian.
• Procure hardware MFA devices and define the custody process.
• Enable hardware MFA for root in production and security-tooling accounts first.
• Turn on Security Hub CIS checks and start collecting IAM.6 evidence exports ¹.

Days 31–60 (scale to all accounts and harden operations)

• Roll out root hardware MFA enrollment across remaining accounts using a repeatable checklist.
• Implement a formal break-glass workflow (ticketing + approvals + post-use review).
• Set up an exception process for blocked accounts (lost device, inaccessible root email) with remediation deadlines.

Days 61–90 (make it audit-proof and resilient)

• Run a full internal “audit”: pick a sample of accounts and reproduce evidence from scratch (Security Hub + console proof + custody logs).
• Add periodic verification into your GRC cadence and assign recurring tasks in your system of record.
• Centralize evidence collection and control mapping in Daydream so audits pull from a single source of truth rather than ad hoc screenshots.

Frequently Asked Questions

Do I need hardware MFA on the root user if nobody uses root?

Yes. Root still exists and is a takeover target, and the CIS requirement is explicit about enabling hardware MFA for root ².

Is virtual MFA (authenticator app) acceptable for CIS AWS Foundations v1.2 1.14?

The requirement is specifically “hardware MFA” for the root user ². If you use a virtual authenticator, document it as an exception and plan remediation.

How do I prove compliance quickly to an auditor?

Provide Security Hub evidence for the mapped control (IAM.6) and a per-account capture showing root MFA enabled with a hardware device ¹.

How does this work in a multi-account AWS Organizations setup?

Root MFA is configured per member account. Centralize tracking and evidence, but complete enrollment and custody mapping for every account individually.

What artifacts are most likely to be challenged in an audit?

Point-in-time screenshots without ongoing verification, and evidence that doesn’t show the MFA device is hardware. Pair console proof with Security Hub IAM.6 exports and a recurring verification record ¹.

What if we lose the hardware MFA device?

Treat it like a security incident for that account’s break-glass access. Follow a documented recovery path, replace the device, re-enroll hardware MFA, and retain the incident record plus updated custody documentation.

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; AWS Security Hub CIS AWS Foundations mapping table