What is Multi-Factor Authentication in AWS?

Riyaz Walikar
Feature image

What is Multi-Factor Authentication?

Multi-factor authentication or MFA, also sometimes (slightly incorrectly) referred to as 2-factor authentication, is a security mechanism in which an entity has to provide two or more pieces of information to prove authentication for the entity. If two proofs are required to be provided (the most common/popular choice), it is termed as 2-factor authentication, which would be a subset of multi-factor authentication. These proofs can be of various forms, the first of which in most cases is a username and password combination coupled with one additional authentication credential.

Common Examples in the real world

Multi-factor authentication is fairly common today. Depending on the company/organisation we are talking about, it could be an optional feature, a mandatory setting, or a forced mechanism.

Some of the most common examples for multi-factor authentication are:

  1. Receiving a one-time-password (OTP) on SMS, usually a 6-digit number, to approve monetary transactions in addition to the existing security code/CVV for the bank card
  2. Google sending Are you trying to login notification to your phone and asking you to click the Yes, it’s me button to log in to your Gmail account on a new device in addition to entering your password
  3. Having to connect to a VPN along with using the private key to SSH into a server
  4. Banks require you to have access to a physical key apart from your identification and the key that the Bank Manager will have if you want to access your physical locker

AWS Multi-Factor Authentication

AWS Identity and Access Management (IAM) services allow one to create IAM users, which can have access to resources in the AWS account via the web console and/or CLI credentials. Along with these credentials, AWS provides the ability to add MFA to enhance security for IAM users. The MFA can be in the form of a TOPT (time-based OTP generated typically on a mobile device in an app or password managers) or a hardware key (for example, Yubikey). These keys are then required every time the user signs in through the console along with the username/password combination.

Setting up MFA for AWS IAM

We will look at how to add software and hardware MFA tokens to our IAM users.

Software Token

Setting up software MFA for an IAM user using the web console can be done by following these steps:

  1. Log in to the AWS management console

  2. Navigate to the IAM services page

  3. Click on the “Users” section on the IAM page

  4. Either click on an existing user or create a new user to add software MFA token to

  5. Click on the “Security Credentials” tab on the user details page, it should currently say “Assigned MFA device: Not assigned

    AWS Security Credentials

  6. Click on “Manage” for the “Assigned MFA device” section

    Assigned MFA device

  7. Select the “Virtual MFA device” option and click on the continue button

    Virtual MFA device

  8. You can use a mobile application like Google Authenticator, Microsoft Authenticator to scan the QR code and set up the OTP or get the secret key to use with a Desktop tool like KeePassXC

    setup Virtual MFA device

  9. Next, use the application that was used to set up MFA in the previous step to enter two consecutive MFA codes and click on the “Assign MFA” button

    Assign MFA

  10. The “Assigned MFA device” section now shows the ARN of the virtual device added

    Assigned MFA device The software MFA token is set up for the user and will be asked from the next sign-in to the console.

Hardware Token

Setting up hardware MFA for an IAM user using the web console can be done by following these steps:

  1. Log in to the AWS management console

  2. Navigate to the IAM services page

  3. Click on the “Users” section on the IAM page

  4. Either click on an existing user or create a new user to add software MFA token to

  5. Click on the “Security Credentials” tab on the user details page

    AWS Security Credentials

  6. Click on “Manage” for the “Assigned MFA device” section

    Assigned MFA device

  7. Select the “U2F security key” option and click on continue

    U2F security key

  8. Insert the hardware key and tap the button to assign it to MFA

    setup U2F security key

  9. You might get a browser pop-up asking you to allow AWS to access information about your hardware key, click on “allow”

    hardware key

  10. You should get the following message on successfully adding the hardware token, click on the “Close” button

    aws setup U2F security key

  11. Now we can see that the ARN of the hardware token added in the “Assigned MFA device” section

    ARN of U2F security key

The hardware MFA token is set up for the user and the user will be asked to insert the hardware key from the next sign-in to the console.

What about the CLI?

AWS CLI, by default, does not enforce MFA for executing actions on AWS resources. Additionally, AWS only supports virtual MFA devices for CLI and not U2F security keys.

However, we can create an IAM policy that enforces IAM users to use MFA even while using AWS CLI. The premise of how this works is as follows:

  1. Requests made through AWS CLI (the regular way i.e. without MFA) does not have the MultiFactorAuthPresent key present
  2. We can create an IAM policy that has a conditional statement that checks for the existence of the MultiFactorAuthPresent key
  3. If the key does not exist, we can deny almost all operations (we will need the CLI to fetch some information later before we can use MFA so denying all operations would deny fetching this required information too)
  4. If the key exists, all operations that were permitted to the user can be performed

To create this policy and for a more detailed explanation, use this documentation from AWS as a reference. Once the policy is created, it could be attached to the users on whom we want to enforce MFA for CLI operations, ideally, this applies to all users. A better approach, from a management point of view, would be to add all users to a group and attach the policy to a group instead of individually attaching the policy to each user.

Now that the policy is created and attached to the relevant IAM users, we will use the MFA token to generate temporary sessions with STS to work on AWS resources through the CLI. To create a new STS session with AWS CLI with MFA, follow these steps:

  1. Get the ARN of the MFA device for the user by running the following AWS CLI command (this is why I mentioned that we cannot deny all operations from our MFA enforcement IAM policy)
aws iam list-mfa-devices –user-name <username>

aws iam list-mfa-devices

  1. Next, run the following AWS CLI command to create a temporary STS session for working with the CLI
aws sts get-session-token --serial-number <arn-of-the-mfa-device> --token-code <token>
  1. For more details and a video demonstration, this documentation can be used as a reference

Multi-Factor when AWS is used with an SSO like Okta

Alongside IAM, AWS also provides the ability to use an SSO (single sign-on) service, which can be used with a 3rd party federation tool/organization, like Okta, to provision IAM resources. Taking Okta as an example, once set up, users can sign in to an AWS account via Okta using AWS SSO without having to create IAM users explicitly.

Setting up MFA for accounts created with AWS SSO differs from how we set it up for IAM users in the previous sections. This documentation from AWS can be used to enable MFA with AWS SSO. While setting up MFA, there are three configurations to choose from:

  1. Only when their sign-in context changes (context-aware): A convenient version that only asks for MFA when the context of the user signing-in changes, such as login from a new device, etc.
  2. Every time they sign in (always-on): A bit more tedious as the user must provide an MFA token each time he tries to sign in but this is the most secure option and is strongly recommended
  3. Never (disabled): This configuration would not ask for MFA and definitely not the right configuration to pick

Importance of Multi-Factor Authentication

Multi-factor authentication is an incredible mechanism that allows us to add additional layers of security to our various accounts without (for the most part) having to remember an additional credential or password. This makes our accounts robust to accidental leakage of our credentials, which in most cases are passwords. For an account that has MFA enabled, in case the password to the account is stolen, the attackers cannot log into the account because they do not have all the proofs to authenticate themselves thus keeping our account secure.

Multi-factor authentication can usually go up to 4 separate pieces of information that are required before an entity is authenticated, and with the addition of each layer, it becomes increasingly difficult to break into an account with MFA configured. That being said, it does not mean we should add 10-factor authentication, even if it makes breaking into one’s account virtually impossible because for most purposes 2-factor authentication mechanisms are good enough and it also hampers the user experience of having a tedious sign-in process which could lead to the exact opposite effect as intended when users rebel and stop enabling and using MFA altogether!

While MFA is most certainly a great security control, it does come with one big risk. The risk is what happens if the user loses the MFA device - the phone that had the authenticator app, the Yubikey with the hardware token. Some sites provide you with a list of recovery codes/phrases to allow you back into your accounts in the event of losing access to your MFA device, for example, GitHub. While some accounts would require an administrator to reset/remove the MFA device from your account, AWS is one such entity. This is not to be treated as an excuse to not use MFA, just something to keep in mind. Safely storing these recovery codes is no different from safely storing your password in a password manager and in the case where you need an administrator to reset your account, that is even easier. This is just to ensure that you understand MFA is not a magic bullet to solve all sign-in problems but a great security solution that also has some risks involved.


In this article, we covered what multi-factor authentication is with some common examples, and then we ventured into how MFA can be used with AWS by enabling hardware or software tokens for IAM users to be used along with the regular credentials. Though AWS CLI currently does not support it, we saw how we can still enforce MFA with a combination of IAM policies and STS sessions to work on our AWS resources. Even with services like AWS SSO being used in conjunction with Okta (and other identity federation providers), we can enable MFA with various settings with the recommended setting obviously being to enforce entering MFA information on every sign-in attempt.

Lastly, we talked about how MFA is an increasingly important security control to implement without adding a lot of hindrances (depending on how many layers of authentication we add) makes our cloud accounts and resources exponentially safer. So while we know nothing should be treated as “unhackable”, if you have not implemented it yet, it might be a good time to start enforcing MFA for your cloud accounts and resources as it does increase the overall security of the target system.

This article is brought to you by Kloudle Academy, a free e-resource compilation, created and curated by Kloudle. Kloudle is a cloud security management platform that uses the power of automation and simplifies human requirements in cloud security. If you wish to give your feedback on this article, you can write to us here.

← Back to Academy