AWS Account Security

How I Set Up MFA on an AWS IAM User (Step by Step)

A walkthrough of adding an authenticator app to an IAM account, and why I don't let root or IAM users go without it

Multi-factor authentication turns a single leaked password into a non-event. Here's exactly how I enabled it on an AWS IAM user with an authenticator app, from the IAM dashboard to a successful login test.

Why I don't skip MFA on AWS accounts

Every time I open the IAM dashboard for a new account, MFA is one of the first things I check. It's easy to treat as an afterthought when you're just trying to get a demo user working or spin up some test infrastructure, but the root account in particular is worth pausing on. Root has no guardrails — no permission boundaries, no service control policies that can fully restrict it. If someone gets the root password, they have the account. A rotating six-digit code sitting in an authenticator app is a small amount of friction that turns a leaked password into a non-event instead of a breach.

I treat individual IAM users the same way, even though they're less catastrophic than root by design. If you're studying for an AWS certification, this is also one of those topics that keeps showing up in exam material across different tracks — IAM security fundamentals are foundational enough that most cloud certifications expect you to know how MFA registration works, not just why it matters. I'd still recommend checking the current exam guide for whatever certification you're prepping for, since objectives shift between versions and I don't want to promise this maps to a specific exam you're sitting for.

So before touching anything else, I go back to the IAM dashboard, click into Users, and pick the account I want to secure.

Finding the MFA settings for a user

Once I'm on a specific user's page, the MFA controls live under the Security Credentials tab. This is the same tab where you'd manage access keys, so it's worth getting familiar with — it's the central place for anything related to how a user authenticates.

Scrolling down, there's a dedicated multi-factor authentication section with an option to assign a new MFA device. This is where the actual setup begins, and it's a short flow: name the device, pick a type, and register it. Nothing here requires elevated permissions beyond what you'd normally have to manage your own account or the users you administer.

Choosing the right MFA device type

AWS gives you three options when you assign a device: a passkey, an authenticator app, or a hardware security key. I gave mine a descriptive name — something like "iPhone demo" — mostly so that if I ever have multiple devices registered, I can tell them apart later without guessing.

Of the three, the authenticator app is the one I reach for by default, and it's the one most people end up using in practice. Passkeys are great if your device and browser support them well, and hardware keys are the gold standard for high-security environments, but an authenticator app hits the sweet spot of being free, portable, and compatible with almost anything. It also doesn't require buying extra hardware, which matters if you're setting this up across a team or a training environment.

Once I selected the authenticator app option, AWS moved straight into generating the actual registration credential.

Scanning the QR code to register the app

AWS produces a QR code on screen at this point, and the standard move is to scan it with whatever authenticator app you're using — Google Authenticator, Authy, 1Password, or in my case, the password manager that's already built into my iPhone. Most modern iPhones can scan a QR code straight from the camera without needing a separate scanner app, and recent versions of iOS also let you save the resulting verification code directly inside the built-in password manager alongside a saved login. That's worth double-checking against your own iOS version and settings, since the exact behavior has shifted across updates and isn't guaranteed to be identical on every device.

One thing worth being deliberate about here: that QR code encodes the actual shared secret that generates your rotating codes. Anyone who captures a clear image of it can generate valid MFA codes for that account, which defeats the purpose of setting this up in the first place. If you're ever recording your screen, presenting to a group, or screen-sharing during this step, treat that QR code the same way you'd treat a password in plaintext — don't leave it visible any longer than it takes to scan it, and don't screenshot or save the image anywhere persistent.

After scanning, I saved the entry under a clearly labeled name so I could find it again quickly, then AWS asked for two consecutive codes from the app to confirm the device was registered correctly. Entering two codes instead of one is a small detail, but it makes sense — it proves the app is actually generating valid, time-synced codes rather than the registration having succeeded by coincidence.

Confirming it actually works

Setup steps only mean something once you've verified them, so I logged out of the account and went back to the sign-in screen to test the whole flow end to end. After entering the username and password, AWS prompted for the MFA code before letting the login through — exactly what you'd want to see.

I opened the password manager, grabbed the current rotating code, and typed it in. The login went through cleanly, which confirmed the device was properly linked to the account and that the codes were syncing correctly. That last step matters more than it might seem: it's the difference between assuming MFA is configured and actually knowing it is. I'd rather find out immediately if something's misconfigured than discover it later when I'm locked out or, worse, when it turns out MFA silently wasn't enforced at all.

A couple of habits worth carrying forward

A few things I keep in mind after going through this a handful of times. First, do this for root immediately if you haven't — it's the single highest-leverage MFA setup you can do on an AWS account, since root access sidesteps most other controls. Second, apply the same standard to IAM users, especially anyone with console access to production resources. It costs a few minutes per person and meaningfully raises the bar for account takeover.

Second, be mindful of what's on screen during setup. Beyond the QR code itself, password managers will sometimes auto-fill or auto-generate a password into a saved entry as part of this flow. If that's a real account rather than a disposable demo, it's worth double-checking that nothing sensitive stayed visible longer than it needed to, especially if you're recording, sharing your screen, or working somewhere others can see your monitor.

Finally, if you're doing this as part of certification prep, don't just memorize the click path — actually register a device on a test account and go through the failure modes. Try logging in without the code, try entering a stale one, and see how AWS responds. That kind of hands-on repetition sticks a lot better than reading through the console flow alone, and it'll serve you well whether or not this exact topic ends up on whatever exam you're studying for.

Conclusion

If you've got IAM users or a root account without MFA turned on, that's the next five minutes well spent — head into Security Credentials, assign a device, and run through the QR code registration while being mindful of who might see that code on your screen.

Official AWS references

KEEP PRACTICING THE DECISION

Learn the concept, then test the edge case.

The Solutions Architect Associate course in TutorialRepo combines guided lessons, scenario questions, review, and course-aware explanations.

  All articles