Require multi-factor authentication (MFA) for IAM users with console access to strengthen account security and reduce the risk of compromised credentials. The plan walks through identifying which IAM users actually sign in to the AWS Management Console, understanding their current MFA status, deciding who must use MFA and what types of devices they can use, guiding enrollment for both virtual and hardware MFA devices, and finally validating and testing that MFA is correctly enforced for all in-scope users.
By the end, every IAM user with console access will either have MFA enabled, be explicitly documented as an approved exception (for example, a break-glass account), or be marked out of scope (such as accounts scheduled for removal). The plan also supports clear documentation of decisions, timelines, and inventories so you can maintain and audit MFA coverage over time.
In the Assessment phase, you build a complete, structured picture of who can access the console and how MFA should apply to them.
Identify IAM users with console access
Enumerate all IAM users in each in-scope AWS account and determine which have console login profiles (passwords) configured. Capture key attributes for these users—such as name, ARN, creation time, password status, and tags (Environment, Application, Owner, CostCenter). Service or automation users that have login profiles but are not intended for console use are flagged so you can decide whether MFA is needed or if the login profile should be removed. The result is a structured inventory of IAM users with console access.
Determine current MFA status for console users
For each IAM user with console access, list associated MFA devices (virtual and hardware), capturing details like device type, serial/ARN, user association, and enablement status. Users are categorized by MFA state (enabled MFA, disabled MFA, or no devices). Users with multiple devices are flagged for later cleanup decisions. A summarized view shows total console users, how many already have MFA, and how many do not, and this is linked to the original console-user inventory.
Define MFA scope and exceptions
Using the combined console-access and MFA-status inventory, you review which users or groups must be protected by MFA. You categorize users (for example, production admins, non-production admins, regular users, service/automation accounts) and decide which must have MFA, which are approved exceptions (such as break-glass accounts) along with justification and safeguards, and which are out of scope (for example, accounts to be decommissioned). Each IAM user with console access is mapped to one of these categories and the decisions are documented in a structured format.
Set MFA enrollment policy and timelines
You review organizational security requirements and available tools to define acceptable MFA device types (virtual TOTP apps, hardware tokens, security keys, etc.). For each user or user category, you decide whether they must enroll virtual MFA, hardware MFA, or can choose between options. You also define timelines or deadlines for enrollment, identify where multiple devices (such as backup MFA devices) are required, and document any supporting processes (user instructions, help desk involvement, approvals). The output is a clear MFA enrollment plan per user or category, including required device types, allowed alternatives, and timelines.
In the Configuration phase, users are guided through actually enrolling MFA devices for the IAM users in scope.
Enroll IAM users with virtual MFA devices
Based on the enrollment plan, you select the IAM users designated for virtual MFA. You ensure each has access to a compatible authenticator app on a trusted device. For each user, you initiate virtual MFA setup in IAM, present the shared secret (QR code or key) to the user to add to their app, and collect the required consecutive MFA codes to activate the device. Afterward, you verify that the virtual MFA is associated with the correct IAM user and enabled. Any failed enrollments or issues (like incorrect codes or time-sync problems) are recorded along with follow-up actions. A record is maintained listing users with enabled virtual MFA, including device identifiers.
Enroll IAM users with hardware MFA devices
For users designated for hardware MFA, you ensure they have compatible devices (such as OTP tokens or supported security keys), and you record their serial numbers or unique identifiers. You confirm that the device type is supported in the relevant account/Region, then start the enrollment process for each IAM user, associating the correct hardware device. Required actions—entering codes or interacting with the device—are performed to complete activation, and you verify that the device is enabled and linked to the correct user. Any enrollment failures and impacted users/devices are documented, and a structured record of users with enabled hardware MFA (including device types and identifiers) is maintained.
In the Validation phase, you confirm that MFA is correctly configured and behaves as expected for console sign-in.
Confirm MFA configuration for in-scope users
Using the finalized in-scope list and MFA requirements from the Assessment phase, you re-check the current MFA devices associated with each relevant IAM user. For all users required to have MFA, you confirm that at least one MFA device is associated and enabled. For approved exceptions, you verify that their status aligns with the documented exception list. A summary report shows the total number of in-scope console users, how many have enabled MFA, and any remaining gaps where users are still missing MFA despite being in scope. Discrepancies are recorded with suggested remediation steps, such as re-enrollment or further follow-up.
Test console sign-in with and without MFA
You select a representative sample of users with newly enabled MFA (covering both virtual and hardware devices) and perform console sign-in tests. For each, you confirm that the console prompts for MFA and that sign-in succeeds when the correct MFA code or device interaction is provided, with normal console usage functioning afterward. Any unexpected failures are documented with device details and error information for troubleshooting. Optionally, for a non-critical test user, you may attempt sign-in without MFA (if your policies imply this should fail) to confirm behavior matches expectations. Test outcomes are recorded to verify that MFA enrollment is not only configured but also usable and reliable in practice.