AWS MFA: Keeping your Account Secure via Multi-Factor Authentication

AWS MFA: Keeping your Account Secure via Multi-Factor Authentication

An AWS account comes with unlimited possibilities. You can provision almost endless computing resources that exceed small data centers. This power comes with the risk of potential misuse. That's why protecting your account and each IAM user is important. Enabling multi-factor authentication is one crucial step (creating organizations a second 😉)


Before we stumble into practice, let's go through the fundamentals of MFA. We'll go through the definition of MFA, why it's important to enable it, and which MFA types are currently supported by AWS

What Is Multi-Factor Authentication

Multi-Factor Authentication (or short MFA) adds another layer of security to any authentication mechanism. With MFA you can combine:

  • something you know, e.g. your username and password, with

  • something you own, e.g. a device (virtual or hardware-based) that issues a one-time password

The multi-factor authentication flow via the credentials and the TOTP.

Even if one gets compromised, it won't be enough to access the corresponding service in your name.

Importance of MFA at AWS

As said in the introduction, with great power comes great responsibility. Your AWS is one of your most significant responsibilities as a compromised account can ruin your financial future in a short time frame.

MFA is one major security layer to prevent account compromise. And it comes for free and with low effort.

Supported Types

Different MFA types can be used with AWS. Among them are:

  • Virtual MFA devices - A virtual device, often a smartphone app, that's used to generate a time-based one-time password (TOTP). Popular are the Google or Microsoft Authenticator or Authy.

  • Hardware MFA devices - A physical device that also generates a TOTP that's just valid for a specific time frame. YubiKey or RSA security tokens are well-known and widely used MFA hardware devices.

  • SMS-delivered MFA codes - A one-time code that is sent to your mobile phone via SMS. This method is discouraged by AWS and many other services as it has potential security vulnerabilities, including a high risk for spoofing and fishing as well as SIM swapping.

The most commonly used type is the virtual MFA via an authentication app.

Setting up AWS MFA

Setting up an MFA method at AWS is simple and only takes a few minutes.

Enabling a Virtual MFA Device for the Root User

After logging in with your root user, click on the top right of your user and select Security Credentials for being redirected to the security dashboard of your account.

You'll see options to change your password, create access keys for command line access and assign an MFA device. By clicking on the latter one, you'll be prompted to choose your preferred method.

Choosing a MFA type.

Let's select the authenticator app. You can use any authenticator you prefer, e.g. Google Authenticator, Microsoft Authenticator, or Authy. Each of them is available for both Android and iOS devices.

Assigning your virtual MFA device by generating two consecutive TOTPs..

After scanning the QR code with your device, the app will start to generate one-time passwords (commonly with 6 digits). You'll have to enter two consecutive codes at the AWS console to activate the virtual device which will then require you to enter both your credentials and a one-time pass for every login to the console.

The list of assigned MFA devices to your IAM or root user.

MFA for IAM Users

IAM users can be heavily restricted in their possible permissions. Nevertheless, it's best practice to configure an MFA device for those users.

The MFA configuration is completely decoupled from the root user. Each IAM user can and should have their MFA device.

Setting it up is exactly equal to the steps shown before for your root user. Everything happens in the security credentials tab after logging into the AWS console with the specific user.

Hardware TOTP Tokens and FIDO Security Keys

TOTP token generators work by sharing a secret and the current time to generate a password that can be used one time to complete the authentication that has started with the login credentials.

The password will be generated via a mathematical algorithm and the internal clock which ensures that the password is both unique and cannot be guessed easily. Hardware TOTP tokens like SecurID by RSA are a convenient MFA method that doesn't require your phone or an internet connection. Additionally, it can be a good backup mechanism in the event of a failure or loss of the primary MFA devices.

Besides TOTP token hardware devices, there's support for FIDO U2F keys at AWS. YubiKeys are a prominent example of a FIDO-capable device. They work by requiring the user to interact with the device physically, typically by pressing a button, to complete the authentication flow.

This is another security enhancement as the authentication mechanism can't solely be completed via software, but always requires physical interaction.


We've successfully set up MFA devices for our account's root and IAM users. Let's go through all the flows for which we'll now require the second factor.

Logging into the AWS Management Console

After successfully setting up MFA for your user, each login will be prompted for an MFA code.

Logging into the AWS console with an assigned MFA.

Go back to your authenticator app and type in the current code that appears. Note the limited time that the code is valid and can be used to complete your login.

Getting Temporary Credentials for the AWS API

After you've enabled MFA, you can't simply work with only your AWS Access Key ID and Secret Access anymore. You're always required to use temporary credentials that can be retrieved with your keys and a TOTP from your device.

# providing the Access Key ID and Secret Access key
aws configure
  AWS Access Key ID [None]: AKIA...H43K
  AWS Secret Access Key [None]: rIrB...Wvm91
  Default region name [None]: us-east-1
  Default output format [None]: json

# retrieving a session token and exporting it directly
export AWS_SESSION_TOKEN=$(aws sts get-session-token \
    --serial-number arn:aws:iam::0123456789012:mfa/john.doe
    --token-code 287781 \
    | jq -r .Credentials.SessionToken)

If you're not a terminal fan, this is very tedious work. But there are a lot of tools that make this process way easier.

One of them is Leapp which also helps you to easily assume identities & roles. It even supports other providers like Azure.

Leapp helps to easily work with MFA devices and multiple accounts.

For a more simplistic terminal-based experience you can use AWSume.

Best Practices for the Daily Work

Enabling MFA for Root Users and Locking them Away

Your root user has full control over your account, your billing, and every resource you’ll ever create. As a best practice, it’s recommended to lock it away immediately after enabling MFA and switch to Identity and Access Management (IAM) users.

Don’t ever use the root credentials for your daily work, neither in the AWS console nor with infrastructure as code or the AWS command line interface.

Also, citing the AWS documentation about root users:

We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user.

Enforcing MFA for Users

As the root user of an account, it's possible to strictly enforce MFA for IAM users. This needs the configuration of a policy that denies all actions except for those to manage the user's own credentials and MFA devices.

Let's jump to IAM and select Policies on the navigation tab, then choose Create Policy.

Select the JSON tab and insert the policy that you can find in one of the AWS guides that cover how to allow MFA-authenticated IAM users to manage their own credentials.

The important part is the following statement:

  "Sid": "DenyAllExceptListedIfNoMFA",
  "Effect": "Deny",
  "NotAction": [
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"

It restricts users from all actions that are not necessary to set up their MFA devices.

After you've created the policy you can attach it to your desired IAM user's group so all users will be forced to use MFA from now on. Be sure to test this carefully before with a test group.

Monitoring Usage of MFA

You can verify that IAM users are using MFA by checking CloudTrail logs for sign-in events.

List of ConsoleLogin actions that were tracked by CloudTrail.

You only have to click on your event history and filter for the event name ConsoleLogin. By selecting an event you'll see the event itself which will look like this:

    "eventVersion": "1.08",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "AIDA...JLEH",
        "arn": "arn:aws:iam::0123456789012:user/john.doe",
        "accountId": "0123456789012",
        "userName": ""
    "eventTime": "2022-12-23T07:31:55Z",
    "additionalEventData": {
        "LoginTo": "",
        "MobileVersion": "No",
        "MFAIdentifier": "arn:aws:iam::0123456789012:mfa/john.doe",
        "MFAUsed": "Yes"

By checking the nested object additionalEventData you will find MFAUsed.

You can also automate this by creating a dedicated trail, sending the events to CloudWatch, and setting up an alarm that will notify you in case of a login event without MFA occurs.

About Password Managers and Their MFA Capabilities

Yes, this is very convenient. But it completely undercuts the purpose of having a second factor at all, as it's supposed to require another physical or virtual device. As the compromise of an AWS account can have an immense impact on your financial resources, we commend keeping your second factor a real second factor.


Things can go wrong and humans do make mistakes. That's especially true for the software development process. Let's go through the most common ones regarding MFA.

Recovering your account after losing the MFA device

If you lose your MFA device, you're not completely lost. You can still contact AWS Support. Alternatively, check the guide by AWS on what to do if an MFA device is lost or stops working.

If your TOTP codes are rejected, it can be due to the fact that your MFA device is out of sync (this can't happen for FIDO security keys) and needs to be resynchronized.


Enabling multi-factor authentication for your account is a must. It will immensely enhance the security of your account.

If you haven't done this yet, the next best time is now.