Console-enabled IAM users signing in with only a password
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-083 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Source | iam_mfa.go |
Where it applies
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:
aws iam generate-credential-report >/dev/null && sleep 5aws 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.