CIS AWS Foundations v1.2 1.2: MFA should be enabled for all IAM users that have a console password

To meet CIS AWS Foundations v1.2 1.2, every AWS IAM user who can sign in to the AWS Management Console (has a console password) must have multi-factor authentication (MFA) enabled, and you must be able to prove it continuously. Operationalize this by eliminating long-lived console IAM users where possible, enforcing MFA on any remaining users, and monitoring drift with Security Hub findings. ¹

Key takeaways:

• Scope is specific: IAM users with a console password must have MFA enabled. ²
• The fastest path is to reduce IAM console users, then enforce MFA for any exceptions. ³
• Auditors will ask for evidence of current state and ongoing monitoring, not a one-time screenshot. ³

CIS AWS Foundations v1.2 1.2 is a simple requirement with tricky operational edges: you’re compliant only if every IAM user who can log into the AWS Console is protected by MFA, and you can demonstrate the control keeps working over time. ²

From a GRC perspective, this is an access control requirement with immediate blast-radius implications. A single IAM user with a console password and no MFA creates a credible path to account takeover via phishing, password reuse, or credential stuffing. Your job is to make that path expensive and observable: require a second factor, remove unnecessary console access, and build a repeatable evidence trail. ²

This page focuses on what a Compliance Officer, CCO, or GRC lead needs to operationalize quickly: scope boundaries (who counts as “console password”), implementation patterns that work in real AWS organizations (including multi-account setups), the minimum evidence bundle to retain, and the audit questions you should expect. Where possible, align your program language with how AWS Security Hub maps the CIS benchmark so engineering and compliance talk about the same control. ³

Requirement: cis aws foundations v1.2 1.2: mfa should be enabled for all iam users that have a console password requirement

Control objective: prevent console sign-in with only a password for any IAM user.

Pass condition (operational):

• If an IAM user has a console password, that user has at least one MFA device enabled.
• You can detect and remediate any future drift (new console users or MFA removed). ¹

Regulatory text

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

What the operator must do:

• Implement the CIS v1.2 control that requires MFA for any IAM user with a console password.
• Use the AWS Security Hub CIS mapping as your operational reference point for how this is assessed and reported in AWS environments. ¹

Plain-English interpretation

If a human can type a username and password into the AWS Management Console for an IAM user, that login must also require a second factor. “We told people to use MFA” is not enough. You need a technical state where MFA is actually enabled on every in-scope IAM user and a way to prove the current state across accounts. ²

Who it applies to (entity and operational context)

Entity scope

• Any organization operating workloads in AWS and using IAM users for console access. ²

System/asset scope

• All AWS accounts in scope for your CIS program (production, staging, shared services, sandbox if included).
• IAM users with console passwords. Users without console passwords (API-only) are out of scope for this specific requirement, though they may be in scope for other controls. ²

Operational scope

• Identity administration (IAM admins, platform teams).
• Security operations (Security Hub findings triage).
• HR/IT onboarding/offboarding if IAM users are tied to joiner/mover/leaver processes.

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

Step 1: Establish an owner, run cadence, and exception policy (control card)

Write a one-page control card your operators can run:

• Owner: cloud security or IAM platform owner.
• Frequency: continuous detection (Security Hub) plus periodic review of exceptions and evidence bundle.
• Trigger events: new IAM user created, console password set/reset, MFA device deactivated, break-glass access invoked.
• Exceptions: break-glass accounts and vendor/third-party support users (time-bound, compensating controls, approval required).

This is the difference between “we configured it once” and “we operate it.” ²

Step 2: Inventory IAM users with console access

You need a definitive list of IAM users who have console passwords.

• Pull IAM credential reports per AWS account (or via your multi-account tooling).
• Identify users where a console password exists (these are in scope for MFA enforcement).

Operational note: multi-account environments fail audits because teams only check the “main” account. Treat this as an org-wide requirement even if your reporting rolls up centrally. ³

Step 3: Reduce scope by removing console passwords where you don’t need them

This control gets easier when fewer IAM users can log in to the console.

• Prefer centralized identity (for example, SSO/federation) for workforce access rather than long-lived IAM users.
• For service and automation needs, prefer roles and short-lived credentials rather than IAM users with passwords.
• Disable console access for users who should not have it.

GRC action: require a business justification for any IAM user with a console password, and make that justification part of your evidence package.

Step 4: Enable MFA for every remaining in-scope IAM user

For each IAM user with a console password:

• Ensure an MFA device is assigned and activated.
• Ensure the user can successfully authenticate with MFA (a “configured but unusable” MFA device becomes an emergency ticket during an incident).

Design decision to document (auditors ask): what MFA methods you allow (virtual MFA apps, hardware keys) and how you handle lost devices.

Step 5: Enforce and monitor continuously using AWS Security Hub mapping

Turn the requirement into ongoing control operation:

• Enable AWS Security Hub in accounts in scope and enable the CIS AWS Foundations benchmark checks that map to this requirement. ³
• Route findings to your ticketing system with a clear SLA and owner.
• Define remediation steps for common finding causes: new console user without MFA, MFA device removed, break-glass account drift.

Where Daydream fits naturally: use Daydream to store the control card, evidence bundle definitions, and recurring control health checks so you can show auditors the control’s design, operation, and remediation tracking without assembling artifacts by hand.

Step 6: Handle exceptions safely (break-glass and third-party access)

You will have edge cases. Treat them as managed risk, not silent noncompliance.

• Break-glass: keep it rare, monitored, and approved. If it has a console password, it still needs MFA; if you cannot meet that, document a compensating control and a deadline to remediate.
• Third party access: vendors or consultants should generally use federated access or a tightly governed path. If an IAM user must exist temporarily, require MFA and set an expiry process (time-bound access plus offboarding).

Required evidence and artifacts to retain

Maintain an evidence bundle that proves both current compliance and repeatable operation:

Configuration/state evidence

• IAM credential reports (or equivalent exports) showing console-password users and MFA status per account.
• Security Hub CIS benchmark results/screenshots or exported findings referencing the relevant CIS mapping. ³
• A list of IAM users with console passwords and the associated MFA device presence (date-stamped).

Operational evidence

• Control card (owner, cadence, triggers, exception rules).
• Tickets or change records for remediation of noncompliant users (open → fixed → validated).
• Exception register entries (break-glass, temporary third-party users) with approval, compensating controls, and expiration.

Retention and location

• Store evidence in a system with immutable history or audit logging (GRC repository, ticketing attachments, or controlled cloud storage with access logs). Document where it lives so you can retrieve it fast.

Common exam/audit questions and hangups

Expect these questions and prepare short, specific answers:

1. “How do you know every account is covered?”
   Show Security Hub enablement and CIS mapping coverage across accounts. ³

2. “Define ‘console password’ in your process.”
   Point to your credential report logic and your joiner process controls.

3. “How quickly do you remediate a new noncompliant user?”
   Show your ticket workflow and alerting path from Security Hub to owners. ³

4. “What about break-glass access?”
   Show your exception register, approvals, monitoring, and periodic review.

5. “Do you rely on policy, or do you have technical enforcement?”
   Show MFA enabled state and detection of drift; policy alone will be challenged.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Only checking the management account	Leaves member accounts noncompliant	Inventory and report across all in-scope accounts; centralize reporting. 3
Treating “MFA required” as a policy statement	Auditors test actual config	Keep credential reports + Security Hub findings as primary evidence. 3
Allowing IAM console users to proliferate	Increases ongoing admin load and audit risk	Require justification and prefer federation; remove console passwords where possible.
Unmanaged exceptions (break-glass)	Becomes the “one account” auditors focus on	Formal exception register with approvals, monitoring, and expiry.
No drift monitoring	You pass once, fail later	Continuous detection via Security Hub + remediation workflow. 3

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific actions. Practically, this control maps to common customer diligence and audit expectations around account takeover prevention and privileged access hygiene. Failure typically surfaces as a control deficiency (for example, during SOC 2-style access control testing) and as a material risk in cloud security reviews because a single password-only console user can enable broad unauthorized changes in AWS. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and get visibility)

• Name an owner and publish the control card (objective, scope, exceptions, operating cadence).
• Enable or validate AWS Security Hub CIS mapping checks in all in-scope accounts and set up alert routing. ³
• Export credential reports; identify all IAM users with console passwords; open remediation tickets for any without MFA.

Days 31–60 (reduce attack surface and formalize exceptions)

• Remove console passwords from users who do not need console access; migrate to federated access where feasible.
• Implement an exception register for break-glass and third-party access; require approvals and expiry.
• Define the minimum evidence bundle and store it in a consistent location (GRC system, Daydream, or controlled repository).

Days 61–90 (operationalize and prove repeatability)

• Run a formal control health check: reconcile Security Hub findings vs. IAM exports, confirm ticket closure quality, and validate exceptions.
• Add onboarding/offboarding hooks: new console users must enroll MFA before access is granted.
• Prepare your audit packet: control card, latest evidence bundle, exception register, and remediation metrics from your ticketing workflow. ³

Frequently Asked Questions

Does this apply to IAM users that only use access keys (no console access)?

This requirement is scoped to IAM users that have a console password. If an IAM user is API-only, it is not in scope for CIS AWS Foundations v1.2 1.2, though other CIS controls may still apply. ²

If we use SSO/federation for console access, do we still need to worry about this?

You still need to check for any remaining IAM users with console passwords, including legacy accounts and break-glass users. If there are none, this specific requirement becomes easier to evidence because your in-scope population is empty or very small. ²

What evidence is strongest for auditors: screenshots, exports, or Security Hub?

Prefer machine-generated exports (credential reports) plus Security Hub CIS benchmark findings for ongoing monitoring. Screenshots help for a point-in-time explanation, but they are weak as the primary evidence source. ³

How should we handle break-glass accounts under this control?

If a break-glass account has a console password, enable MFA and control access to the MFA device. If you have a temporary exception, document approval, compensating monitoring, and a deadline to remove the exception.

We have a third party who insists on an IAM user for console troubleshooting. Is that allowed?

It can be, but treat it as an exception-driven design: require MFA, time-bound access, tight permissions, and an offboarding trigger. Keep the approval and the expiry record in your exception register.

What’s the quickest way to fail this requirement after you pass it once?

A new IAM user gets created with a console password during an incident or project, and MFA enrollment is skipped. Drift detection through Security Hub plus a “no console access until MFA enrolled” onboarding step prevents that. ³

Footnotes

1. CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table

2. CIS AWS Foundations Benchmark

3. AWS Security Hub CIS AWS Foundations mapping table