Multi-factor authentication requires evidence from at least two different factor categories: knowledge, such as a password; possession, such as a security key or authenticator device; and inherence, such as a biometric. A password followed by another password or a security question is not MFA because both are knowledge factors. A passkey can provide multi-factor authentication when its possession-based credential requires local user verification through a PIN or biometric; two separate login prompts are not inherently necessary.
In cloud environments, MFA primarily protects human authentication. Engineers typically authenticate through a central identity provider, satisfy its MFA policy, and receive short-lived access to cloud accounts through federation and roles. Authentication establishes who the user is; authorization determines what that user can do. MFA does not grant permissions, replace least privilege, or make cross-account role assumption secure without appropriate trust and permissions policies.
For AWS workforce access, IAM Identity Center can provide centralized sign-in and account assignments. With an external identity provider, enforce MFA at that provider and validate the complete federation flow. For IAM users, administrators can associate supported MFA devices and require MFA for relevant access paths. Enrolling a device is not equivalent to enforcing MFA for every operation. Test console access, command-line access, role assumption, and recovery separately.
Console MFA does not automatically protect requests signed with long-term access keys. For supported IAM-user API workflows, AWS Security Token Service can issue temporary credentials through GetSessionToken or AssumeRole using an MFA device identifier and a time-based one-time password. FIDO security keys used for browser sign-in are not interchangeable with the token-code parameters of these APIs. A practical administrative workflow is to obtain an MFA-authenticated temporary session and use that session for approved operations rather than relying on permanent access keys.
Policy conditions require careful interpretation. The aws:MultiFactorAuthPresent condition key is not universally present, including in requests made with long-term access keys, and external identity-provider MFA is not automatically represented by that key in federated sessions. A deny policy that must also reject requests lacking MFA context commonly needs BoolIfExists rather than a simple Bool test, but its scope must account for automation and service access. For federated access, enforce MFA at the identity provider and design any downstream assurance checks using supported, trusted session attributes. Cross-account roles do not inherently require MFA.
Protect AWS account root users separately from ordinary administrators. Where root credentials exist, register MFA, protect the root email account and recovery channels, avoid root access keys, and reserve root use for tasks that require it. Maintain separately secured backup authenticators where supported. In AWS Organizations, centralized root access management can remove root credentials from member accounts and prevent their recovery; privileged root actions can instead use authorized, task-scoped temporary root sessions through STS AssumeRoot. This does not remove the need to secure the management account's root user, and service control policies do not restrict the management account.
Break-glass procedures should define who can authorize emergency access, how credentials and authenticators are protected, which recovery paths remain available, and how every use is logged and reviewed. Test these procedures without making emergency access an unmonitored permanent bypass. Losing an authenticator, an identity-provider outage, or inaccessible recovery email can otherwise turn strong authentication into an availability incident.
MFA methods have different threat resistance and operational costs. Time-based codes can be phished, SMS introduces telecom-related risks, and repeated push prompts can cause approval fatigue. Properly implemented FIDO2/WebAuthn authentication resists credential phishing through origin binding. MFA still does not prevent misuse of a stolen authenticated session, so short-lived sessions, endpoint security, and monitoring remain necessary. Applications and systems should normally use workload roles, federation, or certificates rather than a shared human MFA device; customer-facing applications can implement MFA through an identity platform such as Amazon Cognito.
Amazon Cognito
AWS Organizations