4 Multi-Factor Authentication
Learn how MFA adds independent proof to sign-in, how to choose and configure an authenticator, and how to protect authentication and recovery without confusing sign-in security with access permissions.
What MFA protects
requires proof from at least two different : something you know, something you have, or something you are. A password is something you know; a security key or phone is something you have; and a fingerprint is something you are.
Combining a password with a one-time code from an authenticator app uses two categories. Combining a password with another password does not. MFA makes a stolen password less useful, but it does not replace secure passwords or determine which resources a user may access. continue to govern permissions.
Choose an authenticator
For AWS sign-in, prefer a when available. These use public-key cryptography and are phishing-resistant: they help prevent an attacker’s fake sign-in page from reusing your authentication.
A virtual authenticator app or hardware token can generate a . These are useful alternatives, but a code can still be tricked from a user and relayed to an attacker. AWS no longer supports enabling SMS-based MFA.
Configure MFA for an IAM user
An administrator, or an IAM user who has the required permissions, can register an authenticator in the AWS Management Console:
Sign in to the AWS Management Console and open IAM.
To configure your own user, choose your user name and then Security credentials. To configure another IAM user, choose Users, select the user, and then Security credentials.
Under , choose Assign MFA device.
Name the device, select the authenticator type, and follow the on-screen setup. For an authenticator app, scan the displayed QR code and enter the requested consecutive codes to verify setup. For a passkey or security key, follow the browser’s prompts and complete the action requested by the device.
Sign out and sign back in to confirm that the MFA challenge works.
Keep the authenticator’s setup secret private. Where practical, register more than one MFA device so that losing or being unable to use one device does not unnecessarily block access.
Root-user MFA is configured separately and protects only the root user; it does not enable MFA for IAM users. IAM Identity Center is another workforce sign-in path and has its own MFA configuration.
Sign in and recover securely
At sign-in, enter your username and password on the genuine service sign-in page, then complete the MFA challenge with your registered device. Check the sign-in address before entering credentials, use a unique password, and keep recovery contact details current.
Treat unexpected MFA prompts as a warning. Deny prompts you did not initiate, and never tell anyone a one-time code or approve a request on someone else’s behalf.
If a device is lost or compromised, promptly use the service’s recovery process and ask an administrator to remove or replace the registered device. Keep an alternate authenticator secured separately rather than storing all recovery options with the primary device.
Authentication is not authorization
If an attacker learns an IAM user’s password, MFA can stop the attacker from completing an interactive sign-in without also controlling an enrolled authenticator. However, MFA does not make an over-permissioned user safe: the user’s policies still define what that identity can do after authentication.
MFA therefore adds independent proof of identity at sign-in, while continue to control authorization.