How to enforce MFA for every AWS user

Why this matters

Passwords get stolen. Phishing pages collect them. Reused passwords leak. For an AWS account, a stolen password without MFA can be enough to launch resources, read data, or change IAM policies. MFA makes that password useless on its own. Every human who signs in to AWS should use it, not just administrators.

AWS has no single account-wide switch that forces MFA on every IAM user. MFA is a property of each user, and enforcement comes from identity policies that deny actions when MFA is missing. That design is flexible, but you must apply it on purpose. One user left out can still sign in with a password alone.

The job has two parts: enroll every human in MFA, then make AWS refuse requests when MFA is absent. The second part turns a habit into a control. The root user needs its own MFA, and that is a separate task. This guide covers IAM users, federated users, command line access, and roles.

Before you start

List every human identity that can reach AWS. Include IAM users in each account, users in IAM Identity Center, and people who sign in through a SAML identity provider. Add roles that people assume, especially cross-account admin roles. Then list machine identities: IAM roles used by applications and any active long-term access keys.

Decide how people will enroll. Virtual MFA apps work for most staff. Hardware security keys are better for administrators and finance. If you use IAM Identity Center, set the MFA requirement there instead of building IAM policies for each account. If you use an external identity provider, enforce MFA at the provider, because AWS only sees the signed assertion.

Pick a break-glass path before you deny anything. Keep one admin identity with MFA enrolled and a tested recovery process. Store its credentials in a controlled place, not a shared spreadsheet. Confirm you can create IAM policies, attach them to groups, list users, and generate a credential report. Tell users what will change and when.

Check for old access keys and unused users. An IAM user with an active access key can call AWS APIs without the console. Your MFA policy must handle that path, or you must remove the key. Decide which service accounts will move to IAM roles before you start, because roles do not use MFA the same way.

How to do it

The core pattern is a group and a policy. Create a policy that allows a user to enroll an MFA device and change their own password, and denies every other action when MFA is not present. Attach it to a group, then add users to the group. AWS evaluates the deny and blocks the request. This works for console sessions and for API calls made with temporary credentials that carry MFA context.

For command line work, long-term access keys do not carry MFA. The user must call sts:GetSessionToken with an MFA code, then use the temporary credentials from that call. You can wrap that in a shell function or a credential process. Better, move human access to IAM Identity Center and let it issue short-term credentials after an MFA sign-in. For cross-account roles, add a condition to the role trust policy that requires MFA.

Roll out in waves. Start with a pilot group that can tolerate a broken session. Enroll their devices, test sign-in, test the CLI, then expand. Keep a break-glass user out of the deny group until the end. When the policy is live for everyone, remove unused users and keys rather than leaving them for later.

1. Inventory users and access keys. Run aws iam list-users and aws iam list-access-keys in each account, or download the IAM credential report. Mark each identity as human, machine, or unknown. Disable or remove unknown users before enforcement.
2. Create the MFA enforcement policy. Build a customer managed policy that allows the MFA enrollment calls, iam:ChangePassword, and sts:GetSessionToken. Add a deny statement with NotAction for those calls and a condition of BoolIfExists aws:MultiFactorAuthPresent false. Attach it to a group, not to each user.
3. Attach the policy to a pilot group. Create an IAM group named MFARequired and attach the policy. Add two or three users who can test quickly. Have them sign in, register a virtual MFA device or security key, and sign in again. Confirm the console forces enrollment.
4. Expand to all human users. Add users to MFARequired in batches. Watch for lockouts and support questions. Keep one break-glass admin out of the group until every other human user is enrolled and tested. Then enroll that admin and add it last.
5. Require MFA for command line sessions. Tell users to run aws sts get-session-token with their MFA device serial number and current code, then set the returned temporary credentials in a profile. Test that an access key alone cannot call iam:ListUsers or s3:ListBucket. Remove access keys that no longer have a purpose.
6. Add MFA conditions to role trust policies. For roles that people assume, edit the trust policy and add a condition that requires aws:MultiFactorAuthPresent to be true. This blocks a stolen password from assuming an admin role even if the user is in the MFA group. Test the role with and without an MFA session.
7. Set MFA in IAM Identity Center or your IdP. If you use IAM Identity Center, open Settings, Authentication, and set MFA to required. Choose which factors you allow. If you use SAML federation, enforce MFA in the identity provider and confirm the assertion reaches AWS. AWS cannot enforce a factor the provider never checked.
8. Remove long-term keys and unused users. Move workload access to IAM roles. Delete access keys that are unused or belong to people who should use roles. Disable IAM users who have not signed in and have no owner. This shrinks the set of identities that can bypass your MFA policy.

How to check it worked

Generate the IAM credential report and open the mfa_active column. Every human user should show true. Any false entry is either a user you missed or a machine identity that should not be an IAM user. Run the report again after each rollout wave, because the file is a snapshot.

Use AWS Config. The managed rule mfa-enabled-for-iam-console-access flags IAM users who can sign in to the console without MFA. If you use AWS Organizations, deploy the rule across accounts from the management account. For a quick manual check, open the IAM console, choose Users, and look at the MFA column.

Read CloudTrail. A ConsoleLogin event includes additionalEventData.MFAUsed. Filter for MFAUsed set to No and for human users. For API calls, look for sts:GetSessionToken events with MFA codes and for denied calls that cite the MFA condition. A denied call from a user without MFA is a sign the policy is working.

Test the negative case. Create a temporary test user, give it a password, do not enroll MFA, and try to list S3 buckets or open the IAM console. The request should fail. Enroll MFA and try again, then delete the test user. Do the same for a role trust policy and for a command line profile built from a long-term access key.

Mistakes to avoid

The most common failure is turning on the deny before users enroll. People cannot enroll if the policy blocks iam:EnableMFADevice. Test on one group first, and keep the break-glass admin out until the end. Do not attach the deny policy to every user by hand, because you will miss one and have no easy rollback.

Another mistake is covering the console but not the API. An IAM user with an access key can still call AWS services without MFA unless the policy applies to that path and the user gets temporary credentials. The same gap appears with roles. A role trust policy without an MFA condition lets a stolen password assume the role. Federated users are another gap: AWS cannot enforce MFA that your identity provider did not perform.

Do not treat MFA as a substitute for permissions. A user with full administrator access and MFA can still cause damage. Review for over-broad policies and unused permissions while you are in IAM. Avoid shared users too. MFA is tied to a person, so shared credentials defeat the audit trail and make recovery harder.

Document the recovery path. Users lose phones and security keys. Have a verified process to reset MFA that does not involve disabling the policy for everyone. If you want an outside read on identity and access gaps, the Cloud security review from Cloudverg is a fixed price package at $6,500 that runs 2 to 3 weeks and starts within 10 business days. It is one option among others.

Frequently asked questions