AWS MFA: Virtual, Hardware, and Passkey Options

Definition

AWS Multi-Factor Authentication (MFA) requires a second proof of identity — beyond a password — before an identity can sign in to AWS. It combines "something you know" (the password) with "something you have" (an authenticator app, a security key, a hardware token) or "something you are" (a fingerprint or face unlocking that authenticator).

The reason AWS pushes MFA harder than almost any other control is that a stolen password is the single most common route into an AWS account, and MFA breaks that route cleanly: the attacker has the password and still cannot sign in. AWS now enforces MFA on the root user of every account type, including management and member accounts in an AWS Organization — it is no longer a recommendation.

There are two distinct places MFA is configured, and they are not the same system:

• AWS IAM — MFA for the account root user and for individual IAM users, configured per identity inside one account.
• AWS IAM Identity Center (formerly AWS SSO) — MFA for workforce users signing in to the AWS access portal across many accounts, configured centrally with its own prompt policy.

Both are covered below, along with which device type to actually choose.

How It Works

AWS MFA integrates with AWS IAM for both root and IAM users, as well as with AWS IAM Identity Center for federated users. The process enhances security by combining "something you know" (your password) with "something you have" (your MFA device) or "something you are" (a biometric scan).

The typical authentication flow is as follows:

1. A user navigates to the AWS Management Console and enters their user name and password.
2. After successfully validating the password, AWS prompts the user for an authentication code.
3. The user generates a code from their pre-configured MFA device and enters it.
4. AWS validates the code. If correct, it grants the user access to their account and resources.

To enable MFA, an administrator or the user themselves associates an MFA device with their IAM identity. This is a one-time setup process that involves scanning a QR code (for virtual devices) or registering a hardware device's serial number within the IAM console. For API access, users must obtain temporary credentials using the sts:GetSessionToken API call, which requires passing an MFA token.

Administrators can enforce the use of MFA by creating an IAM policy that denies all actions if the user has not authenticated with an MFA device. This ensures that users cannot access any AWS resources until they have set up and are using MFA.

AWS MFA Types Compared

AWS IAM supports exactly three MFA types. SMS text-message MFA is no longer among them — AWS has ended support for SMS MFA, and any IAM users still showing "SMS" in the console's MFA column need migrating.

| | Passkeys & security keys | Virtual MFA device | Hardware TOTP token | | --- | --- | --- | --- | | Standard | FIDO2 / WebAuthn | TOTP (RFC 6238) | TOTP (RFC 6238) | | What it is | A synced passkey in a credential manager, or a physical key like a YubiKey | An authenticator app on a phone or laptop | A dedicated key-fob or display card | | Phishing-resistant | Yes — the credential is cryptographically bound to the real AWS sign-in domain | No — a convincing fake site can harvest the 6-digit code | No | | Cost | Free (synced passkeys) or ~$25–70 per key | Free | ~$20–50 per token, must be bought from an AWS-listed supplier | | Batteries / lifetime | None (keys) | Phone's lifetime | Battery-limited, eventually expires | | Multiple users per device | Yes — one security key can serve several accounts | Yes — apps hold many tokens | No | | Enable via CLI/API | No — console only | Yes | Yes | | Works with sts:GetSessionToken | No — use aws login instead | Yes | Yes |

AWS's own recommendation is passkeys or security keys, because they are the only phishing-resistant option: the FIDO credential is bound to the genuine AWS domain, so a user who is fooled into visiting a lookalike site simply cannot complete authentication. A virtual MFA app is the sensible interim choice while hardware is being procured, not a permanent destination.

Two practical constraints catch people out. Passkeys and security keys can only be registered from the AWS Management Console — there is no CLI or API path. And you cannot pass a passkey or security key to sts:GetSessionToken to mint MFA-protected CLI credentials; the aws login command is the supported route. Teams that script credential vending sometimes discover this after standardising on security keys.

Other features and limits

• Up to eight MFA devices of any combination can be registered per root user and per IAM user. Only one is needed to sign in, and an IAM user must authenticate with an existing device before adding or removing another. Registering two — one everyday device, one stored somewhere safe — is the cheapest possible protection against lockout.
• Mandatory for root users: AWS enforces MFA for the root user of all account types, including management and member accounts within an AWS Organization.
• Hardware tokens must come from AWS-listed suppliers. Token seeds are shared with AWS at manufacture, so a TOTP token bought elsewhere will not work with IAM — unlike security keys, where any FIDO-certified product is fine.
• API and CLI protection: MFA can be required for operations performed via the CLI or SDKs by using MFA-vended temporary credentials.
• IAM Policy control: Access can be gated on whether MFA was used, via the aws:MultiFactorAuthPresent condition key.
• Unassigned virtual devices are deleted automatically when new ones are added, which frees up the device name for reuse.

MFA in AWS IAM Identity Center (AWS SSO)

If your organisation signs in through IAM Identity Center — the successor to AWS SSO — MFA is configured centrally there, not per IAM user. This is a genuinely separate system: Identity Center users, groups, and credentials are distinct from IAM users, and turning MFA on in one place does nothing for the other.

MFA settings live under Settings → Authentication → Multi-factor authentication in the Identity Center console, and the central choice is how often to prompt:

| Prompt mode | Behaviour | | --- | --- | | Every time they sign in (always-on) | The default and the most secure. Any user with a registered device is prompted at every sign-in to the AWS access portal. Required by frameworks such as PCI DSS for high-risk transactions | | Only when their sign-in context changes (context-aware) | Users may mark a device as trusted. Identity Center then prompts once and afterwards analyses device, browser, and location, re-prompting only when that context changes. Easier for staff signing in daily from one office; measurably weaker | | Never (disabled) | Password only. Not recommended — and while disabled, neither administrators nor users can manage MFA devices at all |

Supported authenticators include FIDO2 security keys and built-in biometric authenticators, TOTP authenticator apps, and RADIUS MFA through AWS Directory Service. Note that switching from Disabled to either enabled mode overrides existing RADIUS MFA settings — if you deliberately rely on RADIUS, leaving the mode disabled is what preserves it.

One important exception: if you connect an external identity provider — Okta, Entra ID, Ping — the Multi-factor authentication section disappears from the Identity Center console entirely. Your IdP owns MFA at that point, and enforcement has to be configured there.

Alongside the prompt mode, two related settings decide how strict enrolment is: MFA device enforcement (what happens to users who have no registered device yet — require registration at sign-in, block, or allow) and allowing users to register their own MFA devices rather than an administrator doing it for them.

Common Use Cases

• Securing the AWS Account Root User: This is the most critical use case. The root user has unrestricted access to all resources in the account, and securing it with MFA is a foundational security step that AWS now mandates.
• Protecting Privileged IAM Users: Any IAM user with administrative or sensitive permissions (e.g., permissions to create or delete resources, manage other users, or access sensitive data) should have MFA enabled to prevent account takeover.
• Enforcing Corporate Security Compliance: Organizations can enforce MFA for all users via IAM policies to meet internal security standards or external regulatory requirements (e.g., PCI DSS, HIPAA).
• Securing Cross-Account Access: When using IAM roles to grant access to resources in another AWS account, requiring MFA for the initial authentication before assuming the role adds a critical layer of security.
• Protecting Programmatic Access: Developers and automated systems using the AWS API can be required to use MFA-vended temporary credentials, preventing access key misuse from a compromised machine.

Pricing Model

Using MFA for AWS IAM is generally free of charge.

• Virtual MFA Devices: There is no additional cost for using virtual MFA applications like Google Authenticator or Authy.
• Hardware MFA Devices: While AWS does not charge for using hardware tokens, customers must purchase the physical device from a third-party vendor such as Yubico or Thales.

For services like Amazon Cognito, which provides identity management for custom applications, there may be separate charges for sending MFA codes via SMS, as this uses Amazon Simple Notification Service (SNS) on the backend.

Pros and Cons

Pros:

• Dramatically Increased Security: MFA provides a significant defense against common attacks like phishing, credential stuffing, and brute-force password guessing.
• Low to No Cost: Virtual MFA methods are free to use, making a high level of security accessible to everyone.
• Flexible Options: The support for virtual, hardware, and FIDO security keys allows organizations to choose the right balance of security and user convenience.
• Compliance Enablement: Helps organizations meet strict compliance and regulatory requirements for data protection.

Cons:

• Device Dependency and Loss: If a user loses their only registered MFA device, they will be locked out of their account. A recovery process exists but can cause delays.
• User Friction: It adds an extra step to the sign-in process, which can be a minor inconvenience for users.
• Administrative Overhead: Administrators must manage the MFA lifecycle for users, including setup and handling lost device scenarios for IAM users.

IAM MFA vs IAM Identity Center: Which Should You Use?

MFA is a control, not a service, so the real comparison is between the two places AWS lets you enforce it.

| | IAM MFA | IAM Identity Center MFA | | --- | --- | --- | | Protects | Root user and IAM users, one account at a time | Workforce users signing in to the AWS access portal across many accounts | | Configured | Per identity | Once, centrally, for the whole directory | | Prompt policy | Always, when the identity signs in | Choice of always-on or context-aware | | External IdP | Not applicable | Supported — and the IdP then owns MFA entirely | | Best for | The root user; break-glass identities; single-account setups | Any organisation with more than one AWS account |

The modern guidance is straightforward: use IAM Identity Center for humans, and reserve IAM users for the few cases that genuinely need long-lived credentials. IAM MFA still matters regardless, because every account has a root user and every root user must have MFA — Identity Center does not change that.

Common Pitfalls

• Registering exactly one MFA device. The single most common way to lose access to an AWS account. Since AWS allows eight, register at least two — a phone authenticator plus a security key kept in a safe. With a spare, a lost phone is an inconvenience; without one, root recovery means a support case and days of delay.
• Assuming MFA on the root user protects the account. It protects the root user. Every IAM user is a separate identity with its own MFA configuration, and an administrator IAM user without MFA is just as dangerous a foothold.
• Enforcing MFA with a policy that locks users out of enrolling. A Deny on everything when aws:MultiFactorAuthPresent is false must carve out the handful of iam:*VirtualMFADevice and iam:EnableMFADevice calls a user needs to register a device — otherwise they cannot set up the MFA the policy is demanding.
• Trusting aws:MultiFactorAuthPresent in a role trust policy without care. The key is absent, not false, for some credential types, and a Bool condition on a missing key does not match. Use BoolIfExists deliberately and understand which way it fails.
• Standardising on security keys before checking the tooling. Passkeys and security keys cannot be enrolled from the CLI or API, and cannot be used with sts:GetSessionToken. Teams that automate credential vending need to plan for aws login first.
• Forgetting Identity Center is separate. Turning on MFA for IAM users does nothing for people who sign in through the AWS access portal, and vice versa. With an external IdP wired into Identity Center, neither AWS setting applies — MFA lives in Okta or Entra ID.

Exam Relevance

MFA is a fundamental and frequently tested topic across nearly all AWS certification exams, from Foundational to Professional and Specialty levels.

• AWS Certified Cloud Practitioner (CLF-C02): Expect questions on the basic concept of MFA and its importance as a security best practice, especially for the root user.
• AWS Certified Solutions Architect – Associate (SAA-C03): Questions may involve scenarios where you need to secure access for IAM users, enforce MFA using policies, and understand the different MFA options.
• AWS Certified Security – Specialty (SCS-C02): Deep knowledge is required. Expect questions on enforcing MFA for CLI/API access, troubleshooting MFA issues, and integrating MFA with federated identity solutions.

Examinees must know what MFA is, why it's critical for the root user, the different types of MFA available, and how to enforce its use with IAM policies.

Frequently Asked Questions

Q: What should I do if I lose my MFA device?

A: The recovery process depends on whether you are the root user or an IAM user. If you are an IAM user, you must contact an account administrator to have them deactivate the MFA device from your user profile, allowing you to sign in with your password and set up a new device. If you are the root user and have lost your device, you can attempt to recover your account by using the email address and phone number associated with the account for verification. If that fails, you will need to contact AWS Support.

Q: How can I require all of my users to use MFA?

A: You can enforce MFA use by attaching an IAM identity-based policy to your IAM users or groups. This policy should include a statement with "Effect": "Deny" for all actions ("NotAction") except those required to set up MFA, with a condition that checks if "aws:MultiFactorAuthPresent": "false". This policy effectively blocks users from doing anything in the AWS console or API until they have enabled and authenticated with an MFA device.

Q: What is a virtual MFA device in AWS?

A: A virtual MFA device is an authenticator application — Google Authenticator, Microsoft Authenticator, Authy, 1Password and similar — running on a phone or laptop that emulates a physical token. It implements the TOTP algorithm (RFC 6238) and displays a six-digit code that rotates roughly every 30 seconds. You register it by scanning a QR code in the IAM console, which transfers the shared secret, then entering two consecutive codes to prove the clock is in sync. One app can hold many tokens, so a single phone can cover several AWS accounts plus everything else you use. It is free and instant to set up, which makes it the usual starting point — but it is not phishing-resistant, because a convincing fake sign-in page can simply ask you for the code and replay it.

Q: How do I set up MFA for AWS SSO users?

A: AWS SSO is now IAM Identity Center, and its MFA is configured centrally rather than per user: open the IAM Identity Center console, go to Settings → Authentication → Multi-factor authentication, and choose Configure. Set the prompt mode to Every time they sign in (always-on) unless you have a specific reason not to, decide whether users may register their own devices, and set MFA device enforcement for users who have not enrolled yet. Note two things: these settings apply to the AWS access portal, not to IAM users in individual accounts, and if you have connected an external identity provider the MFA section will not appear at all — your IdP owns MFA in that case.

Q: What is the difference between a virtual MFA device and a FIDO security key?

A: A virtual MFA device is a software application (like Google Authenticator) on your phone or computer that generates a rotating 6-digit code based on the TOTP algorithm. A FIDO security key (like a YubiKey) is a physical, hardware-based authenticator that uses public key cryptography. FIDO keys are considered more secure because they are resistant to phishing attacks; a user must physically touch the device to authenticate, and the cryptographic exchange is bound to the specific website (e.g., the AWS console), preventing credentials from being used on a fake site.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.