An IAM user with a console password and no MFA device can be signed in to with nothing more than a guessed, reused or phished password. AWS enforces MFA for the root user of every account type, but each IAM user has its own MFA configuration, so this check stays with the account owner. This runbook shows how to find those users with the IAM credential report, AWS Config and AWS Security Hub, how to fix each one (add MFA, remove the password, or move the person to federated access), and how to stop new ones appearing. It is for cloud security and platform engineers working in a single account or across an AWS Organization. Root user checks and access keys have their own pages: see the Cloud Provider Mandatory MFA and the AWS Access Keys Security Guide.
This is an independent guide from NHI Mgmt Group, based on AWS's public documentation as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.
Key takeaways
- The credential report answers the question directly. Filter rows where
password_enabledis true andmfa_activeis false; that is the list. - Use the managed checks for scale. The AWS Config rule
mfa-enabled-for-iam-console-accessand Security Hub control IAM.5 report the same condition continuously, across accounts if you aggregate them. - Decide per user, not in bulk. A person who needs the console gets MFA (passkey or security key first); a user that never signs in loses its password; most humans should move to IAM Identity Center.
- Deleting a password does not touch access keys or live sessions. Revoke active console sessions separately and review the user's keys in the same change.
- Guardrails stop the list growing back. A deny-unless-MFA policy, alerts on
CreateLoginProfileand a standing IAM.5 check keep the count at zero.
When you need this
Run this check when you inherit accounts, before an audit, after a phishing or password spraying campaign against your staff, and as a standing monthly control. It matters most in accounts that still hold long-lived IAM users for people: contractors, break-glass users created before IAM Identity Center, shared "admin" users and users created for a third party to look at a console. AWS documentation recommends that human users use temporary credentials and asks whether you have considered IAM Identity Center, so every user this runbook finds is also a candidate for removal rather than repair.
The attack path is plain. A console password with no second factor is exposed to password spraying (ATT&CK T1110.003) and, once valid, gives the attacker a cloud account (T1078.004) with whatever the user's policies allow. See the Password Spraying and Credential Stuffing Defence Guide for the wider defence.
Before you start
- Permissions:
iam:GenerateCredentialReportandiam:GetCredentialReportto read the report;iam:ListMFADevices,iam:GetLoginProfileandiam:GetUserto confirm single users;iam:DeleteLoginProfileonly for the people allowed to make the fix. - Report timing: IAM generates a new credential report at most once every four hours. If one was produced in the last four hours you get that one, so a fix made a minute ago will not show until the next report.
- Owners: have a way to reach the person or team behind each user before you remove anything. An exceptions register with an owner and an expiry date (our recommendation) saves arguments later.
- Change window: removing a password is reversible (you can create a new one), but agree the window with the owners of any user that signs in regularly.
Step-by-step
1. Pull the credential report
- Generate the report:
aws iam generate-credential-report. - Download and decode it:
aws iam get-credential-report --query Content --output text | base64 --decode > credential-report.csv. - Repeat per account, or run it from a script that assumes a read-only audit role in each member account.
2. Filter for console users without MFA
The columns you need are below. The report is a CSV with a header row, so filter by column name rather than position where your tooling allows.
| Column | Values | What it tells you |
|---|---|---|
password_enabled | TRUE or FALSE | The user has a console password (a login profile). |
mfa_active | TRUE or FALSE | At least one MFA device is enabled for the user. |
password_last_used | Date and time, no_information or N/A | Last console sign-in with the password. no_information means never used or no data; N/A means no password. |
password_last_changed | Date and time or N/A | When the password was last set; a very old value hints at a forgotten user. |
user_creation_time | Date and time | Helps separate new starters still enrolling from long-standing gaps. |
access_key_1_active, access_key_2_active | TRUE or FALSE | Whether the same user also has programmatic access to deal with. |
A one-line filter that works in most shells, matching on the header names and ignoring case:
python3 -c "import csv,sys; r=csv.DictReader(open(sys.argv[1])); [print(x['user'], x['password_last_used'], x['access_key_1_active'], x['access_key_2_active']) for x in r if x['password_enabled'].lower()=='true' and x['mfa_active'].lower()=='false']" credential-report.csvThe report also includes a row for the account root user (commonly shown as <root_account>; check your own report); handle it through the root user process, not this one.
3. Confirm each user before you act
aws iam get-login-profile --user-name <user>confirms a password still exists (it returnsNoSuchEntityif not).aws iam list-mfa-devices --user-name <user>confirms no device is enabled.aws iam get-user --user-name <user>showsPasswordLastUsed, which is fresher than the report.- List the user's groups and attached policies so the owner knows what the user can do today.
4. Turn on continuous detection
For more than a handful of accounts, use the managed checks rather than scripts.
| Source | Name | What it evaluates | Notes |
|---|---|---|---|
| AWS Config managed rule | mfa-enabled-for-iam-console-access (identifier MFA_ENABLED_FOR_IAM_CONSOLE_ACCESS) | Each AWS::IAM::User with a console password has MFA enabled | Periodic trigger, no parameters. Check the rule page for the Regions where it is available. |
| AWS Security Hub control | IAM.5: MFA should be enabled for all IAM users that have a console password | Same condition, backed by the Config rule above | Severity Medium. Mapped by AWS to CIS AWS Foundations Benchmark v5.0.0 1.9 and NIST SP 800-53 IA-2(1), IA-2(2). |
| AWS Security Hub control | IAM.19: MFA should be enabled for all IAM users | Every IAM user, password or not | Stricter; useful once console users are clean, though users with only access keys will also appear. |
In an AWS Organization, aggregate Config results or use a Security Hub delegated administrator account so IAM.5 findings from every member account land in one place.
5. Fix each user
Pick one action per user with its owner. The table is our recommended decision order.
| Situation | Action | How |
|---|---|---|
| Person needs the console and you run IAM Identity Center or another federated identity provider | Move them to federated access, then remove the IAM user's password | See the AWS IAM Identity Center Guide. |
| Person needs the console and must keep an IAM user for now | Register MFA, preferring a passkey or security key | User registers a device on the Security credentials page; up to eight devices per user. |
password_last_used is no_information or older than your threshold (for example 90 days, our suggestion) | Remove the console password | Console: Security credentials, Manage console access, Disable access. CLI: aws iam delete-login-profile --user-name <user>. |
| User is really a workload that only uses access keys but was given a password | Remove the password; plan to replace the keys with a role | See How to find unused AWS IAM roles and access keys. |
| Shared user used by several people | Replace with named federated access, then remove the password | Shared users cannot tie MFA or actions to one person. |
AWS recommends phishing-resistant MFA (passkeys and security keys) wherever possible and describes virtual authenticator apps as an interim option. See the Phishing-Resistant MFA Guide.
6. End live sessions where risk is high
Removing the password stops new password sign-ins; to end console sessions already open, select Revoke active console sessions in the Manage console access dialog, which applies an inline deny policy keyed on aws:TokenIssueTime. Do this when you suspect the password was exposed, and check CloudTrail for the user's recent activity at the same time.
Verify it worked
- Wait for the four-hour window, generate a new credential report and re-run the filter: the fixed users should show
mfa_activeTRUE orpassword_enabledFALSE. - Re-evaluate the Config rule (or wait for the periodic run) and confirm Security Hub IAM.5 findings move to passed or resolved.
- For users who enrolled MFA, confirm the next console sign-in event in CloudTrail (
ConsoleLogin) shows"MFAUsed": "Yes"in itsadditionalEventData. - Confirm with each owner that nothing they rely on broke.
Rollback and common errors
- Someone still needs the console: recreate the password with
aws iam create-login-profile --user-name <user> --password-reset-required(supply a temporary password through your approved channel) and enrol MFA in the same session. - Revoke left an inline policy behind: the session revocation policy stays on the user; review it with
aws iam list-user-policiesand remove it once it is no longer needed, or keep it as a record. NoSuchEntityon delete-login-profile: the user had no password; the report you used was stale.- User cannot enrol MFA: an IAM user needs permission to manage their own MFA device. The AWS example policy for self-managed MFA grants it.
- Deleting the IAM user instead: the CLI requires the login profile to be removed first; use the order in the unused access runbook linked above.
Hardening afterwards
Require MFA in policy
AWS publishes an example identity-based policy that lets users manage their own MFA device and denies everything else when MFA is absent. Its DenyAllExceptListedIfNoMFA statement uses NotAction with the condition "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}. Because of IfExists, requests signed with long-term access keys are also denied for anything outside the MFA setup list, so CLI users must call sts:GetSessionToken with their MFA code first. Attach it to a group that holds your remaining human IAM users, test with one user, then widen.
Alert on new passwords
Watch CloudTrail for CreateLoginProfile, UpdateLoginProfile and DeactivateMFADevice. A new password on a user that previously had none, or MFA removed from an active user, should go to the security team the same day. AWS Organizations service control policies can also deny iam:CreateLoginProfile outside an approved administration role (our recommendation for accounts that use IAM Identity Center for all people).
Measure
| Metric | Source | Target (our suggestion) |
|---|---|---|
| IAM users with a password and no MFA | Credential report or IAM.5 failed findings | Zero, with named exceptions only |
| IAM users with a console password at all | Credential report password_enabled | Falling each quarter as people move to federation |
| Days from IAM.5 finding to fix | Security Hub finding timestamps | Under 7 days |
| Console users on phishing-resistant MFA | list-mfa-devices device types | Rising towards all |
| Accounts where the Config rule is deployed | Config aggregator | Every account and supported Region |
Framework mapping
| Framework | Reference | Link to this runbook |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2(1), IA-2(2), AC-2 | MFA for privileged and non-privileged accounts; account management for unused passwords |
| NIST CSF 2.0 | PR.AA-03 | Users, services and hardware are authenticated |
| CIS AWS Foundations Benchmark | v5.0.0 1.9 (as mapped by AWS to IAM.5) | MFA for every IAM user with a console password |
| MITRE ATT&CK | T1078.004, T1110.003 | Valid cloud accounts reached by password spraying |
Practitioner checklist
- Credential report pulled from every account, filtered on
password_enabledandmfa_active. - Each finding confirmed with
get-login-profileandlist-mfa-devices, and an owner named. - Unused passwords removed; active console users enrolled in phishing-resistant MFA or moved to IAM Identity Center.
- Active console sessions revoked where the password may have been exposed.
- Access keys on the same users reviewed in the same change.
- Config rule
mfa-enabled-for-iam-console-accessdeployed and IAM.5 enabled, aggregated across the Organization. - Deny-unless-MFA policy attached to remaining human IAM users.
- CloudTrail alerts on
CreateLoginProfile,UpdateLoginProfileandDeactivateMFADevice. - Exceptions register with owner and expiry date reviewed monthly.
Standards and references
- AWS: Generate credential reports for your AWS account
- AWS: AWS Multi-factor authentication in IAM
- AWS Config: mfa-enabled-for-iam-console-access
- AWS Security Hub: Security Hub controls for IAM
- AWS: Manage passwords for IAM users
- AWS: Allows MFA-authenticated IAM users to manage their own MFA device
- MITRE ATT&CK: T1078.004 Cloud Accounts
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: AWS IAM Identity Center Guide, AWS Access Keys Security Guide, How to find unused AWS IAM roles and access keys, Cloud Provider Mandatory MFA, Top 10 MFA Mistakes.