CIS AWS Foundations v1.2 3.2: Ensure a log metric filter and alarm exist for Management Console sign-in without MFA

To meet CIS AWS Foundations v1.2 3.2, you must detect AWS Management Console logins that occur without MFA by creating a CloudWatch Logs metric filter on CloudTrail sign-in events and attaching a CloudWatch alarm that notifies your security responders. Operationally, this is a detection-and-alerting control, backed by retained evidence. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Key takeaways:

• You need CloudTrail management events delivered to CloudWatch Logs, then a metric filter that matches ConsoleLogin where MFAUsed = "No".
• You must attach a CloudWatch alarm with defined notification routing (SNS, ticketing, on-call) and retain evidence of operation.
• Auditors will look for multi-account coverage, correct filter logic, and proof alerts are reviewed and acted on.

“Management Console sign-in without MFA” is one of the highest-signal identity events in AWS because it indicates a user authenticated with only a password (or equivalent) to access the console. CIS AWS Foundations v1.2 control 3.2 requires you to detect and alert on that event by using a log metric filter and alarm. This does not replace MFA enforcement. It gives you rapid visibility when MFA is missing, bypassed, misconfigured, or temporarily exempted.

For a CCO or GRC lead, the fastest path is to treat this requirement as a small, testable detection pipeline: (1) ensure CloudTrail is recording console sign-in events, (2) ensure those logs land in CloudWatch Logs, (3) create the metric filter that increments a metric when “ConsoleLogin” happens without MFA, (4) alarm on that metric and route notifications to the right responders, and (5) retain evidence that it works and is reviewed.

AWS Security Hub maps this requirement to a benchmark-aligned control, which gives you a ready-made place to track coverage and exceptions in a way auditors understand. (AWS Security Hub CIS AWS Foundations mapping table)

Regulatory text

Excerpt (as provided): “Implement CIS AWS Foundations Benchmark v1.2 requirement 3.2 as mapped in AWS Security Hub.” (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Operator meaning: You must implement the CIS AWS Foundations v1.2 safeguard that ensures a CloudWatch Logs metric filter and a CloudWatch alarm exist to identify AWS Management Console sign-ins where MFA was not used. Evidence must show the control exists, covers in-scope accounts, and is operating. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Plain-English interpretation (what the requirement is asking)

Create an automated alert that triggers when someone logs into the AWS console without MFA, based on CloudTrail logs. If the event occurs, the system should notify a monitored channel (security inbox, on-call, SIEM, or ticketing queue) so your team can triage quickly.

This is a detective control. It assumes:

• You record the right events (CloudTrail).
• You can query them in near real time (CloudWatch Logs metric filter).
• You raise an alert with a defined response path (CloudWatch alarm + SNS or integrations).

Who it applies to

Entity scope

• Any organization operating AWS accounts and claiming alignment to CIS AWS Foundations Benchmark v1.2. (CIS AWS Foundations Benchmark)

Operational scope (what environments)

Applies to:

• Production and non-production AWS accounts where console access exists (even if “discouraged”).
• Root and IAM user console activity (where recorded by CloudTrail).
• Organizations using AWS Organizations, Control Tower, or standalone accounts.

Does not meaningfully apply where:

• Console access is fully disabled for all identities (rare in practice). If you claim this, expect auditors to ask for proof of enforcement and exceptions.

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

Below is an implementation path that works for most regulated environments. Adjust ownership (security vs. cloud platform) but keep the artifacts.

Step 1: Confirm CloudTrail captures console sign-in events

1. Verify you have an organization trail (preferred) or per-account trails that include management events.
2. Confirm CloudTrail logs are being delivered consistently (S3 is common; CloudWatch Logs is required for the metric filter approach described here).

Evidence to capture now: Screenshot/export of CloudTrail trail configuration showing management events enabled and destinations configured.

Step 2: Ensure CloudTrail is delivered to CloudWatch Logs

1. In CloudTrail configuration, enable CloudWatch Logs delivery.
2. Confirm the CloudWatch Logs log group exists and is receiving events.
3. Validate IAM permissions for CloudTrail to put log events.

Audit hangup: Teams often have CloudTrail to S3 only. CIS 3.2 specifically expects a log metric filter and alarm, which is typically implemented via CloudWatch Logs + metric filters.

Step 3: Create the log metric filter for “ConsoleLogin without MFA”

1. In CloudWatch Logs, choose the log group receiving CloudTrail events.
2. Create a metric filter that matches:
   • eventName = ConsoleLogin
   • and the MFA indicator shows MFA was not used (commonly represented as an element like additionalEventData.MFAUsed = No in the CloudTrail event payload).
3. Set the filter to publish to a dedicated metric namespace (example: CIS/CloudTrail) with a metric name that is explicit (example: ConsoleLoginWithoutMFA).
4. Set metric value to 1 for each match.

Control intent: Every time a console login occurs without MFA, the metric increments.

Practical validation: Pull a recent ConsoleLogin event from CloudTrail and ensure the filter pattern matches the exact JSON structure you receive. Mismatched patterns are the #1 cause of “we have a filter” but no detections.

Step 4: Create the CloudWatch alarm and route notifications

1. Create a CloudWatch alarm on the ConsoleLoginWithoutMFA metric.

2. Threshold: alarm when the metric is >= 1 within an evaluation window appropriate for your response model (fast detection is the point; pick a window that avoids missing single events).

3. Notification action: publish to an SNS topic that routes to:

   • Security on-call paging, and/or
   • A monitored mailbox, and/or
   • SIEM ingestion, and/or
   • Ticketing automation.

4. Define who acknowledges and how quickly they triage (runbook step).

Minimum operational bar: The alarm must reach a monitored channel and produce a trackable triage outcome (ticket, case, or incident record).

Step 5: Build the triage runbook (what responders do)

When the alarm triggers, responders should be able to answer:

• Which principal logged in (IAM user, assumed role session, federated principal if present)?
• Source IP, user agent, geo context if available
• Whether the identity is supposed to have MFA enforced
• Whether it is a false positive (expected break-glass) vs. suspicious

Runbook actions typically include:

• Confirm identity owner and business justification
• Check whether MFA is configured and enforced
• Review related CloudTrail events around the same time (privilege changes, new access keys, failed logins)
• Contain if needed (disable user, revoke sessions, rotate credentials)

Step 6: Periodic verification (keep it from rotting)

Set an operational cadence to:

• Reconfirm the filter still matches the CloudTrail schema you receive.
• Confirm the SNS subscriptions still work (email changes, pager rotations).
• Review any exceptions (break-glass accounts) and document approvals.

Daydream fit (earned mention): If you’re tracking CIS alignment across many AWS accounts, Daydream can store the control mapping, evidence snapshots, and periodic verification results so audits don’t turn into “find screenshots in Slack.” Keep the owner, last test date, and evidence links tied to this requirement.

Required evidence and artifacts to retain

Keep evidence that proves existence, coverage, and operation:

Configuration evidence (existence)

• CloudTrail trail settings showing management events enabled and delivery to CloudWatch Logs.
• CloudWatch Logs metric filter configuration (filter pattern, target metric namespace/name).
• CloudWatch alarm configuration (metric, threshold, evaluation, actions).
• SNS topic configuration and subscriptions (who receives alerts).

Operational evidence (operation)

• At least one test record showing the alarm can fire and be received (change record, test ticket, or incident drill outcome).
• Ticket/incident samples showing triage occurred (sanitize sensitive details).
• Runbook document and ownership (who responds, escalation path).

Coverage evidence (scope)

• Account inventory listing which AWS accounts are in scope and how the alarm is deployed across them (Org-wide stack set, Control Tower, or per-account IaC).
• Exceptions register for accounts/users with approved alternative controls.

Common exam/audit questions and hangups

Auditor question	What they are really testing	What to show
“How do you know you detect console logins without MFA?”	Existence + correct logic	Filter pattern, sample CloudTrail event, metric increment proof
“Is this enabled in every production account?”	Coverage	Org account list + deployment method + Security Hub view (if used) (AWS Security Hub CIS AWS Foundations mapping table)
“Who gets the alert, and what do they do?”	Operational response	SNS subscriptions + runbook + tickets
“How do you prevent drift?”	Ongoing control operation	Periodic verification records + IaC pipeline evidence

Frequent implementation mistakes (and how to avoid them)

1. CloudTrail not sent to CloudWatch Logs.
   Fix: Enable CloudWatch Logs delivery, then confirm ingestion before building filters.

2. Filter pattern doesn’t match your actual CloudTrail JSON.
   Fix: Copy a real ConsoleLogin event from your environment and match on fields exactly as received.

3. Alarm exists but not routed to a monitored channel.
   Fix: Tie the alarm to SNS with owned subscriptions, and test delivery after every on-call rotation change.

4. Only implemented in one “main” account.
   Fix: Use an org-wide deployment method (StackSets / Control Tower guardrails where applicable) and maintain a coverage list.

5. No evidence of review.
   Fix: Require a ticket outcome for every alert (benign, expected, incident) and sample those tickets for audit.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this specific CIS requirement, so treat this as a benchmark-driven expectation rather than a directly enforceable regulation in itself. The risk is still concrete: console access without MFA increases the chance that credential theft or password reuse becomes an account compromise, and without alerting you may learn about the compromise late.

From a governance angle, auditors often treat CIS AWS Foundations as a “reasonable security baseline.” Failure to implement 3.2 can be framed as a detection gap around identity and access management activity. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Practical 30/60/90-day execution plan

First 30 days: Stand up detection in priority accounts

• Confirm CloudTrail coverage and CloudWatch Logs delivery for production accounts.
• Implement the metric filter and alarm in those accounts.
• Route notifications to a monitored security channel.
• Write a one-page runbook and assign ownership.

Days 31–60: Expand coverage and harden operations

• Roll out across all in-scope accounts via consistent deployment (IaC preferred).
• Add test procedure and schedule verification checks.
• Create an exceptions workflow for break-glass access (approval + time-bound review).

Days 61–90: Evidence maturity and audit readiness

• Run an internal control test: generate a known test event and confirm end-to-end alerting and ticket closure.
• Package evidence: configs, coverage matrix, runbook, sample alerts/tickets.
• If you use AWS Security Hub for CIS mapping, align findings and document any compensating controls or accepted risks. (AWS Security Hub CIS AWS Foundations mapping table)

Frequently Asked Questions

Does this requirement mean we must enforce MFA on all console users?

No. CIS AWS Foundations v1.2 3.2 requires detection and alerting for console sign-ins without MFA. You should still enforce MFA as a preventative control, but this specific requirement focuses on the metric filter and alarm. (CIS AWS Foundations Benchmark)

Can we meet this with a SIEM instead of CloudWatch alarms?

The requirement wording is specific to having a log metric filter and alarm, which aligns to CloudWatch Logs metric filters and CloudWatch alarms. If you detect in a SIEM, keep CloudWatch-based controls or document a clearly equivalent implementation and be prepared for pushback in a strict CIS audit.

What identities does “Management Console sign-in” cover?

It covers AWS console authentication events recorded by CloudTrail (commonly ConsoleLogin). Validate in your CloudTrail logs which principals generate these events in your environment before finalizing the filter.

We have break-glass accounts that sometimes log in without MFA. Is that automatically noncompliant?

Not automatically, but it creates noise and audit questions. Keep an exceptions register, restrict who can use break-glass access, and require post-use review tied to the alarm event.

How do we prove to an auditor that the alarm works?

Keep a test record showing the metric increments and the alarm notifies the intended channel, plus an associated ticket or incident record showing triage. Screenshots alone rarely satisfy “operating effectiveness.”

Do we need this in every AWS region?

CloudTrail and CloudWatch resources are region-scoped in implementation details, but your objective is account-wide detection of console logins without MFA. Document how your logging architecture achieves coverage and show where the metric filter and alarm run.

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