Stop Phishing: Make FIDO MFA Standard in AWS IAM for Security Teams

AWS IAM supports three MFA types: passkeys and security keys (FIDO), virtual authenticator apps (TOTP), and hardware TOTP tokens. AWS recommends phishing-resistant FIDO-based authenticators over TOTP whenever possible. Root user MFA can only be configured through the AWS Management Console, and IAM lets you register up to eight MFA devices per principal for redundancy.

TL;DR:

• FIDO-based passkeys and security keys are the most phishing-resistant MFA options, while virtual authenticator apps are easier to deploy but prone to clock drift issues.
• AWS recommends enabling MFA immediately on the root account via the console and registering multiple backup devices to prevent lockouts.
• MFA enforcement for IAM users should be implemented through policies, with up to eight devices per user, and organizations should centralize identity management to reduce operational overhead.
• Clock drift often causes TOTP codes to fail, so syncing devices regularly and registering backup MFA devices are essential for reliable access.
• Passkeys and security keys should become the default MFA method rather than an upgrade, with virtual apps as a fallback when hardware isn’t practical.

What MFA Means Inside AWS IAM’s Identity Model

MFA adds a second proof of identity on top of a password or access key, and it fits directly into IAM’s least-privilege philosophy: even a leaked credential is useless without the second factor. AWS’s identity model has three layers where MFA matters differently. The root user, tied to the account’s billing and full control, needs MFA the moment the account exists. IAM users, the individual accounts your team logs in with, need MFA enforced through policy. Federated identities, managed through IAM Identity Center or an external identity provider, typically inherit MFA from that provider rather than configuring it inside IAM directly.

The payoff is concrete. MFA blocks the overwhelming majority of account takeovers that start with a stolen or guessed password, and it adds a layer that survives credential-stuffing attacks entirely. It also pairs naturally with temporary credentials and session tokens, since a compromised short-lived token is far less useful to an attacker who still can’t pass the second factor.

MFA Types Supported by AWS IAM: Passkeys, Virtual Apps, and Hardware Tokens

Each method AWS supports for MFA in IAM trades off security strength against deployment friction. AWS does not charge extra for any of them, so cost isn’t the deciding factor. Notably, AWS has retired SMS-based MFA in IAM, and the current guidance pushes everyone still using it toward passkeys, virtual apps, or hardware tokens.

Passkeys and security keys (FIDO). These rely on public key cryptography rather than a shared secret, which is what makes them phishing resistant: there’s no code to intercept or trick someone into typing on a fake login page. Some passkeys sync across a user’s devices through a platform vendor, while security keys stay bound to a single physical device. The FIDO Alliance maintains the certification standards that back this approach.

Virtual authenticator apps (TOTP). These generate a six-digit code every 30 seconds using the RFC 6238 TOTP algorithm. They’re free, work on any smartphone, and need no extra hardware. Their weak point is clock drift: if the app’s clock and AWS’s server clock fall out of sync, codes stop validating.

Hardware TOTP tokens. Physical devices that generate the same style of time-based code, useful when phones aren’t allowed near sensitive systems. They carry vendor and seed-provisioning constraints that make large-scale rollout slower than software options.

• Passkeys/security keys: highest phishing resistance, moderate deployability, recovery requires a backup device.
• Virtual TOTP apps: strong security, easiest to deploy, prone to clock-drift support tickets.
• Hardware TOTP tokens: strong security, slower procurement, no battery or app dependency but easy to misplace.

How to Enable MFA for IAM Users and the Root User

Setting up virtual MFA through the console follows the same basic flow for both IAM users and the root account, with one hard rule: root user MFA can only be configured through the console, never through the CLI or API, according to AWS’s own guidance. AWS recommends turning it on for the root user the moment the account is created.

1. Sign in to the account, go to IAM (or Security Credentials for root), and choose “Assign MFA device.”
2. Select the device type: passkey/security key, virtual authenticator app, or hardware TOTP token.
3. For a virtual app, scan the QR code with an authenticator app, then enter two consecutive codes to confirm the device syncs correctly.
4. For a security key, follow the browser prompt to register the physical device or platform passkey.
5. Save the device, and repeat the process to register a second backup device where the account allows it.

For IAM users, the same actions are scriptable. AWS documents the CLI commands: create-virtual-mfa-device to generate the seed, enable-mfa-device to attach two codes and activate it, and resync-mfa-device to fix a device that’s drifted out of sync. Running this requires iam:CreateVirtualMFADevice and iam:EnableMFADevice permissions at minimum.

Pro Tip: Grant your team a self-service IAM policy that allows iam:*MFADevice* actions scoped to their own user ARN. That single policy change eliminates most MFA-related help desk tickets, since people can register and resync their own devices without waiting on an admin.

MFA Best Practices for AWS Environments

AWS’s own guidance is consistent on ordering: reach for FIDO-based passkeys and security keys first, and treat virtual TOTP apps as an acceptable bridge rather than the end state. A few practices separate teams that handle this well from teams that generate support tickets every quarter.

• Register at least two MFA devices per principal, since IAM allows up to eight per user, and store the backup somewhere separate from the primary device.
• Migrate away from SMS entirely, since AWS has ended that method and now points users toward passkeys, virtual apps, or hardware tokens.
• Centralize identity through IAM Identity Center or a federated identity provider once you’re managing more than a handful of users, since AWS notes this cuts the operational load of tracking individual MFA registrations.
• Enforce MFA through IAM policy conditions rather than relying on people to opt in voluntarily.
• Favor roles and temporary credentials for human access over long-lived IAM user access keys, since a short-lived token paired with MFA closes most of the exposure window that static keys leave open.

Larger organizations increasingly skip individual IAM user MFA altogether in favor of enforcing it at the identity provider level, which is worth considering if you’re past a few dozen accounts.

Troubleshooting MFA: Clock Drift, Lost Devices, and Resyncing

TOTP codes fail most often because of clock drift, not user error. If a virtual MFA device stops accepting codes even though they look correct, the device’s internal clock has likely fallen out of sync with AWS’s servers, a known limitation of the RFC 6238 standard itself.

1. Confirm the phone or authenticator app’s time is set to automatic, not manual.
2. Run resync-mfa-device with two consecutive codes generated a few seconds apart to realign the device.
3. If a device is lost or stolen, sign in using a registered backup device immediately and deregister the missing one.
4. If no backup device exists, account recovery requires identity verification through AWS support, which can take days.

That last point is why registering a second device matters more than it seems. Adding or removing an MFA device typically requires MFA from an existing device first, so a single lost phone with no backup can lock you out of your own remediation path. Plan a break-glass procedure, ideally a hardware token stored in a safe, before you need it.

How LogMeOnce’s Passwordless MFA Complements AWS IAM

AWS IAM handles authentication into the AWS console and APIs, but most organizations run MFA across dozens of other systems too. Logmeonce builds passwordless MFA and single sign-on tools designed to centralize that sprawl, pairing FIDO-based authentication with identity management that extends beyond a single cloud provider. For teams already running IAM Identity Center or a federated identity provider, a centralized passwordless layer reduces the number of places employees register separate MFA devices in the first place.

Why Phishing-Resistant MFA Should Be the Default, Not the Upgrade

Most organizations still treat passkeys and security keys as the advanced option and TOTP as the default. That ordering is backward. TOTP was a real improvement over passwords alone, but it still asks a human to copy a code, which means it can still be phished. Security keys remove that step entirely. If you’re setting up MFA for a new team today, start with FIDO and only fall back to virtual apps where hardware isn’t practical yet. Pair that with centralized identity and an actual recovery plan, not an assumption that someone will remember their backup device.

— Mike

Sources

• Multi-Factor Authentication (MFA) for IAM
• RFC 6238 – TOTP: Time-Based One-Time Password Algorithm

FAQ

How Is MFA Used in IAM?

MFA in IAM adds a second identity check, beyond a password or access key, before granting access to the AWS console or APIs. It applies to the root user, individual IAM users, and can be enforced through policy conditions across an account. AWS supports passkeys, security keys, virtual TOTP apps, and hardware tokens as the underlying methods.

How Do I Set Up AWS Multi-Factor Authentication in IAM?

In the IAM console, go to a user’s security credentials, choose “Assign MFA device,” and pick a passkey, security key, or virtual authenticator app. For a virtual app, scan the QR code and enter two consecutive codes to confirm the setup, following the console steps AWS documents. Root user MFA must go through the console; there’s no CLI or API path for it.

What Is the Difference Between IAM and SSO?

IAM manages individual users, roles, and permissions inside a single AWS account. Single sign-on, typically through IAM Identity Center or a federated identity provider, lets one set of credentials and one MFA registration grant access across multiple AWS accounts and applications. Larger organizations generally move to SSO to avoid registering MFA separately for every account a person touches.

Where Do I Find My AWS MFA Code?

Your MFA code comes from whichever device you registered: a virtual authenticator app generates a six-digit TOTP code that refreshes every 30 seconds, a hardware token displays its own rotating code, and a security key or passkey doesn’t show a code at all since it authenticates directly through your browser or device. If a virtual app’s codes stop working, the device has likely drifted out of sync and needs a resync.