Multi-Factor Authentication (MFA)

Multi-Factor Authentication (MFA) adds a second layer of protection beyond a password. In AWS, MFA requires presenting a one-time code from a registered device (virtual authenticator app, hardware token, or FIDO2 security key) in addition to the password when signing in to the console or performing sensitive API operations.

MFA Types in AWS

• Virtual MFA: TOTP apps like Google Authenticator, Authy (free, most common)
• Hardware TOTP token: physical key fob (e.g., Thales)
• FIDO2 security key: YubiKey, Titan (phishing-resistant, strongest)
• Passkeys: FIDO2-based passwordless authentication (supported since 2024), including synced passkeys from credential managers such as Apple, Google, Microsoft, or 1Password

AWS ended support for enabling SMS text message-based MFA. If you still have users on SMS MFA, migrate them to a passkey, security key, virtual authenticator, or hardware token. Note that AWS now enforces MFA for the root user of all account types, and both root users and IAM users can register up to eight MFA devices each, which gives you a backup if a device is lost.

Where to Require MFA

• Root account (mandatory per CIS benchmark, and now enforced by AWS for root users)
• All IAM users with console access
• Sensitive API operations via IAM policy conditions (aws:MultiFactorAuthPresent)
• Cross-account role assumption

How It Goes Wrong in Practice

The most common gap is enforcing MFA for the console while leaving programmatic access wide open. A user signs in to the console with a TOTP code, but the same user also holds long-term access keys, and API calls made with those keys never involve MFA at all. If the keys leak through a Git commit or a laptop compromise, the MFA policy did nothing. The fix is to remove long-term keys where possible and, where you keep IAM users, write policies that deny sensitive actions unless aws:MultiFactorAuthPresent is true. Be careful with the condition logic: using BoolIfExists versus Bool changes how requests with no MFA context (like those signed with long-term keys) are evaluated, and getting it wrong either locks out legitimate service traffic or silently exempts exactly the requests you wanted to block.

The second recurring pattern is TOTP phishing. Virtual MFA codes can be phished in real time: the attacker presents a fake sign-in page, the victim types both password and current code, and the attacker replays them within the validity window. This is why AWS recommends phishing-resistant FIDO-based methods (security keys and passkeys) over TOTP: FIDO authentication is bound to the origin, so a code cannot be relayed from a look-alike domain. Finally, watch for attackers registering their own MFA device on an account they have compromised, which turns your security control into their persistence mechanism. Alert on MFA device enrollment events in CloudTrail.

Auditing MFA From the CLI

To list virtual MFA devices in the account and see which are assigned:

aws iam list-virtual-mfa-devices --assignment-status Any

The --assignment-status parameter accepts Assigned, Unassigned, or Any (the default). The output lists each device's SerialNumber ARN and, for assigned devices, the attached user. Two useful audits: run with Unassigned to find orphaned devices, and cross-check the IAM credential report (aws iam generate-credential-report then aws iam get-credential-report) for console users whose mfa_active column is false. Unassigned virtual MFA devices are deleted automatically when new virtual devices are added, but they are still worth reviewing during an incident.

Frequently Asked Questions

How many MFA devices can one user register?

Up to eight devices per root user or IAM user, in any combination of supported types. You only need one of them to sign in. Registering at least two (for example a security key plus a passkey) protects you from losing access when a single device breaks or disappears.

Does MFA protect my access keys?

Not by itself. Long-term access keys authenticate without any MFA step. You can force MFA for API calls by writing IAM policies that require aws:MultiFactorAuthPresent, which pushes users to call sts:GetSessionToken with an MFA code and use the resulting temporary credentials. The cleaner solution is to eliminate long-term keys and use IAM Identity Center or federated roles, where MFA happens at the identity provider.

Which MFA type should I choose?

Phishing-resistant FIDO methods first: a hardware security key or a passkey. AWS explicitly recommends them over TOTP because they resist phishing, man-in-the-middle, and replay attacks. Use a virtual TOTP app only as an interim measure, and avoid relying on a single device for the root user.

Can I enable a security key from the CLI?

No. Passkeys and FIDO security keys can only be enabled from the AWS Management Console, not through the CLI or API. Virtual and hardware TOTP devices can be enabled programmatically with aws iam enable-mfa-device.