# IAM User Without MFA Enabled

> Only IAM users with console access and mfa_enabled=false are flagged. Programmatic-only identities never appear, because access keys cannot use MFA at sign-in. Both facts come from discovery metadata, and either one missing means no finding, so every flagged user represents 1 confirmed password-only console login path.

Source: https://zop.dev/integrations/aws/recommendations/iam-user-without-mfa-enabled
Updated: 2026-08-19

---

## What a password-only console user actually exposes

A phished or reused password on a console-enabled IAM user hands over everything that user's
policies allow, interactively, with a browser. No stolen laptop, no network foothold required:
credential-stuffing lists and lookalike sign-in pages are commodity attacks. A second factor
turns that from a working credential into a dead end, which is why MFA on human users is in
the first page of every compliance framework's IAM section.

## Why programmatic users are exempt

The rule requires two confirmed facts from discovery: the user has console access, and no MFA
device is registered. A service account that only holds access keys never signs in through the
console, so console MFA is meaningless for it, and flagging those users would generate findings
nobody can act on. (Key hygiene for programmatic identities is a different problem with its
own rule.) When either fact is missing from the discovered state, the rule abstains: a user is
never accused of a gap that was not positively observed.

## List the exposed users yourself

The credential report is the fastest account-wide view. Column 4 is `password_enabled`,
column 8 is `mfa_active`:

```bash
aws iam generate-credential-report >/dev/null && sleep 5
aws iam get-credential-report --query Content --output text | base64 -d \
  | awk -F, '$4=="true" && $8=="false" {print $1}'
```

## Remediation is per-user; enforcement is policy

Registering a device fixes one user. The durable fix is an IAM policy (or Organizations SCP)
that denies everything except MFA self-enrolment when `aws:MultiFactorAuthPresent` is false.
After that, a new user without MFA can do nothing until they enrol, and the finding class
stops regenerating with every hire. FIDO2 security keys or authenticator apps both satisfy
the condition; hardware keys additionally shut down phishing of the second factor itself.

## The larger question a fired finding raises

Every console IAM user found here is also a prompt to ask why the human is on a long-lived
IAM identity at all. Identity Center (SSO) users authenticate through your IdP with its own
MFA and session policies, and shrinking the IAM-user population shrinks this entire finding
class at the source. Zero human IAM users is an achievable end state; MFA on the remainder is
the interim bar.