How to Enable MFA on AWS (Amazon Web Services)

Your AWS account controls cloud infrastructure that could cost thousands of dollars if compromised. A misconfigured or stolen AWS root account can result in massive unauthorised charges, data breaches, and complete loss of cloud resources. Enabling MFA on your AWS root account and IAM users is one of the highest-impact security steps you can take for any cloud workload.

AWS Root Account vs IAM Users — Enable MFA on Both

AWS has two types of accounts that need MFA protection. The root account is the email address used to create the AWS account — it has unrestricted access to everything including billing and account closure. It should be used rarely but must be protected with MFA. IAM users are the accounts used for day-to-day access. Every IAM user with console access should have MFA enabled individually.

Step 1: Enable MFA on Your AWS Root Account

1. Sign in to the AWS Management Console at console.aws.amazon.com using your root account email and password.
2. Click your account name in the top right, then select Security credentials.
3. Under "Multi-factor authentication (MFA)", click Assign MFA device.
4. Give the device a name (e.g. "my-authenticator"), select Authenticator app, and click Next.
5. Click Show QR code and scan it with your authenticator app (Google Authenticator, Authy, 1Password, etc.).
6. Enter two consecutive 6-digit codes from your app (MFA code 1 and MFA code 2) and click Add MFA.
7. MFA is now active on your root account.

Step 2: Enable MFA for IAM Users

To enable MFA for an IAM user (including your own user):

1. Go to the IAM console at console.aws.amazon.com/iam.
2. Click Users in the left sidebar and select the user.
3. Go to the Security credentials tab.
4. Under "Multi-factor authentication (MFA)", click Assign MFA device.
5. Follow the same steps as the root account — name the device, select authenticator app, scan the QR code, enter two consecutive codes.

Enforce MFA for All IAM Users with a Policy

You can require MFA for all IAM actions by attaching a policy that denies everything unless MFA is present. This is AWS best practice for any account with multiple users. Create an IAM policy with the condition "Bool": {"aws:MultiFactorAuthPresent": "false"} and attach it to your users or groups. Users without MFA will be blocked from all actions except the minimal steps needed to enrol their MFA device.

FIDO2 Security Keys for AWS

AWS supports FIDO2/WebAuthn hardware security keys (such as YubiKey) as an MFA option. For root accounts and highly privileged IAM users, a hardware key provides the strongest available protection and is phishing-resistant. Register a FIDO2 key the same way as a virtual MFA device — select "Security key" instead of "Authenticator app" during enrolment. AWS recommends registering two hardware keys and storing one as a backup in a physically secure location.

What to Do If You Lose AWS MFA Access

For IAM users, an AWS administrator can deactivate your MFA device from the IAM console and assign a new one. If the administrator themselves is locked out, or if it is the root account, you must contact AWS Support. For root account recovery, AWS requires identity verification including the phone number on the account, payment method information, and in some cases additional verification steps. This process can take hours to days, which is why having a backup MFA device registered is critical for root accounts.

AWS MFA Best Practices Summary

Enable MFA on the root account immediately and use it only for tasks that genuinely require root access (closing the account, changing billing details, recovering from IAM lockout). For day-to-day work, use IAM users or IAM Identity Center with MFA enforced. Store your authenticator backup codes and root account recovery information in a secure offline location. Consider registering a second MFA device as a backup. Audit your IAM users regularly for MFA compliance using AWS Security Hub or IAM credential reports.

Using AWS MFA from the Command Line

MFA also applies when you use the AWS Command Line Interface (CLI) or SDKs, but it is not requested automatically. To use MFA with CLI credentials, run aws sts get-session-token with the --serial-number flag set to your MFA device ARN and --token-code set to the current 6-digit code from your app. The temporary credentials last up to 12 hours. A more robust pattern is to create an IAM role whose trust policy requires the aws:MultiFactorAuthPresent condition, then use aws sts assume-role with --serial-number and --token-code. Because the role denies every API call made without MFA, this protects automation and anyone holding long-lived access keys. Accounts using IAM Identity Center can instead enforce MFA at the permission set level, and the CLI can refresh MFA-required sessions automatically.

Troubleshooting AWS MFA Problems

If your 6-digit code is rejected, the most common cause is a clock mismatch on your phone. TOTP codes are derived from the current Unix time, so a device clock that drifts even a few seconds generates codes AWS will not accept. On iPhone, enable Set Automatically under Settings → General → Date & Time; on Android, enable automatic time under Settings → System → Date & Time. Google Authenticator also offers a time correction option in its settings menu. If you lose your phone, an IAM administrator can deactivate the virtual MFA device from the IAM console by selecting the user, opening Security credentials, and choosing Deactivate. A root account locked out of its MFA device must use AWS account recovery, which requires proof of identity such as the account's phone number, the card on file, and email access. Registering a second device or a hardware key makes that recovery dramatically faster.

AWS MFA Device Types Compared

• Virtual MFA (authenticator app) — free, works offline, and the easiest to add for personal accounts; the tradeoff is that the software token lives on a phone you could lose
• Hardware key (U2F or FIDO) — a physical device such as a YubiKey that you touch to approve; phishing-resistant and unaffected by phone loss, at the cost of $25–$60 and one more thing to carry
• SMS — still offered for IAM users, but AWS itself recommends against it for security-sensitive accounts because text codes can be intercepted or SIM-swapped
• Software on your desktop — IAM also supports the Windows and macOS authenticator tools, which is convenient for workstations but ties MFA to a single machine

Most people should start with a virtual MFA app, register a second device or export the setup key safely, and upgrade to a hardware key if the account controls production infrastructure. If a second factor for the root account is what you need, AWS requires hardware or virtual MFA for the root user — SMS is not an option there.

Enrolling MFA for a New Team Member

Adding MFA to an existing IAM user takes about two minutes. In the console, open IAM → Users, click the user, open the Security credentials tab, and choose Assign MFA device. Pick "Authenticator app", show the user the QR code, and have them enter the code from their own phone — the person should scan the QR with their own device, never through a screenshot shared in chat, so the secret is not copied into any messaging history.

Then test the assignment before the user walks away: have them sign out and sign back in using the new MFA code. AWS marks the device as active only after the first successful use, so a test login also confirms the status shown in the console. If a teammate loses their phone later, an administrator can remove the old device from the same tab and let them re-enroll — a five-minute fix, provided someone with administrator permissions acts quickly.

IAM Identity Center vs Classic IAM Users

AWS now pushes most new organisations toward IAM Identity Center, which manages access to the AWS console and applications through a single portal with your identity provider (Okta, Google Workspace, Microsoft Entra ID, or AWS's own directory). The key difference for MFA: Identity Center users have MFA policies applied centrally — you can require MFA for every login, for specific permission sets, or only when users sign in from unfamiliar networks — and the enforcement lives with the provider rather than per user.

Classic IAM users, by contrast, each carry their own MFA device, and the root account remains separate regardless of which model you use. If you are starting fresh, Identity Center is the recommended path because MFA is enforced uniformly; if you are on classic IAM users, the same protection is achieved by assigning MFA devices to every user and reviewing the list under the Security credentials tab.

What a Compromised AWS Account Actually Costs

MFA fatigue aside, the realistic alternative to 2FA is expensive. A stolen access key can be used to launch hundreds of GPU instances, run mining workloads or brute-force scripts, and rack up a bill in a single weekend. Publicised incidents routinely reach five-figure invoices, and because the root user is billed for every service used, the first signal is often the cloud bill itself — by which point the damage is done.

That is the case for taking MFA seriously rather than treating it as a checkbox: the root account's MFA protects the billing and account-management powers, while MFA on IAM users protects the compute and data resources. Both are cheap to set up, and both are the difference between an attacker hitting a wall and an attacker hitting your credit card.