# IAM users
<a name="id_users"></a>

**Important**  
 IAM [best practices](best-practices.md) recommend that you require human users to use federation with an identity provider to access AWS using temporary credentials instead of using IAM users with long-term credentials. We recommend that you only use IAM users for [specific use cases](gs-identities-iam-users.md) not supported by federated users.

An *IAM user* is an entity that you create in your AWS account. The IAM user represents the human user or workload who uses the IAM user to interact with AWS resources. An IAM user consists of a name and credentials.

An IAM user with administrator permissions is not the same thing as the AWS account root user. For more information about the root user, see [AWS account root user](id_root-user.md).

## How AWS identifies an IAM user
<a name="id_users_create_aws-identifiers"></a>

When you create an IAM user, IAM creates these ways to identify that user:
+ A "friendly name" for the IAM user, which is the name that you specified when you created the IAM user, such as `Richard` or `Anaya`. These are the names you see in the AWS Management Console. Because IAM user names appear in Amazon Resource Names (ARNs), we do not recommend including personally identifying information in the IAM name. Refer to [IAM name requirements](reference_iam-quotas.md#reference_iam-quotas-names) for requirements and restrictions for IAM names.
+ An Amazon Resource Name (ARN) for the IAM user. You use the ARN when you need to uniquely identify the IAM user across all of AWS. For example, you could use an ARN to specify the IAM user as a `Principal` in an IAM policy for an Amazon S3 bucket. An ARN for an IAM user might look like the following: 

  `arn:aws:iam::account-ID-without-hyphens:user/Richard`
+ A unique identifier for the IAM user. This ID is returned only when you use the API, Tools for Windows PowerShell, or AWS CLI to create the IAM user; you do not see this ID in the console.

For more information about these identifiers, see [IAM identifiers](reference_identifiers.md).

## IAM users and credentials
<a name="id_users_creds"></a>

You can access AWS in different ways depending on the IAM user credentials:
+ [**Console password**](id_credentials_passwords.md): A password that the IAM user can type to sign in to interactive sessions such as the AWS Management Console. Disabling the password (console access) for an IAM user prevents them from signing in to the AWS Management Console using their sign-in credentials. It does not change their permissions or prevent them from accessing the console using an assumed role. IAM users with console access enabled can also use these same credentials to authenticate for AWS CLI and SDK access using the `aws login` AWS CLI command. These users will need to have [SignInLocalDevelopmentAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SignInLocalDevelopmentAccess.html) permissions. See [Authentication and access credentials for the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-authentication.html) in the *AWS Command Line Interface User Guide* for more details. 
+ [**Access keys**](id_credentials_access-keys.md): Used to make programmatic calls to AWS. However, there are more secure alternatives to consider before you create access keys for IAM users. For more information, see [Considerations and alternatives for long-term access keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#alternatives-to-long-term-access-keys) in the *AWS General Reference*. If the IAM user has active access keys, they continue to function and allow access through the AWS CLI, Tools for Windows PowerShell, AWS API, or the AWS Console Mobile Application.
+ [**SSH keys for use with CodeCommit**](id_credentials_ssh-keys.md): An SSH public key in the OpenSSH format that can be used to authenticate with CodeCommit.
+ [**Server certificates**](id_credentials_server-certs.md): SSL/TLS certificates that you can use to authenticate with some AWS services. We recommend that you use AWS Certificate Manager (ACM) to provision, manage, and deploy your server certificates. Use IAM only when you must support HTTPS connections in a region that is not supported by ACM. To learn which regions support ACM, see [AWS Certificate Manager endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/acm.html) in the *AWS General Reference*.

You can choose the credentials that are right for your IAM user. When you use the AWS Management Console to create an IAM user, you must choose to at least include a console password or access keys. By default, a brand new IAM user created using the AWS CLI or AWS API has no credentials of any kind. You must create the type of credentials for an IAM user based on your use case. 

You have the following options to administer passwords, access keys, and multi-factor authentication (MFA) devices:
+ **[Manage passwords for your IAM users](id_credentials_passwords.md).** Create and change the passwords that permit access to the AWS Management Console. Set a password policy to enforce a minimum password complexity. Allow IAM users to change their own passwords. 
+ **[Manage access keys for your IAM users](id_credentials_access-keys.md).** Create and update access keys for programmatic access to the resources in your account. 
+ **[Enable multi-factor authentication (MFA) for the IAM user](id_credentials_mfa.md).** As a [best practice](best-practices.md), we recommend that you require multi-factor authentication for all IAM users in your account. With MFA, IAM users must provide two forms of identification: First, they provide the credentials that are part of their user identity (a password or access key). In addition, they provide a temporary numeric code that's generated on a hardware device or by an application on a smartphone or tablet.
+ **[Find unused passwords and access keys](id_credentials_finding-unused.md).** Anyone who has a password or access keys for your account or an IAM user in your account has access to your AWS resources. The security [best practice](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html) is to remove passwords and access keys when IAM users no longer need them.
+ **[Download a credential report for your account](id_credentials_getting-report.md).** You can generate and download a credential report that lists all IAM users in your account and the status of their various credentials, including passwords, access keys, and MFA devices. For passwords and access keys, the credential report shows how recently the password or access key has been used.

## IAM users and permissions
<a name="id_users_perms"></a>

By default, a new IAM user has no [permissions](access.md) to do anything. They are not authorized to perform any AWS operations or to access any AWS resources. An advantage of having individual IAM users is that you can assign permissions individually to each user. You might assign administrative permissions to a few users, who then can administer your AWS resources and can even create and manage other IAM users. In most cases, however, you want to limit a user's permissions to just the tasks (AWS actions or operations) and resources that are needed for the job. 

Imagine a user named Diego. When you create the IAM user `Diego`, you create a password for him and attach permissions that let him launch a specific Amazon EC2 instance and read (`GET`) information from a table in an Amazon RDS database. For procedures on how to create IAM users and grant them initial credentials and permissions, see [Create an IAM user in your AWS account](id_users_create.md). For procedures on how to change the permissions for existing users, see [Change permissions for an IAM user](id_users_change-permissions.md). For procedures on how to change the user's password or access keys, see [User passwords in AWS](id_credentials_passwords.md) and [Manage access keys for IAM users](id_credentials_access-keys.md).

You can also add a permissions boundary to your IAM users. A permissions boundary is an advanced feature that allows you to use AWS managed policies to limit the maximum permissions that an identity-based policy can grant to an IAM user or role. For more information about policy types and uses, see [Policies and permissions in AWS Identity and Access Management](access_policies.md).

## IAM users and accounts
<a name="id_users_accounts"></a>

Each IAM user is associated with one and only one AWS account. Because IAM users are defined within your AWS account, they don't need to have a payment method on file with AWS. Any AWS activity performed by IAM users in your account is billed to your account.

The number and size of IAM resources in an AWS account are limited. For more information, see [IAM and AWS STS quotas](reference_iam-quotas.md).

## IAM users as service accounts
<a name="id_users_service_accounts"></a>

An IAM user is a resource in IAM that has associated credentials and permissions. An IAM user can represent a person or an application that uses its credentials to make AWS requests. This is typically referred to as a *service account*. If you choose to use the long-term credentials of an IAM user in your application, **do not embed access keys directly into your application code.** The AWS SDKs and the AWS Command Line Interface allow you to put access keys in known locations so that you do not have to keep them in code. For more information, see [Manage IAM User Access Keys Properly](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html#iam-user-access-keys) in the *AWS General Reference*. Alternatively, and as a best practice, you can [use temporary security credentials (IAM roles) instead of long-term access keys](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html#use-roles).

# How IAM users sign in to AWS
<a name="id_users_sign-in"></a>

To sign in to the AWS Management Console as an IAM user, you must provide your account ID or account alias in addition to your user name and password. When your administrator created your IAM user in the console, they should have sent you your sign-in credentials, including your user name and the URL to your account sign-in page that includes your account ID or account alias. 

```
https://My_AWS_Account_ID.signin.aws.amazon.com/console/
```

**Tip**  
To create a bookmark for your account sign-in page in your web browser, you should manually type the sign-in URL for your account in the bookmark entry. Do not use your web browser bookmark feature because redirects can obscure the sign-in URL. 

You can also sign in at the following general sign-in endpoint and type your account ID or account alias manually:

```
[https://console.aws.amazon.com/](https://console.aws.amazon.com/)
```

For convenience, the AWS sign-in page uses a browser cookie to remember the IAM user name and account information. The next time the user goes to any page in the AWS Management Console, the console uses the cookie to redirect the user to the account sign-in page.

You have access only to the AWS resources that your administrator specifies in the policy that is attached to your IAM user identity. To work in the console, you must have permissions to perform the actions that the console performs, such as listing and creating AWS resources. For more information, see [Access management for AWS resources](access.md) and [Example IAM identity-based policies](access_policies_examples.md).

**Note**  
If your organization has an existing identity system, you might want to create a single sign-on (SSO) option. SSO gives users access to the AWS Management Console for your account without requiring them to have an IAM user identity. SSO also eliminates the need for users to sign in to your organization's site and to AWS separately. For more information, see [Enable custom identity broker access to the AWS console](id_roles_providers_enable-console-custom-url.md). 

**Logging sign-in details in CloudTrail**  
If you enable CloudTrail to log sign-in events to your logs, you need to be aware of how CloudTrail chooses where to log the events.
+ If your users sign-in directly to a console, they are redirected to either a global or a regional sign-in endpoint, based on whether the selected service console supports regions. For example, the main console home page supports regions, so if you sign in to the following URL:

  ```
  https://alias.signin.aws.amazon.com/console
  ```

  you are redirected to a regional sign-in endpoint such as `https://us-east-2.signin.aws.amazon.com`, resulting in a regional CloudTrail log entry in the user's region's log:

  On the other hand, the Amazon S3 console does not support regions, so if you sign in to the following URL

  ```
  https://alias.signin.aws.amazon.com/console/s3
  ```

  AWS redirects you to the global sign-in endpoint at `https://signin.aws.amazon.com`, resulting in a global CloudTrail log entry.
+ You can manually request a certain regional sign-in endpoint by signing in to the region-enabled main console home page using a URL syntax like the following:

  ```
  https://alias.signin.aws.amazon.com/console?region=ap-southeast-1
  ```

  AWS redirects you to the `ap-southeast-1` regional sign-in endpoint and results in a regional CloudTrail log event.

For more information about CloudTrail and IAM, see [Logging IAM events with CloudTrail](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html).

If users need programmatic access to work with your account, you can create an access key pair (an access key ID and a secret access key) for each user. However, there are more secure alternatives to consider before you create access keys for users. For more information, see [Considerations and alternatives for long-term access keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#alternatives-to-long-term-access-keys) in the *AWS General Reference*.

## Additional resources
<a name="id_users_sign-in-additional-resources"></a>

The following resources can help you learn more about AWS sign-in.
+ The [AWS Sign-In User Guide](https://docs.aws.amazon.com/signin/latest/userguide/what-is-sign-in.html) helps you understand the different ways that you can sign in to Amazon Web Services (AWS), depending on what type of user you are.
+ You can sign in up to five different identities simultaneously in a single web browser in the AWS Management Console. For details, see [Signing in to multiple accounts](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/multisession.html) in the *AWS Management Console Getting Started Guide*.

# MFA enabled sign-in
<a name="console_sign-in-mfa"></a>

Users who are configured with [multi-factor authentication (MFA)](id_credentials_mfa.md) devices must use their MFA devices to sign in to the AWS Management Console. After the user enters their sign-in credentials, AWS checks the user's account to see if MFA is required for that user. 

**Important**  
If you use access key and secret key credentials for direct AWS Management Console access with the AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API call, MFA will NOT be required. For more information, see [Using access keys and secret key credentials for console access](securing_access-keys.md#console-access-security-keys).

The following topics provide information on how users complete signing in when MFA is required. 

**Topics**
+ [

## Multiple MFA devices enabled
](#console_sign-in-multiple-mfa)
+ [

## FIDO security key
](#console_sign-in-mfa-fido)
+ [

## Virtual MFA device
](#console_sign-in-mfa-virtual)
+ [

## Hardware TOTP token
](#console_sign-in-mfa-hardware)

## Multiple MFA devices enabled
<a name="console_sign-in-multiple-mfa"></a>

If a user signs in to the AWS Management Console as an AWS account root user or IAM user with multiple MFA devices enabled for that account, they only need to use one MFA device to sign in. After the user authenticates with the user’s password, they select which MFA device type they would like to use to finish authenticating. Then the user is prompted to authenticate with the type of device that they selected. 

## FIDO security key
<a name="console_sign-in-mfa-fido"></a>

If MFA is required for the user, a second sign-in page appears. The user needs to tap the FIDO security key.

**Note**  
Google Chrome users should not choose any of the available options on the pop-up that asks to **Verify your identity with amazon.com**. You only need to tap on the security key.

Unlike other MFA devices, FIDO security keys do not go out of sync. Administrators can deactivate a FIDO security key if it's lost or broken. For more information, see [Deactivating MFA devices (console)](id_credentials_mfa_disable.md#deactive-mfa-console).

For information on browsers that support WebAuthn and FIDO-compliant devices that AWS supports, see [Supported configurations for using passkeys and security keys](id_credentials_mfa_fido_supported_configurations.md).

## Virtual MFA device
<a name="console_sign-in-mfa-virtual"></a>

If MFA is required for the user, a second sign-in page appears. In the **MFA code** box, the user must enter the numeric code provided by the MFA application.

If the MFA code is correct, the user can access the AWS Management Console. If the code is incorrect, the user can try again with another code. 

A virtual MFA device can go out of sync. If a user cannot sign in to the AWS Management Console after several tries, the user is prompted to synchronize the virtual MFA device. The user can follow the on-screen prompts to synchronize the virtual MFA device. For information about how you can synchronize a device on behalf of a user in your AWS account, see [Resynchronize virtual and hardware MFA devices](id_credentials_mfa_sync.md). 

## Hardware TOTP token
<a name="console_sign-in-mfa-hardware"></a>

If MFA is required for the user, a second sign-in page appears. In the **MFA code** box, the user must enter the numeric code provided by a hardware TOTP token. 

If the MFA code is correct, the user can access the AWS Management Console. If the code is incorrect, the user can try again with another code. 

A hardware TOTP token can go out of sync. If a user can't sign in to the AWS Management Console after several tries, the user is prompted to synchronize the MFA token device. The user can follow the on-screen prompts to synchronize the MFA token device. For information about how you can synchronize a device on behalf of a user in your AWS account, see [Resynchronize virtual and hardware MFA devices](id_credentials_mfa_sync.md). 

# Create an IAM user in your AWS account
<a name="id_users_create"></a>

**Important**  
 IAM [best practices](best-practices.md) recommend that you require human users to use federation with an identity provider to access AWS using temporary credentials instead of using IAM users with long-term credentials. We recommend that you only use IAM users for [specific use cases](gs-identities-iam-users.md) not supported by federated users.

The process of creating an IAM user and enabling that user to perform tasks consists of the following steps:

1. Create the [user in the AWS Management Console, the AWS CLI](getting-started-workloads.md), Tools for Windows PowerShell, or using an AWS API operation. If you create the user in the AWS Management Console, then steps 1–4 are handled automatically, based on your choices. If you create the IAM users programmatically, then you must perform each of those steps individually.

1. Create credentials for the user, depending on the type of access the user requires:
   + **Enable console access – *optional***: If the user needs to access the AWS Management Console, [create a password for the user](id_credentials_passwords_admin-change-user.md). Disabling console access for a user prevents them from signing in to the AWS Management Console using their user name and password. It does not change their permissions or prevent them from accessing the console using an assumed role.
**Tip**  
Create only the credentials that the user needs. For example, for a user who requires access only through the AWS Management Console, do not create access keys.

1. Give the user permissions to perform the required tasks. We recommend that you put your IAM users in groups and manage permissions through policies that are attached to those groups. However, you can also grant permissions by attaching permissions policies directly to the user. If you use the console to add the user, you can copy the permissions from an existing user to the new user.

   You can also add a [permissions boundary](access_policies_boundaries.md) to limit the user’s permissions by specifying a policy that defines the maximum permissions that the user can have. Permissions boundaries don't grant any permissions.

   For instructions on creating a custom permission policy to use to either grant permissions or set a permissions boundary, see [Define custom IAM permissions with customer managed policies](access_policies_create.md).

1. (Optional) Add metadata to the user by attaching tags. For more information about using tags in IAM, see [Tags for AWS Identity and Access Management resources](id_tags.md).

1. Provide the user with the necessary sign-in information. This includes the password and the console URL for the account sign-in page where the user provides those credentials. For more information, see [How IAM users sign in to AWS](id_users_sign-in.md).

1. (Optional) Configure [multi-factor authentication (MFA)](id_credentials_mfa.md) for the user. MFA requires the user to provide a one-time-use code each time he or she signs into the AWS Management Console.

1. (Optional) Give IAM users permissions to manage their own security credentials. (By default, IAM users do not have permissions to manage their own credentials.) For more information, see [Permit IAM users to change their own passwords](id_credentials_passwords_enable-user-change.md).
**Note**  
If you use the console to create the user and you select **User must create a new password at next sign-in (recommended)**, the user has the required permissions.

For information about the permissions that you need in order to create a user, see [Permissions required to access IAM resources](access_permissions-required.md).

For instructions on creating IAM users for specific use cases, see the following topics:
+ [Create an IAM user for emergency access](getting-started-emergency-iam-user.md)
+ [Create an IAM user for workloads that can't use IAM roles](getting-started-workloads.md)

# View IAM users
<a name="id_users_list"></a>

You can list the IAM users in your AWS account or in a specific IAM group, and list all the IAM groups that a user is in. For information about the permissions that you need in order to list users, see [Permissions required to access IAM resources](access_permissions-required.md). 

## To list all the IAM users in your account
<a name="id_users_manage_list-users"></a>

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Users**. 

The console displays the IAM users in your AWS account.

------
#### [ AWS CLI ]

Run the following command:
+ `[aws iam list-users](https://docs.aws.amazon.com/cli/latest/reference/iam/list-users.html)`

------
#### [ API ]

Call the following operation:
+ `[ListUsers](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html)` 

------

## To list the IAM users in an IAM group
<a name="id_users_manage_list-users-group"></a>

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **User groups**.

1. Choose the name of the user group. 

The IAM users that are members of the group are listed on the **Users** tab.

------
#### [ AWS CLI ]

Run the following command:
+ `[aws iam get-group](https://docs.aws.amazon.com/cli/latest/reference/iam/get-group.html)`

------
#### [ API ]

Call the following operation:
+ `[GetGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)` 

------

## To list all the IAM groups that a user is in
<a name="id_users_manage_list-groups-users"></a>

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Users**.

1. In the **Users** list, choose the name of the IAM user. 

1. Select the **Groups** tab to display the list of groups that include the current user.

------
#### [ AWS CLI ]

Run the following command:
+ `[aws iam list-groups-for-user](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups-for-user.html)`

------
#### [ API ]

Call the following operation:
+ `[ListGroupsForUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroupsForUser.html)` 

------

## Next steps
<a name="id_users_list-next-steps"></a>

Once you have a list of your IAM users, you can rename, delete, or deactivate an IAM user using the following procedures.
+ [Rename an IAM user](id_users_rename.md)
+ [Remove or deactivate an IAM user](id_users_remove.md)

# Rename an IAM user
<a name="id_users_rename"></a>

**Note**  
As a [best practice](best-practices.md), we recommend that you require human users to use federation with an identity provider to access AWS using temporary credentials. If you follow the best practices, you are not managing IAM users and groups. Instead, your users and groups are managed outside of AWS and are able to access AWS resources as a *federated identity*. A federated identity is a user from your enterprise user directory, a web identity provider, the AWS Directory Service, the Identity Center directory, or any user that accesses AWS services by using credentials provided through an identity source. Federated identities use the groups defined by their identity provider. If you are using AWS IAM Identity Center, see [Manage identities in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html) in the *AWS IAM Identity Center User Guide* for information about creating users and groups in IAM Identity Center.

Amazon Web Services offers multiple tools for managing the IAM users in your AWS account. You can list the IAM users in your account or in a user group, or list all IAM groups that a user is a member of. You can rename or change the path of an IAM user. If you are moving to using federated identities instead of IAM users, you can delete an IAM user from your AWS account, or deactivate the user.

For more information about adding, changing, or removing managed policies for an IAM user, see [Change permissions for an IAM user](id_users_change-permissions.md). For information about managing inline policies for IAM users, see [Adding and removing IAM identity permissions](access_policies_manage-attach-detach.md), [Edit IAM policies](access_policies_manage-edit.md), and [Delete IAM policies](access_policies_manage-delete.md). As a best practice, use managed policies instead of inline policies. *AWS managed policies* grant permissions for many common use cases. Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they are available for use by all AWS customers. As a result, we recommend that you reduce permissions further by defining [customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases. For more information, see [AWS managed policies](access_policies_managed-vs-inline.md#aws-managed-policies). For more information about AWS managed policies that are designed for specific job functions, see [AWS managed policies for job functions](access_policies_job-functions.md).

To learn about validating IAM policies, see [IAM policy validation](access_policies_policy-validator.md).

**Tip**  
[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) can analyze the services and actions that your IAM roles use, and then generate a fine-grained policy that you can use. After you test each generated policy, you can deploy the policy to your production environment. This ensures that you grant only the required permissions to your workloads. For more information about policy generation, see [IAM Access Analyzer policy generation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html).

For information about managing IAM user passwords, see [Manage passwords for IAM users](id_credentials_passwords_admin-change-user.md).

## Renaming an IAM user
<a name="id_users_renaming"></a>

To change a user's name or path, you must use the AWS CLI, Tools for Windows PowerShell, or AWS API. There is no option in the console to rename a user. For information about the permissions that you need in order to rename a user, see [Permissions required to access IAM resources](access_permissions-required.md). 

When you change a user's name or path, the following happens: 
+ Any policies attached to the user stay with the user under the new name.
+ The user stays in the same IAM groups under the new name.
+ The unique ID for the user remains the same. For more information about unique IDs, see [Unique identifiers](reference_identifiers.md#identifiers-unique-ids).
+ Any resource or role policies that refer to the user *as a principal* (the user is being granted access) are automatically updated to use the new name or path. For example, any queue-based policies in Amazon SQS or resource-based policies in Amazon S3 are automatically updated to use the new name and path. 

IAM does not automatically update policies that refer to the user *as a resource* to use the new name or path; you must manually do that. For example, imagine that user `Richard` has a policy attached to him that lets him manage his security credentials. If an administrator renames `Richard` to `Rich`, the administrator also needs to update that policy to change the resource from this:

```
arn:aws:iam::111122223333:user/division_abc/subdivision_xyz/Richard
```

to this:

```
arn:aws:iam::111122223333:user/division_abc/subdivision_xyz/Rich
```

This is true also if an administrator changes the path; the administrator needs to update the policy to reflect the new path for the user. 

### To rename a user
<a name="id_users_manage_list-users-rename"></a>
+ AWS CLI: [aws iam update-user](https://docs.aws.amazon.com/cli/latest/reference/iam/update-user.html)
+ AWS API: [UpdateUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateUser.html) 

# Remove or deactivate an IAM user
<a name="id_users_remove"></a>

[Best practices](best-practices.md#remove-credentials) recommend that you remove unused IAM users from your AWS account. If you want to retain the IAM users credentials for future use, instead of deleting them from the account you can deactivate the user's access. For more information, see [Deactivating an IAM user](#id_users_deactivating).

**Warning**  
Once an IAM user and its access keys are deleted, they cannot be restored or recovered.

## Prerequisite – View IAM user access
<a name="users-manage_prerequisites"></a>

Before you remove a user, review their recent service-level activity. This helps prevent removing access from a principal (person or application) who is using it. For more information about viewing last accessed information, see [Refine permissions in AWS using last accessed information](access_policies_last-accessed.md).

## Removing an IAM user (console)
<a name="id_users_deleting_console"></a>

When you use the AWS Management Console to remove an IAM user, IAM automatically deletes the following associated information: 
+ The IAM user identifier
+ Any group memberships—that is, the IAM user is removed from any groups that the IAM user was a member of
+ Any password associated with the IAM user 
+ All inline policies embedded in the IAM user (policies that were applied to the IAM user using user group permissions are not affected) 
**Note**  
IAM removes any managed policies attached to the IAM user when you delete the user, but does not delete managed policies. 
+ Any associated MFA device

### To remove an IAM user (console)
<a name="id_users_remove-section-1"></a>

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Users**, and then select the checkbox next to the IAM user name that you want to delete. 

1. At the top of the page, choose **Delete**.
**Note**  
If any of the users have active access keys, you must deactivate the access keys before deleting the users. For more information, see [To deactivate an access key for an IAM user](access-keys-admin-managed.md#admin-deactivate-access-key).

1. In the confirmation dialog box, enter the username in the text input field to confirm the deletion of the user. Choose **Delete**. 

The console displays a status notification that the IAM user was deleted.

------

## Deleting an IAM user (AWS CLI)
<a name="id_users_deleting_cli"></a>

Unlike the AWS Management Console, when you delete a IAM user with the AWS CLI, you must delete the items attached to the IAM user manually. This procedure illustrates the process. 

**To delete an IAM user from your AWS account (AWS CLI)**

1. Delete the user's password, if the user has one.

   `[aws iam delete-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-login-profile.html)`

1. Delete the user's access keys, if the user has them.

   `[aws iam list-access-keys](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)` (to list the user's access keys) and `[aws iam delete-access-key](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)`

1. Delete the user's signing certificate. Note that when you delete a security credential, it's gone forever and can't be retrieved.

   `[aws iam list-signing-certificates](https://docs.aws.amazon.com/cli/latest/reference/iam/list-signing-certificates.html)` (to list the user's signing certificates) and `[aws iam delete-signing-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-signing-certificate.html)`

1. Delete the user's SSH public key, if the user has them.

   `[aws iam list-ssh-public-keys](https://docs.aws.amazon.com/cli/latest/reference/iam/list-ssh-public-keys.html)` (to list the user's SSH public keys) and `[aws iam delete-ssh-public-key](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-ssh-public-key.html)`

1. Delete the user's Git credentials.

   `[aws iam list-service-specific-credentials](https://docs.aws.amazon.com/cli/latest/reference/iam/list-service-specific-credentials.html)` (to list the user's git credentials) and `[aws iam delete-service-specific-credential](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-service-specific-credential.html)`

1. Deactivate the user's multi-factor authentication (MFA) device, if the user has one.

   `[aws iam list-mfa-devices](https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-devices.html)` (to list the user's MFA devices), `[aws iam deactivate-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html)` (to deactivate the device), and `[aws iam delete-virtual-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-virtual-mfa-device.html)` (to permanently delete a virtual MFA device) 

1. Delete the user's inline policies. 

   `[aws iam list-user-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-user-policies.html)` (to list the inline policies for the user) and [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-user-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-user-policy.html) (to delete the policy) 

1. Detach any managed policies that are attached to the user. 

   `[aws iam list-attached-user-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-user-policies.html)` (to list the managed policies attached to the user) and [https://docs.aws.amazon.com/cli/latest/reference/iam/detach-user-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/detach-user-policy.html) (to detach the policy) 

1. Remove the user from any IAM groups. 

   `[aws iam list-groups-for-user](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups-for-user.html)` (to list the IAM groups to which the user belongs) and `[aws iam remove-user-from-group](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-user-from-group.html)` 

1. Delete the user.

   `[aws iam delete-user](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-user.html)` 

## Deactivating an IAM user
<a name="id_users_deactivating"></a>

You might need to deactivate an IAM user while they are temporarily away from your company. You can leave their IAM user credentials in place and still block their AWS access.

To deactivate a user, create and attach a policy to deny the user access to AWS. You can restore the user's access later.

Here are two examples of deny policies that you can attach to a user to deny their access.

The following policy does not include a time limit. You must remove the policy to restore the user's access.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [ 
      {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*"
      } 
   ]
}
```

------

The following policy includes a condition that starts the policy on December 24, 2024 at 11:59 PM (UTC) and ends it on February 28, 2025 at 11:59 PM (UTC).

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
      {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
          "DateGreaterThan": {"aws:CurrentTime": "2024-12-24T23:59:59Z"},
          "DateLessThan": {"aws:CurrentTime": "2025-02-28T23:59:59Z"}
          }
       }
   ]
}
```

------

# Control IAM user access to the AWS Management Console
<a name="console_controlling-access"></a>

IAM users with permission who sign in to your AWS account through the AWS Management Console can access your AWS resources. The following list shows the ways that you can grant IAM users access to your AWS account resources through the AWS Management Console. It also shows how IAM users can access other AWS account features through the AWS website.

**Note**  
There is no charge to use IAM.

**The AWS Management Console**  
You create a password for each IAM user who needs access to the AWS Management Console. Users access the console through your IAM-enabled AWS account sign-in page. For information about accessing the sign-in page, see [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*. For information about creating passwords, see [User passwords in AWS](id_credentials_passwords.md).  
You can prevent an IAM user from accessing the AWS Management Console by removing their password. This prevents them from signing into the AWS Management Console using their sign-in credentials. It does not change their permissions or prevent them from accessing the console using an assumed role. If the user has active access keys, they continue to function and allow access through the AWS CLI, Tools for Windows PowerShell, AWS API, or the AWS Console Mobile Application.

**Your AWS resources, such as Amazon EC2 instances, Amazon S3 buckets, and so on**  
Even if your IAM users have passwords, they still need permission to access your AWS resources. When you create an IAM user, that user has no permissions by default. To give your IAM users the permissions they need, you attach policies to them. If you have many IAM users who perform the same tasks with the same resources, you can assign those IAM users to a group. Then assign the permissions to that group. For information about creating IAM users and groups, see [IAM Identities](id.md). For information about using policies to set permissions, see [Access management for AWS resources](access.md).

**AWS Discussion Forums**  
Anyone can read the posts on the [AWS Discussion Forums](https://forums.aws.amazon.com/). Users who want to post questions or comments to the AWS Discussion Forum can do so using their user name. The first time a user posts to the AWS Discussion Forum, the user is prompted to enter a nickname and email address. Only that user can use that nickname in the AWS Discussion Forums. 

**Your AWS account billing and usage information**  
You can grant users access your AWS account billing and usage information. For more information, see [ Controlling Access to Your Billing Information](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/control-access-billing.html) in the *AWS Billing User Guide*. 

**Your AWS account profile information**  
Users cannot access your AWS account profile information.

**Your AWS account security credentials**  
Users cannot access your AWS account security credentials.

**Note**  
IAM policies control access regardless of the interface. For example, you could provide a user with a password to access the AWS Management Console. The policies for that user (or any groups the user belongs to) would control what the user can do in the AWS Management Console. Or, you could provide the user with AWS access keys for making API calls to AWS. The policies would control which actions the user could call through a library or client that uses those access keys for authentication.

# Change permissions for an IAM user
<a name="id_users_change-permissions"></a>

You can change the permissions for an IAM user in your AWS account by changing its group memberships, by copying permissions from an existing user, by attaching policies directly to a user, or by setting a [permissions boundary](access_policies_boundaries.md). A permissions boundary controls the maximum permissions that a user can have. Permissions boundaries are an advanced AWS feature.

For information about the permissions that you need in order to modify the permissions for a user, see [Permissions required to access IAM resources](access_permissions-required.md).

**Topics**
+ [

## View user access
](#users-modify_prerequisites)
+ [

## Generate a policy based on a user's access activity
](#users_change_permissions-gen-policy)
+ [

## Adding permissions to a user (console)
](#users_change_permissions-add-console)
+ [

## Changing permissions for a user (console)
](#users_change_permissions-change-console)
+ [

## To remove a permissions policy from a user (console)
](#users_change_permissions-remove-policy-console)
+ [

## To remove the permissions boundary from a user (console)
](#users_change_permissions-remove-boundary-console)
+ [

## Adding and removing a user's permissions (AWS CLI or AWS API)
](#users_change_permissions-add-programmatic)

## View user access
<a name="users-modify_prerequisites"></a>

Before you change the permissions for a user, you should review its recent service-level activity. This is important because you don't want to remove access from a principal (person or application) who is using it. For more information about viewing last accessed information, see [Refine permissions in AWS using last accessed information](access_policies_last-accessed.md).

## Generate a policy based on a user's access activity
<a name="users_change_permissions-gen-policy"></a>

You might sometimes grant permissions to an IAM entity (user or role) beyond what they require. To help you refine the permissions that you grant, you can generate an IAM policy that is based on the access activity for an entity. IAM Access Analyzer reviews your AWS CloudTrail logs and generates a policy template that contains the permissions that have been used by the entity in your specified date range. You can use the template to create a managed policy with fine-grained permissions and then attach it to the IAM entity. That way, you grant only the permissions that the user or role needs to interact with AWS resources for your specific use case. To learn more, see [IAM Access Analyzer policy generation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html).

## Adding permissions to a user (console)
<a name="users_change_permissions-add-console"></a>

IAM offers three ways to add permissions policies to a user:
+ **Add the IAM user to an IAM group** – Make the user a member of a group. The policies from the group are attached to the user.
+ **Copy permissions from an existing IAM user** – Copy all group memberships, attached managed policies, inline policies, and any existing permissions boundaries from the source user.
+ **Attach policies directly to the IAM user** – Attach a managed policy directly to the user. For easier permissions management, attach your policies to a group and then make IAM users members of the appropriate groups.

**Important**  
If the user has a permissions boundary, then you cannot add more permissions to the user than are allowed by the permissions boundary.

### To add permissions by adding the IAM user to a group
<a name="users_change_permissions-add-group-console"></a>

Adding an IAM user to an IAM group updates the user's permissions with the permissions defined for the group immediately.

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Users**.

1. In the **Users** list, choose the name of the IAM user. 

1. Select the **Groups** tab to display the list of groups that include the current user.

1. Choose **Add user to groups**. 

1. Select the checkbox for each group that you want the user to join. The list shows each group's name and the policies that the user receives if made a member of that group.

1. (Optional) You can choose **Create group** to define a new group. This is useful if you want to add the user to a group with different attached policies than the existing groups:

   1. In the new tab, for **User group name**, type a name for your new group.
**Note**  
The number and size of IAM resources in an AWS account are limited. For more information, see [IAM and AWS STS quotas](reference_iam-quotas.md). Group names can be a combination of up to 128 letters, digits, and these characters: plus (\$1), equal (=), comma (,), period (.), at sign (@), and hyphen (-). Names must be unique within an account. They are not distinguished by case. For example, you cannot create two groups named *TESTGROUP* and *testgroup*.

   1. Select one or more checkboxes for the managed policies that you want to attach to the group. You can also create a new managed policy by choosing **Create policy**. If you do, return to this browser tab or window when the new policy is done; choose **Refresh**; and then choose the new policy to attach it to your group. For more information, see [Define custom IAM permissions with customer managed policies](access_policies_create.md).

   1. Choose **Create user group**.

   1. Return to the original tab, refresh your list of groups. Then select the checkbox for your new group.

1. Choose **Add user to group(s)**.

The console displays a status message informing you that the user has been added to the groups you specified.

------

### To add permissions by copying from another IAM user
<a name="users_change_permissions-add-copy-console"></a>

If you choose to add permissions to an IAM user by copying permissions, IAM copies all group memberships, attached managed policies, inline policies, and any existing permissions boundaries from the specified user and applies them immediately to the currently selected user.

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Users**.

1. In the **Users** list, choose the name of the IAM user. 

1. On the **Permissions** tab choose and select **Add permissions**.

1. On the **Add permissions** page, choose **Copy permissions**. The list displays available IAM users along with their group memberships and attached policies. 

1. Select the radio button next to the user whose permissions you want to copy. 

1. Choose **Next** to see the list of changes that are to be made to the user. Then choose **Add permissions**.

The console displays a status message informing you that the permissions were copied from the IAM user you specified.

------

### To add permissions by attaching policies directly to the IAM user
<a name="users_change_permissions-add-directly-console"></a>

You can attach a managed policy directly to an IAM user. The updated permissions are applied immediately.

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Users**.

1. In the **Users** list, choose the name of the IAM user. 

1. On the **Permissions** tab, choose and select **Add permissions**.

1. On the **Add permissions** page, choose **Attach policies directly**. The **Permissions policies** list displays available policies along with their policy types and attached entities. 

1. Select the radio button next to the **Policy name** you want to attach. 

1. Choose **Next** to see the list of changes that are to be made to the user. Then choose **Add permissions**.

The console displays a status message informing you that the policy was added to the IAM user you specified.

------

### To set the permissions boundary for an IAM user
<a name="users_change_permissions-set-boundary-console"></a>

A permissions boundary is an advanced feature for managing permissions in AWS that is used to set the maximum permissions that an IAM user can have. Setting a permissions boundary immediately restricts the IAM user permissions to the boundary, regardless of the other permissions granted.

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Users**.

1. In the **Users** list, choose the name of the IAM user whose permissions boundary you want to change. 

1. Choose the **Permissions** tab. If necessary, open the **Permissions boundary** section and then choose **Set permissions boundary**.

1. On the **Set permissions boundary** page, under **Permissions policies** select the policy that you want to use for the permissions boundary.

1. Choose **Set boundary**.

The console displays a status message informing you that the permissions boundary has been added.

------

## Changing permissions for a user (console)
<a name="users_change_permissions-change-console"></a>

IAM allows you to change the permissions that are associated with a user in the following ways:
+ **Edit a permissions policy** – Edit a user's inline policy, the inline policy of the user's group, or edit a managed policy that is attached to the user directly or from a group. If the user has a permissions boundary, then you cannot provide more permissions than are allowed by the policy that was used as the user's permissions boundary.
+ **Changing the permissions boundary** – Change the policy that is used as the permissions boundary for the user. This can expand or restrict the maximum permissions that a user can have. 

### Editing a permissions policy attached to a user
<a name="users_change_permissions-edit-policy-console"></a>

Changing permissions updates the user's access immediately.

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Users**.

1. In the **Users** list, choose the name of the IAM user whose permissions boundary you want to change. 

1. Choose the **Permissions** tab. If necessary, open the **Permissions boundary** section.

1. Choose the name of the policy that you want to edit to view details about the policy. Choose the **Entities attached** tab to view other entities (IAM users, groups, and roles) that might be affected if you edit the policy. 

1. Choose the **Permissions** tab and review the permissions granted by the policy. To make changes to the permissions, choose **Edit**. 

1. Edit the policy and resolve any [policy validation](access_policies_policy-validator.md) recommendations. For more information, see [Edit IAM policies](access_policies_manage-edit.md).

1. Choose **Next**, review the policy summary, and then choose **Save changes**.

The console displays a status message informing you that the policy has been updated.

------

### To change the permissions boundary for a user
<a name="users_change_permissions-change-boundary-console"></a>

Changing a permissions boundary updates the user's access immediately.

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Users**.

1. In the **Users** list, choose the name of the IAM user whose permissions boundary you want to change. 

1. Choose the **Permissions** tab. If necessary, open the **Permissions boundary** section and then choose **Change boundary**.

1. Select the policy that you want to use for the permissions boundary.

1. Choose **Set boundary**.

The console displays a status message informing you that the permissions boundary has been changed.

------

## To remove a permissions policy from a user (console)
<a name="users_change_permissions-remove-policy-console"></a>

Removing a permissions policy updates the user's access immediately.

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Users**.

1. Choose the name of the user whose permissions policies you want to remove. 

1. Choose the **Permissions** tab. 

1. If you want to remove permissions by removing an existing policy, view the **Attached via** column to understand how the user is getting that policy before choosing **Remove** to remove the policy:
   + If the policy applies because of group membership, then choosing **Remove** removes the user from the group. Remember that you might have multiple policies attached to a single group. If you remove a user from a group, the user loses access to *all* policies that it received through that group membership.
   + If the policy is a managed policy attached directly to the user, then choosing **Remove** detaches the policy from the user. This does not affect the policy itself or any other entity that the policy might be attached to.
   + If the policy is an inline embedded policy, then choosing **Remove** removes the policy from IAM. Inline policies that are attached directly to a user exist only on that user.

If the policy was granted to the user through a group membership, the console displays a status message informing you that the IAM user was removed from the IAM group. If the policy directly attached or inline, the status message informs you that the policy has been removed.

------

## To remove the permissions boundary from a user (console)
<a name="users_change_permissions-remove-boundary-console"></a>

Removing the permissions boundary updates the user's access immediately.

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Users**.

1. In the **Users** list, choose the name of the IAM user whose permissions boundary you want to remove. 

1. Choose the **Permissions** tab. If necessary, open the **Permissions boundary** section.

1.  Choose **Change boundary**. To confirm that you want to remove the permissions boundary, in the confirmation dialog, choose **Remove boundary**.

The console displays a status message informing you that the permissions boundary has been removed.

------

## Adding and removing a user's permissions (AWS CLI or AWS API)
<a name="users_change_permissions-add-programmatic"></a>

To add or remove permissions programmatically, you must add or remove the group memberships, attach or detach the managed policies, or add or delete the inline policies. For more information, see the following topics:
+ [Edit users in IAM groups](id_groups_manage_add-remove-users.md)
+ [Adding and removing IAM identity permissions](access_policies_manage-attach-detach.md)

# User passwords in AWS
<a name="id_credentials_passwords"></a>

You can manage passwords for IAM users in your account. IAM users need passwords in order to access the AWS Management Console. Users do not need passwords to access AWS resources programmatically by using the AWS CLI, Tools for Windows PowerShell, the AWS SDKs or APIs. For those environments, you have the option of assigning IAM users [access keys](id_credentials_access-keys.md). However, there are other more secure alternatives to access keys that we recommend you consider first. For more information, see [AWS security credentials](security-creds.md).

**Note**  
If one of your IAM users lose or forget their password, you *cannot* retrieve them from IAM. Depending on your settings, either the user or the administrator must create a new password.

**Topics**
+ [

# Set an account password policy for IAM users
](id_credentials_passwords_account-policy.md)
+ [

# Manage passwords for IAM users
](id_credentials_passwords_admin-change-user.md)
+ [

# Permit IAM users to change their own passwords
](id_credentials_passwords_enable-user-change.md)
+ [

# How an IAM user changes their own password
](id_credentials_passwords_user-change-own.md)

# Set an account password policy for IAM users
<a name="id_credentials_passwords_account-policy"></a>

You can set a custom password policy on your AWS account to specify complexity requirements and mandatory rotation periods for your IAM users' passwords. If you don't set a custom password policy, IAM user passwords must meet the default AWS password policy. For more information, see [Custom password policy options](#password-policy-details).

**Topics**
+ [

## Rules for setting a password policy
](#password-policy-rules)
+ [

## Permissions required to set a password policy
](#default-policy-permissions-required)
+ [

## Default password policy
](#default-policy-details)
+ [

## Custom password policy options
](#password-policy-details)
+ [

## To set a password policy (console)
](#IAMPasswordPolicy)
+ [

## To change a password policy (console)
](#id_credentials_passwords_account-policy-section-1)
+ [

## To delete a custom password policy (console)
](#id_credentials_passwords_account-policy-section-2)
+ [

## Setting a password policy (AWS CLI)
](#PasswordPolicy_CLI)
+ [

## Setting a password policy (AWS API)
](#PasswordPolicy_API)

## Rules for setting a password policy
<a name="password-policy-rules"></a>

The IAM password policy does not apply to the AWS account root user password or IAM user access keys. If a password expires, the IAM user can't sign in to the AWS Management Console but can continue to use their access keys.

When you create or change a password policy, most of the password policy settings are enforced the next time your users change their passwords. However, some of the settings are enforced immediately. For example: 
+ When the minimum length and character type requirements change, these settings are enforced the next time that your users change their passwords. Users are not forced to change their existing passwords, even if the existing passwords do not adhere to the updated password policy.
+ When you set a password expiration period, the expiration period is enforced immediately. For example, assume that you set a password expiration period of 90 days. In that case, the password expires for all IAM users whose existing password is older than 90 days. Those users are required to change their password the next time that they sign in.

You can't create a "lockout policy" to lock a user out of the account after a specified number of failed sign-in attempts. For enhanced security, we recommend that you combine a strong password policy with multi-factor authentication (MFA). For more information about MFA, see [AWS Multi-factor authentication in IAM](id_credentials_mfa.md).

## Permissions required to set a password policy
<a name="default-policy-permissions-required"></a>

You must configure permissions to allow an IAM entity (user or role) to view or edit their account password policy. You can include the following password policy actions in an IAM policy: 
+ `iam:GetAccountPasswordPolicy` – Allows the entity to view the password policy for their account
+ `iam:DeleteAccountPasswordPolicy` – Allows the entity to delete the custom password policy for their account and revert to the default password policy
+ `iam:UpdateAccountPasswordPolicy` – Allows the entity to create or change the custom password policy for their account

The following policy allows full access to view and edit the account password policy. To learn how to create an IAM policy using this example JSON policy document, see [Creating policies using the JSON editor](access_policies_create-console.md#access_policies_create-json-editor).

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "FullAccessPasswordPolicy",
            "Effect": "Allow",
            "Action": [
                "iam:GetAccountPasswordPolicy",
                "iam:DeleteAccountPasswordPolicy",
                "iam:UpdateAccountPasswordPolicy"
            ],
            "Resource": "*"
        }
    ]
}
```

------

For information about the permissions required for an IAM user to change their own password, see [Permit IAM users to change their own passwords](id_credentials_passwords_enable-user-change.md).

## Default password policy
<a name="default-policy-details"></a>

If an administrator does not set a custom password policy, IAM user passwords must meet the default AWS password policy.

The default password policy enforces the following conditions:
+ Minimum password length of 8 characters and a maximum length of 128 characters
+ Minimum of three of the following mix of character types: uppercase, lowercase, numbers, and non-alphanumeric character (`! @ # $ % ^ & * ( ) _ + - = [ ] { } | '`)
+ Not be identical to your AWS account name or email address
+ Never expire password

## Custom password policy options
<a name="password-policy-details"></a>

When you configure a custom password policy for your account, you can specify the following conditions:
+ **Password minimum length** – You can specify a minimum of 6 characters and a maximum of 128 characters.
+ **Password strength** – You can select any of the following checkboxes to define the strength of your IAM user passwords:
  + Require at least one uppercase letter from the Latin alphabet (A–Z)
  + Require at least one lowercase letter from the Latin alphabet (a–z)
  + Require at least one number
  + Require at least one nonalphanumeric character `! @ # $ % ^ & * ( ) _ + - = [ ] { } | '` 
+ **Turn on password expiration** – You can select and specify a minimum of 1 and a maximum of 1,095 days that IAM user passwords are valid after they are set. For example, if you specify an expiration of 90 days, it immediately impacts all of your users. For users with passwords older than 90 days, when they log into the console after the change, they must set a new password. Users with passwords 75-89 days old receive an AWS Management Console warning about their password expiration. IAM users can change their password at any time if they have permission. When they set a new password, the expiration period for that password starts over. An IAM user can have only one valid password at a time.
+ **Password expiration requires administrator reset** – Select this option to prevent IAM users from using the AWS Management Console to update their own passwords after the password expires. Before you select this option, confirm that your AWS account has more than one user with administrative permissions to reset IAM user passwords. Administrators with `iam:UpdateLoginProfile` permission can reset IAM user passwords. IAM users with `iam:ChangePassword` permission and active access keys can reset their own IAM user console password programmatically. If you clear this checkbox, IAM users with expired passwords must still set a new password before they can access the AWS Management Console.
+ **Allow users to change their own password** – You can permit all IAM users in your account to change their own password. This gives users access to the `iam:ChangePassword` action for only their user and to the `iam:GetAccountPasswordPolicy` action. This option does not attach a permissions policy to each user. Rather, IAM applies the permissions at the account-level for all users. Alternatively, you can allow only some users to manage their own passwords. To do so, you clear this checkbox. For more information about using policies to limit who can manage passwords, see [Permit IAM users to change their own passwords](id_credentials_passwords_enable-user-change.md).
+ **Prevent password reuse** – You can prevent IAM users from reusing a specified number of previous passwords. You can specify a minimum number of 1 and a maximum number of 24 previous passwords that can't be repeated. 

## To set a password policy (console)
<a name="IAMPasswordPolicy"></a>

You can use the AWS Management Console to create, change, or delete a custom password policy. Changes to the password policy apply to new IAM users created after this policy change and existing IAM users when they change their passwords.

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Account settings**.

1. In the **Password policy** section, choose **Edit**. 

1. Choose **Custom** to use a custom password policy.

1. Select the options that you want to apply to your password policy and choose **Save changes**. 

1. Confirm that you want to set a custom password policy by choosing **Set custom**.

The console displays a status message informing you that password requirements for IAM users have been updated.

------

## To change a password policy (console)
<a name="id_credentials_passwords_account-policy-section-1"></a>

You can use the AWS Management Console to create, change, or delete a custom password policy. Changes to the password policy apply to new IAM users created after this policy change and existing IAM users when they change their passwords.

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Account settings**.

1. In the **Password policy** section, choose **Edit**. 

1. Select the options that you want to apply to your password policy and choose **Save changes**. 

1. Confirm that you want to set a custom password policy by choosing **Set custom**.

The console displays a status message informing you that password requirements for IAM users have been updated.

------

## To delete a custom password policy (console)
<a name="id_credentials_passwords_account-policy-section-2"></a>

You can use the AWS Management Console to create, change, or delete a custom password policy. Changes to the password policy apply to new IAM users created after this policy change and existing IAM users when they change their passwords.

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Account settings**.

1. In the **Password policy** section, choose **Edit**. 

1. Choose **IAM default** to delete the custom password policy and choose **Save changes**.

1. Confirm that you want to set the IAM default password policy by choosing **Set default**.

The console displays a status message informing you that the password policy is set to IAM default.

------

## Setting a password policy (AWS CLI)
<a name="PasswordPolicy_CLI"></a>

You can use the AWS Command Line Interface to set a password policy.

**To manage the custom account password policy from the AWS CLI**  
Run the following commands:
+ To create or change the custom password policy: [https://docs.aws.amazon.com/cli/latest/reference/iam/update-account-password-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-account-password-policy.html)
+ To view the password policy: [https://docs.aws.amazon.com/cli/latest/reference/iam/get-account-password-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-account-password-policy.html) 
+ To delete the custom password policy: [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-account-password-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-account-password-policy.html) 

## Setting a password policy (AWS API)
<a name="PasswordPolicy_API"></a>

You can use AWS API operations to set a password policy.

**To manage the custom account password policy from the AWS API**  
Call the following operations:
+ To create or change the custom password policy: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccountPasswordPolicy.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccountPasswordPolicy.html)
+ To view the password policy: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountPasswordPolicy.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountPasswordPolicy.html) 
+ To delete the custom password policy: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccountPasswordPolicy.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccountPasswordPolicy.html) 

# Manage passwords for IAM users
<a name="id_credentials_passwords_admin-change-user"></a>

IAM users who use the AWS Management Console to work with AWS resources must have a password in order to sign in. You can create, change, or delete a password for an IAM user in your AWS account. 

After you have assigned a password to a user, the user can sign in to the AWS Management Console using the sign-in URL for your account, which looks like this: 

```
https://12-digit-AWS-account-ID or alias.signin.aws.amazon.com/console
```

For more information about how IAM users sign in to the AWS Management Console, see [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*. 

Even if your users have their own passwords, they still need permissions to access your AWS resources. By default, a user has no permissions. To give your users the permissions they need, you assign policies to them or to the groups they belong to. For information about creating users and groups, see [IAM Identities](id.md). For information about using policies to set permissions, see [Change permissions for an IAM user](id_users_change-permissions.md). 

You can grant users permission to change their own passwords. For more information, see [Permit IAM users to change their own passwords](id_credentials_passwords_enable-user-change.md). For information about how users access your account sign-in page, see [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*. 

**Topics**
+ [

## Creating, changing, or deleting an IAM user password (console)
](#id_credentials_passwords_admin-change-user_console)

## Creating, changing, or deleting an IAM user password (console)
<a name="id_credentials_passwords_admin-change-user_console"></a>

You can use the AWS Management Console to manage passwords for your IAM users.

The access needs of your users can change over time. You might need to enable a user intended for CLI access to have console access, change a user's password because they receive the email with their credentials, or delete a user when they leave your organization or no longer need AWS access. 

### To create an IAM user password (console)
<a name="id_credentials_passwords_admin-change-user-section-1"></a>

Use this procedure to give a user console access by creating a password that is associated with the username.

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Users**.

1. Choose the name of the user whose password you want to create. 

1. Choose the **Security credentials** tab, and then under **Console sign-in**, choose **Enable console access**.

1. In the **Enable console access** dialog box, select **Reset password**, then choose whether to have IAM generate a password or create a custom password: 
   + To have IAM generate a password, choose **Autogenerated password**.
   + To create a custom password, choose **Custom password**, and type the password. 
**Note**  
The password that you create must meet the account's [password policy](id_credentials_passwords_account-policy.md).

1. To require the user to create a new password when signing in, choose **Require password change at the next sign-in**. 

1. To require the user to use the new password immediately, select **Revoke active console sessions**. This attaches an inline policy to the IAM user that denies the user access to resources if their credentials are older than the time specified by the policy.

1. Choose **Reset password**

1. The **Console password** dialog informs you that you have enabled the user's new password. To view the password so you can share it with the user, choose **Show** in the **Console password** dialog box. Select **Download .csv file** to download a file with the user's credentials.
**Important**  
For security reasons, you cannot access the password after completing this step, but you can create a new password at any time.

The console displays a status message informing you that console access has been enabled.

------

### To change the password for an IAM user (console)
<a name="id_credentials_passwords_admin-change-user-section-2"></a>

Use this procedure to update a password that is associated with the username.

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Users**.

1. Choose the name of the user whose password you want to change. 

1. Choose the **Security credentials** tab, and then under **Console sign-in**, choose **Manage console access**.

1. In the **Manage console access** dialog box, select **Reset password**, then choose whether to have IAM generate a password or create a custom password: 
   + To have IAM generate a password, choose **Autogenerated password**.
   + To create a custom password, choose **Custom password**, and type the password. 
**Note**  
The password that you create must meet the account's [password policy](id_credentials_passwords_account-policy.md).

1. To require the user to create a new password when signing in, choose **Require password change at the next sign-in**. 

1. To require the user to use the new password immediately, select **Revoke active console sessions**. This attaches an inline policy to the IAM user that denies the user access to resources if their credentials are older than the time specified by the policy.

1. Choose **Reset password**

1. The **Console password** dialog informs you that you have enabled the user's new password. To view the password so you can share it with the user, choose **Show** in the **Console password** dialog box. Select **Download .csv file** to download a file with the user's credentials.
**Important**  
For security reasons, you cannot access the password after completing this step, but you can create a new password at any time.

The console displays a status message informing you that console access has been updated.

------

### To delete (disable) an IAM user password (console)
<a name="id_credentials_passwords_admin-change-user-section-3"></a>

Use this procedure to delete a password that is associated with the username, removing console access for the user.

**Important**  
You can prevent an IAM user from accessing the AWS Management Console by removing their password. This prevents them from signing in to the AWS Management Console using their sign-in credentials. It does not change their permissions or prevent them from accessing the console using an assumed role. If the user has active access keys, they continue to function and allow access through the AWS CLI, Tools for Windows PowerShell, AWS API, or the AWS Console Mobile Application.

------
#### [ Console ]

1. Follow the sign-in procedure appropriate to your user type as described in the topic [How to sign in to AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

1. On the **IAM Console Home** page, in the left navigation pane, enter your query in the **Search IAM** text box.

1. In the navigation pane, choose **Users**.

1. Choose the name of the user whose password you want to delete. 

1. Choose the **Security credentials** tab, and then under **Console sign-in**, choose **Manage console access**.

1. To require the user to stop using the console immediately, select **Revoke active console sessions**. This attaches an inline policy to the IAM user that denies the user access to resources if their credentials are older than the time specified by the policy.

1. Choose **Disable access**

The console displays a status message informing you that console access has been disabled.

------

### Creating, changing, or deleting an IAM user password (AWS CLI)
<a name="Using_ManagingPasswordsCLIAPI"></a>

You can use the AWS CLI API to manage passwords for your IAM users.

**To create a password (AWS CLI)**

1. (Optional) To determine whether a user has a password, run this command: [aws iam get-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/get-login-profile.html)

1. To create a password, run this command: [aws iam create-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/create-login-profile.html)

**To change a user's password (AWS CLI)**

1. (Optional) To determine whether a user has a password, run this command: [aws iam get-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/get-login-profile.html)

1. To change a password, run this command: [aws iam update-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/update-login-profile.html)

**To delete (disable) a user's password (AWS CLI)**

1. (Optional) To determine whether a user has a password, run this command: [aws iam get-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/get-login-profile.html)

1. (Optional) To determine when a password was last used, run this command: [aws iam get-user](https://docs.aws.amazon.com/cli/latest/reference/iam/get-user.html)

1. To delete a password, run this command: [aws iam delete-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-login-profile.html)

**Important**  
When you delete a user's password, the user can no longer sign in to the AWS Management Console. If the user has active access keys, they continue to function and allow access through the AWS CLI, Tools for Windows PowerShell, or AWS API function calls. When you use the AWS CLI, Tools for Windows PowerShell, or AWS API to delete a user from your AWS account, you must first delete the password using this operation. For more information, see [Deleting an IAM user (AWS CLI)](id_users_remove.md#id_users_deleting_cli). 

**To revoke a user's active console sessions before a specified time (AWS CLI)**

1. To embed an inline policy that revokes an IAM user's active console sessions before a specified time, use the following inline policy and run this command: [aws iam put-user-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-user-policy.html)

   This inline policy denies all permissions and includes the `aws:TokenIssueTime` condition key. It revokes the user's active console sessions before the specified time in the `Condition` element of the inline policy. Replace the `aws:TokenIssueTime` condition key value with your own value.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": {
       "Effect": "Deny",
       "Action": "*",
       "Resource": "*",
       "Condition": {
         "DateLessThan": {
           "aws:TokenIssueTime": "2014-05-07T23:47:00Z"
         }
       }
     }
   }
   ```

------

1. (Optional) To list the names of the inline policies embedded in the IAM user, run this command: [aws iam list-user-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-user-policies.html)

1. (Optional) To view the named inline policy embedded in the IAM user, run this command: [aws iam get-user-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/get-user-policy.html)

### Creating, changing, or deleting an IAM user password (AWS API)
<a name="Using_ManagingPasswordsAPI"></a>

You can use the AWS API to manage passwords for your IAM users.

**To create a password (AWS API)**

1. (Optional) To determine whether a user has a password, call this operation: [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html)

1. To create a password, call this operation: [CreateLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html)

**To change a user's password (AWS API)**

1. (Optional) To determine whether a user has a password, call this operation: [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html)

1. To change a password, call this operation: [UpdateLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateLoginProfile.html)

**To delete (disable) a user's password (AWS API)**

1. (Optional) To determine whether a user has a password, run this command: [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html)

1. (Optional) To determine when a password was last used, run this command: [GetUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html)

1. To delete a password, run this command: [DeleteLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteLoginProfile.html)

**Important**  
When you delete a user's password, the user can no longer sign in to the AWS Management Console. If the user has active access keys, they continue to function and allow access through the AWS CLI, Tools for Windows PowerShell, or AWS API function calls. When you use the AWS CLI, Tools for Windows PowerShell, or AWS API to delete a user from your AWS account, you must first delete the password using this operation. For more information, see [Deleting an IAM user (AWS CLI)](id_users_remove.md#id_users_deleting_cli). 

**To revoke a user's active console sessions before a specified time (AWS API)**

1. To embed an inline policy that revokes an IAM user's active console sessions before a specified time, use the following inline policy and run this command: [PutUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutUserPolicy.html)

   This inline policy denies all permissions and includes the `aws:TokenIssueTime` condition key. It revokes the user's active console sessions before the specified time in the `Condition` element of the inline policy. Replace the `aws:TokenIssueTime` condition key value with your own value.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": {
       "Effect": "Deny",
       "Action": "*",
       "Resource": "*",
       "Condition": {
         "DateLessThan": {
           "aws:TokenIssueTime": "2014-05-07T23:47:00Z"
         }
       }
     }
   }
   ```

------

1. (Optional) To list the names of the inline policies embedded in the IAM user, run this command: [ListUserPolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUserPolicies.html)

1. (Optional) To view the named inline policy embedded in the IAM user, run this command: [GetUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUserPolicy.html)

# Permit IAM users to change their own passwords
<a name="id_credentials_passwords_enable-user-change"></a>

**Note**  
Users with federated identities will use the process defined by their identity provider to change their passwords. As a [best practice](best-practices.md), require human users to use federation with an identity provider to access AWS using temporary credentials.

You can grant IAM users the permission to change their own passwords for signing in to the AWS Management Console. You can do this in one of two ways:
+ [Allow all IAM users in the account to change their own passwords](#proc_letalluserschangepassword). 
+ [Allow only selected IAM users to change their own passwords](#proc_letselectuserschangepassword). In this scenario, you disable the option for all users to change their own passwords and you use an IAM policy to grant permissions to only some users. This approach allows those users to change their own passwords and optionally other credentials like their own access keys. 

**Important**  
We recommend that you [set a custom password policy](id_credentials_passwords_account-policy.md) that requires IAM users to create strong passwords.

## To allow all IAM users change their own passwords
<a name="proc_letalluserschangepassword"></a>

------
#### [ Console ]

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, click **Account settings**.

1. In the **Password policy** section, choose **Edit**.

1. Choose **Custom** to use a custom password policy.

1. Select **Allow users to change their own password**, and then choose **Save changes**. This allows all users in the account access to the `iam:ChangePassword` action for only their user and to the `iam:GetAccountPasswordPolicy` action.

1. Provide users with the following instructions for changing their passwords: [How an IAM user changes their own password](id_credentials_passwords_user-change-own.md). 

------
#### [ AWS CLI ]

Run the following command:
+ `[aws iam update-account-password-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/update-account-password-policy.html)`

------
#### [ API ]

To update the account password policy, call the following operation:
+ `[UpdateAccountPasswordPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccountPasswordPolicy.html)` 

------

## To allow selected IAM users change their own passwords
<a name="proc_letselectuserschangepassword"></a>

------
#### [ Console ]

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, click **Account settings**. 

1. In the **Password policy** section, make sure that **Allow users to change their own password** is not selected. If this checkbox is selected, all users can change their own passwords. (See the previous procedure.) 

1. Create the users who should be allowed to change their own password, if they do not already exist. For details, see [Create an IAM user in your AWS account](id_users_create.md). 

1. (Optional) Create an IAM group for the users who should be allowed to change their passwords, and then add the users from the previous step to the group. For details, see [IAM user groups](id_groups.md). 

1. Assign the following policy to the group. For more information, see [Manage IAM policies](access_policies_manage.md).

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "iam:GetAccountPasswordPolicy",
         "Resource": "*"
       },
       {
         "Effect": "Allow",
         "Action": "iam:ChangePassword",
         "Resource": "arn:aws:iam::*:user/${aws:username}"
       }
     ]
   }
   ```

------

   This policy grants access to the [ChangePassword](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ChangePassword.html) action, which lets users change only their own passwords from the console, the AWS CLI, Tools for Windows PowerShell, or the API. It also grants access to the [GetAccountPasswordPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountPasswordPolicy.html) action, which lets the user view the current password policy; this permission is required so that the user can view the account password policy on the **Change password** page. The user must be allowed to read the current password policy to ensure that the changed password meets the requirements of the policy.

1. Provide users with the following instructions for changing their passwords: [How an IAM user changes their own password](id_credentials_passwords_user-change-own.md). 

------

### For more information
<a name="HowToPwdIAMUser-moreinfo"></a>

For more information on managing credentials, see the following topics:
+ [Permit IAM users to change their own passwords](#id_credentials_passwords_enable-user-change) 
+ [User passwords in AWS](id_credentials_passwords.md)
+ [Set an account password policy for IAM users](id_credentials_passwords_account-policy.md)
+ [Manage IAM policies](access_policies_manage.md)
+ [How an IAM user changes their own password](id_credentials_passwords_user-change-own.md)

# How an IAM user changes their own password
<a name="id_credentials_passwords_user-change-own"></a>

If you have been granted permission to change your own IAM user password, you can use a special page in the AWS Management Console to do this. You can also use the AWS CLI or AWS API.

**Topics**
+ [

## Permissions required
](#change-own-passwords-permissions-required)
+ [

## How IAM users change their own password (console)
](#ManagingUserPwdSelf-Console)
+ [

## How IAM users change their own password (AWS CLI or AWS API)
](#ManagingUserPwdSelf-CLIAPI)

## Permissions required
<a name="change-own-passwords-permissions-required"></a>

To change the password for your own IAM user, you must have the permissions from the following policy: [AWS: Allows IAM users to change their own console password on the Security credentials page](reference_policies_examples_aws_my-sec-creds-self-manage-password-only.md).

## How IAM users change their own password (console)
<a name="ManagingUserPwdSelf-Console"></a>

The following procedure describes how IAM users can use the AWS Management Console to change their own password.

**To change your own IAM user password (console)**

1. Use your AWS account ID or account alias, your IAM user name, and your password to sign in to the [IAM console](https://console.aws.amazon.com/iam).
**Note**  
For your convenience, the AWS sign-in page uses a browser cookie to remember your IAM user name and account information. If you previously signed in as a different user, choose **Sign in to a different account** near the bottom of the page to return to the main sign-in page. From there, you can type your AWS account ID or account alias to be redirected to the IAM user sign-in page for your account.

   To get your AWS account ID, contact your administrator.

1. In the navigation bar on the upper right, choose your user name, and then choose **Security credentials**.   
![\[AWS Management Console Security credentials link\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. On the **AWS IAM credentials** tab, choose **Update password**.

1. For **Current password**, enter your current password. Enter a new password for **New password** and **Confirm new password**. Then choose **Update password**.
**Note**  
The new password must meet the requirements of the account password policy. For more information, see [Set an account password policy for IAM users](id_credentials_passwords_account-policy.md). 

## How IAM users change their own password (AWS CLI or AWS API)
<a name="ManagingUserPwdSelf-CLIAPI"></a>

The following procedure describes how IAM users can use the AWS CLI or AWS API to change their own password.

**To change your own IAM password, use the following:**
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/change-password.html](https://docs.aws.amazon.com/cli/latest/reference/iam/change-password.html)
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ChangePassword.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ChangePassword.html)

# Manage access keys for IAM users
<a name="id_credentials_access-keys"></a>

**Important**  
As a [best practice](best-practices.md), use temporary security credentials (such as IAM roles) instead of creating long-term credentials like access keys. Before creating access keys, review the [alternatives to long-term access keys](security-creds-programmatic-access.md#security-creds-alternatives-to-long-term-access-keys).

Access keys are long-term credentials for an IAM user or the AWS account root user. You can use access keys to sign programmatic requests to the AWS CLI or AWS API (directly or using the AWS SDK). For more information, see [Programmatic access with AWS security credentials](security-creds-programmatic-access.md).

Access keys consist of two parts: an access key ID (for example, `AKIAIOSFODNN7EXAMPLE`) and a secret access key (for example, `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`). You must use both the access key ID and secret access key together to authenticate your requests.



When you create an access key pair, save the access key ID and secret access key in a secure location. The secret access key can be retrieved only at the time you create it. If you lose your secret access key, you must delete the access key and create a new one. For more instructions, see [Update access keys](id-credentials-access-keys-update.md).

You can have a maximum of two access keys per user.

**Important**  
IAM users with access keys are an account security risk. Manage your access keys securely. Do not provide your access keys to unauthorized parties, even to help [find your account identifiers](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html). By doing this, you might give someone permanent access to your account.  
When working with access keys, be aware of the following:  
**Do NOT** use your account's root credentials to create access keys.
**Do NOT** put access keys or credential information in your application files. 
**Do NOT** include files that contain access keys or credential information in your project area.
Access keys or credential information stored in the shared AWS credentials file are stored in plaintext.

## Monitoring recommendations
<a name="monitor-access-keys"></a>

After creating access keys:
+ Use AWS CloudTrail to monitor access key usage and detect any unauthorized access attempts. For more information, see [Logging IAM and AWS STS API calls with AWS CloudTrail](cloudtrail-integration.md).
+ Set up CloudWatch alarms to notify administrators for denied access attempts to help detect malicious activities. For more information, see the [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
+ Regularly review, update, and delete access keys as needed.

The following topics detail management tasks associated with access keys.

**Topics**
+ [

## Monitoring recommendations
](#monitor-access-keys)
+ [

# Control the use of access keys by attaching an inline policy to an IAM user
](access-keys_inline-policy.md)
+ [

# Permissions required to manage access keys
](access-keys_required-permissions.md)
+ [

# How IAM users can manage their own access keys
](access-key-self-managed.md)
+ [

# How an IAM administrator can manage IAM user access keys
](access-keys-admin-managed.md)
+ [

# Update access keys
](id-credentials-access-keys-update.md)
+ [

# Secure access keys
](securing_access-keys.md)

# Control the use of access keys by attaching an inline policy to an IAM user
<a name="access-keys_inline-policy"></a>

As a best practice we recommend that [workloads use temporary credentials with IAM roles](best-practices.md#bp-workloads-use-roles) to access AWS. IAM users with access keys should be assigned least privilege access and have [multi-factor authentication (MFA)](id_credentials_mfa.md) enabled. For more information about assuming IAM roles, see [Methods to assume a role](id_roles_manage-assume.md).

However, if you're creating a proof of concept test of a service automation or other short-term use case, and you choose to run workloads using an IAM user with access keys we recommend that you [use policies conditions to further restrict access](best-practices.md#use-policy-conditions) of their IAM user credentials.

In this situation you can either create a time-bound policy that expires the credentials after the specified time or, if you are running a workload from a secure network, you can use an IP restriction policy.

For both these use cases, you can use an inline policy that's attached to the IAM user that has access keys.

**To configure a time-bound policy for an IAM user**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users** and then select the user for the short-term use case. If you haven't created the user yet, you can [create the user](getting-started-workloads.md) now.

1. On the user **Details** page, choose the **Permissions** tab.

1. Choose **Add permissions** and then select **Create inline policy**.

1. In the **Policy editor** section, select **JSON** to display the JSON editor.

1. In the JSON editor, enter the following policy, replacing the value for the `aws:CurrentTime` timestamp with your desired expiration date and time:

------
#### [ JSON ]

****  

   ```
   {
   "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Deny",
         "Action": "*",
         "Resource": "*",
         "Condition": {
         "DateGreaterThan": {
         "aws:CurrentTime": "2025-03-01T00:12:00Z"
           }
         }
       }
     ]
   }
   ```

------

   This policy uses the `Deny` effect to restrict all actions on all resources after the specified date. The `DateGreaterThan` condition compares the current time with the timestamp you set.

1. Select **Next** to proceed to the **Review and create** page. In **Policy** details, under **Policy name** enter a name for the policy and then choose **Create policy**.

After the policy is created, it's displayed on the **Permissions** tab for the user. When the current time is greater than or equal to the time specified in the policy, the user will no longer have access to AWS resources. Make sure to inform workload developers of the expiration date you specified for these access keys. 

**To configure an IP restriction policy for an IAM user**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users** and then select the user that will run the workload from the secure network. If you haven't created the user yet, you can [create the user](getting-started-workloads.md) now.

1. On the user **Details** page, choose the **Permissions** tab.

1. Choose **Add permissions** and then select **Create inline policy**.

1. In the **Policy editor** section, select **JSON** to display the JSON editor.

1. Copy the following IAM policy into the JSON editor, and change the public IPv4 or IPv6 addresses, or ranges to your needs. You can use [https://checkip.amazonaws.com/](https://checkip.amazonaws.com/) to determine your current public IP address. You can specify individual IP addresses, or ranges of IP addresses using slash notation. For more information, see [aws:SourceIp](reference_policies_condition-keys.md#condition-keys-sourceip). 
**Note**  
The IP addresses must not be obfuscated by a VPN or a proxy server.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Sid":"IpRestrictionIAMPolicyForIAMUser",
         "Effect": "Deny",
         "Action": "*",
         "Resource": "*",
         "Condition": {
           "NotIpAddress": {
             "aws:SourceIp": [
               "203.0.113.0/24",
               "2001:DB8:1234:5678::/64",
               "203.0.114.1"
             ]
           },
           "BoolIfExists": {
             "aws:ViaAWSService": "false"
           }
         }
       }
     ]
   }
   ```

------

   This policy example denies the use of an IAM user’s access keys with this policy applied, unless the request originated from the networks (specified in CIDR notation) “203.0.113.0/24”, “2001:DB8:1234:5678::/64”, or the specific IP address “203.0.114.1” 

1. Select **Next** to proceed to the **Review and create** page. In **Policy** details, under **Policy name** enter a name for the policy and then choose **Create policy**.

After the policy is created, it's displayed on the **Permissions** tab for the user. 

You could also apply this policy as a service control policy (SCP) across multiple AWS accounts in AWS Organizations, we recommend using an additional condition, `aws:PrincipalArn` to make this policy statement only apply to IAM users within the AWS accounts subject to this SCP. The following policy includes that update:

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "IpRestrictionServiceControlPolicyForIAMUsers",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "203.0.113.0/24",
            "2001:DB8:1234:5678::/64",
            "203.0.114.1"
          ]
        },
        "BoolIfExists": {
          "aws:ViaAWSService": "false"
        },
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:user/*"
        }
      }
    }
  ]
}
```

------

# Permissions required to manage access keys
<a name="access-keys_required-permissions"></a>

**Note**  
`iam:TagUser` is an optional permission for adding and editing descriptions for the access key. For more information, see [Tag IAM users](id_tags_users.md)

To create access keys for your own IAM user, you must have the permissions from the following policy:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "CreateOwnAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:CreateAccessKey",
                "iam:GetUser",
                "iam:ListAccessKeys",
                "iam:TagUser"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        }
    ]
}
```

------

To update access keys for your own IAM user, you must have the permissions from the following policy:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ManageOwnAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:CreateAccessKey",
                "iam:DeleteAccessKey",
                "iam:GetAccessKeyLastUsed",
                "iam:GetUser",
                "iam:ListAccessKeys",
                "iam:UpdateAccessKey",
                "iam:TagUser"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        }
    ]
}
```

------

# How IAM users can manage their own access keys
<a name="access-key-self-managed"></a>

IAM administrators can grant IAM users the permission to self-manage their access keys by attaching the policy described in [Permissions required to manage access keys](access-keys_required-permissions.md).

With these permissions, IAM user can use the following procedures to create, activate, deactivate, and delete the access keys associated with their username.

**Topics**
+ [

## Create an access key for yourself (console)
](#Using_CreateAccessKey)
+ [

## Deactivate your access key (console)
](#deactivate-access-key-seccreds)
+ [

## Activate your access key (console)
](#activate-access-key-seccreds)
+ [

## Delete your access key (console)
](#delete-access-key-seccreds)

## Create an access key for yourself (console)
<a name="Using_CreateAccessKey"></a>

If you have been granted the appropriate permissions you can use the AWS Management Console to create access keys for yourself.

**To create your own access keys (console)**

1. Use your AWS account ID or account alias, your IAM user name, and your password to sign in to the [IAM console](https://console.aws.amazon.com/iam).
**Note**  
For your convenience, the AWS sign-in page uses a browser cookie to remember your IAM user name and account information. If you previously signed in as a different user, choose **Sign in to a different account** near the bottom of the page to return to the main sign-in page. From there, you can type your AWS account ID or account alias to be redirected to the IAM user sign-in page for your account.

   To get your AWS account ID, contact your administrator.

1. In the navigation bar on the upper right, choose your user name, and then choose **Security credentials**.   
![\[AWS Management Console Security credentials link\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. In the **Access keys** section, choose **Create access key**. If you already have two access keys, this button is deactivated and you must delete an access key before you can create a new one.

1. On the **Access key best practices & alternatives** page, choose your use case to learn about additional options which can help you avoid creating a long-term access key. If you determine that your use case still requires an access key, choose **Other** and then choose **Next**.

1. (Optional) Set a description tag value for the access key. This adds a tag key-value pair to your IAM user. This can help you identify and update access keys later. The tag key is set to the access key id. The tag value is set to the access key description that you specify. When you are finished, choose **Create access key**.

1. On the **Retrieve access keys** page, choose either **Show** to reveal the value of your user's secret access key, or **Download .csv file**. This is your only opportunity to save your secret access key. After you've saved your secret access key in a secure location, choose **Done**.

## Deactivate your access key (console)
<a name="deactivate-access-key-seccreds"></a>

If you have been granted the appropriate permissions you can use the AWS Management Console to deactivate your access key.

**To deactivate an access key**

1. Use your AWS account ID or account alias, your IAM user name, and your password to sign in to the [IAM console](https://console.aws.amazon.com/iam).
**Note**  
For your convenience, the AWS sign-in page uses a browser cookie to remember your IAM user name and account information. If you previously signed in as a different user, choose **Sign in to a different account** near the bottom of the page to return to the main sign-in page. From there, you can type your AWS account ID or account alias to be redirected to the IAM user sign-in page for your account.

   To get your AWS account ID, contact your administrator.

1. In the navigation bar on the upper right, choose your user name, and then choose **Security credentials**.   
![\[AWS Management Console Security credentials link\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. In the **Access keys** section find the key you want to deactivate, then choose **Actions**, then choose **Deactivate**. When prompted for confirmation, choose **Deactivate**. A deactivated access key still counts toward your limit of two access keys.

## Activate your access key (console)
<a name="activate-access-key-seccreds"></a>

If you have been granted the appropriate permissions you can use the AWS Management Console to activate your access key.

**To activate an access key**

1. Use your AWS account ID or account alias, your IAM user name, and your password to sign in to the [IAM console](https://console.aws.amazon.com/iam).
**Note**  
For your convenience, the AWS sign-in page uses a browser cookie to remember your IAM user name and account information. If you previously signed in as a different user, choose **Sign in to a different account** near the bottom of the page to return to the main sign-in page. From there, you can type your AWS account ID or account alias to be redirected to the IAM user sign-in page for your account.

   To get your AWS account ID, contact your administrator.

1. In the navigation bar on the upper right, choose your user name, and then choose **Security credentials**.   
![\[AWS Management Console Security credentials link\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. In the **Access keys** section, find the key to activate, then choose **Actions**, then choose **Activate**.

## Delete your access key (console)
<a name="delete-access-key-seccreds"></a>

If you have been granted the appropriate permissions you can use the AWS Management Console to delete your access key.

**To delete an access key when you no longer need it**

1. Use your AWS account ID or account alias, your IAM user name, and your password to sign in to the [IAM console](https://console.aws.amazon.com/iam).
**Note**  
For your convenience, the AWS sign-in page uses a browser cookie to remember your IAM user name and account information. If you previously signed in as a different user, choose **Sign in to a different account** near the bottom of the page to return to the main sign-in page. From there, you can type your AWS account ID or account alias to be redirected to the IAM user sign-in page for your account.

   To get your AWS account ID, contact your administrator.

1. In the navigation bar on the upper right, choose your user name, and then choose **Security credentials**.   
![\[AWS Management Console Security credentials link\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. In the **Access keys** section, find the key you want to delete, then choose **Actions**, then choose **Delete**. Follow the instructions in the dialog to first **Deactivate** and then confirm the deletion. We recommend that you verify that the access key is no longer in use before you permanently delete it.

# How an IAM administrator can manage IAM user access keys
<a name="access-keys-admin-managed"></a>

IAM administrators can create, activate, deactivate, and delete the access keys associated with individual IAM users. They can also list the IAM users in the account which have access keys and locate which IAM user has a specific access key.

**Topics**
+ [

## To create an access key for an IAM user
](#admin-create-access-key)
+ [

## To deactivate an access key for an IAM user
](#admin-deactivate-access-key)
+ [

## To activate an access key for an IAM user
](#admin-activate-access-key)
+ [

## To delete an access key for an IAM user
](#admin-delete-access-key)
+ [

## To list the access keys for an IAM user
](#admin-list-access-key)
+ [

## To display all the access key IDs for users in your account
](#admin-list-all-access-keys)
+ [

## To use an access key ID to find a user
](#admin-find-user-access-keys)
+ [

## To find the most recent use of an access key ID
](#admin-find-most-recent-use-access-keys)

## To create an access key for an IAM user
<a name="admin-create-access-key"></a>

------
#### [ Console ]

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**.

1. Choose the user name to go to the user details page.

1. On **Security credentials** tab, in the **Access keys** section, choose **Create access key**.

   If the button is deactivated, then you must delete one of the existing keys before you can create a new one.

1. On the **Access key best practices & alternatives** page, review the best practices and alternatives. Choose your use case to learn about additional options which can help you avoid creating a long-term access key.

1. If you determine that your use case still requires an access key, choose **Other** and then choose **Next**.

1. **(Optional)** On the **Set description tag** page, you can add a description tag to the access key to help track your access key. Select **Create access key**.

1. On the **Retrieve access key page**, choose **Show** to reveal the value of your user's secret access key.

1. To save the access key ID and secret access key to a `.csv` file to a secure location on your computer, choose the **Download .csv file** button.
**Important**  
This is your only time to view or download the newly created access key and you cannot recover it. Make sure you securely maintain your access key.

When you create an access key for your user, that key pair is active by default, and your user can use the pair right away.

------
#### [ AWS CLI ]

Run the following command:
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html)

------
#### [ API ]

Call the following operation:
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html) 

------

## To deactivate an access key for an IAM user
<a name="admin-deactivate-access-key"></a>

------
#### [ Console ]

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**.

1. Choose the user name to go to the user details page.

1. On **Security credentials** tab, in the **Access keys** section, choose the **Actions** drop-down menu, then choose **Deactivate**.

1. In the **Deactivate** dialog box, confirm that you want to deactivate the access key by selecting **Deactivate**

After an access key is deactivated, it can no longer be used by API calls. You can activate it again if needed.

------
#### [ AWS CLI ]

Run the following command:
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html)

------
#### [ API ]

Call the following operation:
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html) 

------

## To activate an access key for an IAM user
<a name="admin-activate-access-key"></a>

------
#### [ Console ]

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**.

1. Choose the user name to go to the user details page.

1. On **Security credentials** tab, in the **Access keys** section, choose the **Actions** drop-down menu, then choose **Activate**.

After an access key is activated, it can be used by API calls. You can deactivate it again if needed.

------
#### [ AWS CLI ]

Run the following command:
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html)

------
#### [ API ]

Call the following operation:
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html) 

------

## To delete an access key for an IAM user
<a name="admin-delete-access-key"></a>

After an access key has been deactivated, if it is no longer required, delete it.

------
#### [ Console ]

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**.

1. Choose the user name to go to the user details page.

1. On **Security credentials** tab, in the **Access keys** section, choose the **Actions** drop-down menu for the inactive access key, then choose **Delete**.

1. In the **Delete** dialog box, confirm that you want to delete the access key by entering the access key ID in the text input field and then selecting **Delete**.

After an access key is deleted, it can't be recovered.

------
#### [ AWS CLI ]

Run the following command:
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)

------
#### [ API ]

Call the following operation:
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html) 

------

## To list the access keys for an IAM user
<a name="admin-list-access-key"></a>

You can view a list of the access key IDs associated with an IAM user. 

------
#### [ Console ]

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**.

1. Choose the user name to go to the user details page.

1. On **Security credentials** tab, the **Access keys** section lists the access key IDs for the user including the status of each key displayed.
**Note**  
Only the user's access key ID is visible. The secret access key can only be retrieved when the key is created.

Each IAM user can have two access keys.

------
#### [ AWS CLI ]

Run the following command:
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)

------
#### [ API ]

Call the following operation:
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html) 

------

## To display all the access key IDs for users in your account
<a name="admin-list-all-access-keys"></a>

You can view a list of the access key IDs for users in your AWS account. 

------
#### [ Console ]

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**.

1. Choose the user name to go to the user details page.

1. If necessary, add the **Access key ID** column to the users table by completing the following steps:

   1. Above the table on the far right, choose the **Preferences** icon (![\[Preferences icon\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/console-settings-icon.console.png)).

   1. In the **Preferences** dialog box, under **Select visible columns** turn on **Access key ID**.

   1. Choose **Confirm** to return to the list of users. The list is updated to include the access key ID.

1. The **Access key ID** column shows the state of each access key, followed by its ID; for example, **`Active - AKIAIOSFODNN7EXAMPLE`** or **`Inactive - AKIAI44QH8DHBEXAMPLE`**. 

   You can use this information to view and copy the access keys IDs for users with one or two access keys. The column displays **`-`** for users with no access key.
**Note**  
The secret access key can only be retrieved when the key is created.

Each IAM user can have two access keys.

------

## To use an access key ID to find a user
<a name="admin-find-user-access-keys"></a>

You can use an access key ID to find a user in your AWS account. 

------
#### [ Console ]

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, in the search box, enter the **Access key ID**, for example AKIAI44QH8DHBEXAMPLE. 

1. The IAM user that the access key ID is associated with appears in the navigation pane. Choose the user name to go to the user details page.

------

## To find the most recent use of an access key ID
<a name="admin-find-most-recent-use-access-keys"></a>

The most recent use of an access key is displayed in the user's list on the IAM users page, on the user detail page, and is part of the credential report. 

------
#### [ Console ]

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In users list, see the **Access key last used** column.

   If the column is not displayed, choose the **Preferences** icon (![\[Preferences icon\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/console-settings-icon.console.png)) and under **Select visible columns** turn on **Access key last used** to display the column.

1. (optional) In the navigation pane, under **Access reports**, select **Credential report** to download a report that includes the access key last used information for all of the IAM users in your account.

1. (optional) Select the IAM user to view the user details. The **Summary** section includes the access key IDs, their status, and when they were last used.

------
#### [ AWS CLI ]

Run the following command:
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)

------
#### [ API ]

Call the following operation:
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html) 

------

# Update access keys
<a name="id-credentials-access-keys-update"></a>

As a security [best practice](best-practices.md#update-access-keys), we recommend that you update IAM user access keys when needed, such as when an employee leaves your company. IAM users can update their own access keys if they have been granted the necessary permissions.

For details about granting IAM users permissions to update their own access keys, see [AWS: Allows IAM users to manage their own password, access keys, and SSH public keys on the Security credentials page](reference_policies_examples_aws_my-sec-creds-self-manage-pass-accesskeys-ssh.md). You can also apply a password policy to your account to require that all of your IAM users periodically update their passwords and how often they must do so. For more information, see [Set an account password policy for IAM users](id_credentials_passwords_account-policy.md). 

**Note**  
If you lose your secret access key, you must delete the access key and create a new one. The secret access key can be retrieved only at the time you create it. Use this procedure to deactivate and then replace any lost access keys with new credentials.

**Topics**
+ [

## Updating IAM user access keys (console)
](#rotating_access_keys_console)
+ [

## Updating access keys (AWS CLI)
](#rotating_access_keys_cli)
+ [

## Updating access keys (AWS API)
](#rotating_access_keys_api)

## Updating IAM user access keys (console)
<a name="rotating_access_keys_console"></a>

You can update access keys from the AWS Management Console.

**To update access keys for an IAM user without interrupting your applications (console)**

1. While the first access key is still active, create a second access key.

   1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

   1. In the navigation pane, choose **Users**.

   1. Choose the name of the intended user, and then choose the **Security credentials** tab.

   1. In the **Access keys** section, choose **Create access key**. On the **Access key best practices & alternatives** page, choose **Other**, then choose **Next**.

   1. (Optional) Set a description tag value for the access key to add a tag key-value pair to this IAM user. This can help you identify and update access keys later. The tag key is set to the access key id. The tag value is set to the access key description that you specify. When you are finished, choose **Create access key**.

   1. On the **Retrieve access keys** page, choose either **Show** to reveal the value of your user's secret access key, or **Download .csv file**. This is your only opportunity to save your secret access key. After you've saved your secret access key in a secure location, choose **Done**.

      When you create an access key for your user, that key pair is active by default, and your user can use the pair right away. At this point, the user has two active access keys.

1. Update all applications and tools to use the new access key.

1. <a name="id_credentials_access-keys-key-still-in-use"></a>Determine whether the first access key is still in use by reviewing the **Last used** information for the oldest access key. One approach is to wait several days and then check the old access key for any use before proceeding.

1. Even if the **Last used** information indicates that the old key has never been used, we recommend that you do not immediately delete the first access key. Instead, choose **Actions** and then choose **Deactivate** to deactivate the first access key.

1. Use only the new access key to confirm that your applications are working. Any applications and tools that still use the original access key will stop working at this point because they no longer have access to AWS resources. If you find such an application or tool, you can reactivate the first access key. Then return to [Step 3](#id_credentials_access-keys-key-still-in-use) and update this application to use the new key.

1. After you wait some period of time to ensure that all applications and tools have been updated, you can delete the first access key:

   1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

   1. In the navigation pane, choose **Users**.

   1. Choose the name of the intended user, and then choose the **Security credentials** tab.

   1. In the **Access keys** section for the access key you want to delete, choose **Actions**, and then choose **Delete**. Follow the instructions in the dialog to first **Deactivate** and then confirm the deletion.

**To determine which access keys need to be updated or deleted (console)**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**.

1. If necessary, add the **Access key age** column to the users table by completing the following steps:

   1. Above the table on the far right, choose the settings icon (![\[Settings icon\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/console-settings-icon.console.png)).

   1. In **Manage columns**, select **Access key age**.

   1. Choose **Close** to return to the list of users.

1. The **Access key age** column shows the number of days since the oldest active access key was created. You can use this information to find users with access keys that might need to be updated or deleted. The column displays **None** for users with no access key.

## Updating access keys (AWS CLI)
<a name="rotating_access_keys_cli"></a>

You can update access keys from the AWS Command Line Interface.

**To update access keys without interrupting your applications (AWS CLI)**

1. While the first access key is still active, create a second access key, which is active by default. Run the following command:
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html)

     At this point, the user has two active access keys.

1. <a name="step-update-apps"></a>Update all applications and tools to use the new access key.

1. <a name="step-determine-use"></a>Determine whether the first access key is still in use by using this command:
   +  [https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)

   One approach is to wait several days and then check the old access key for any use before proceeding.

1. Even if step [Step 3](#step-determine-use) indicates no use of the old key, we recommend that you do not immediately delete the first access key. Instead, change the state of the first access key to `Inactive` using this command:
   +  [https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html)

1. Use only the new access key to confirm that your applications are working. Any applications and tools that still use the original access key will stop working at this point because they no longer have access to AWS resources. If you find such an application or tool, you can switch its state back to `Active` to reactivate the first access key. Then return to step [Step 2](#step-update-apps) and update this application to use the new key.

1. After you wait some period of time to ensure that all applications and tools have been updated, you can delete the first access key with this command:
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)

## Updating access keys (AWS API)
<a name="rotating_access_keys_api"></a>

You can update access keys using the AWS API.

**To update access keys without interrupting your applications (AWS API)**

1. While the first access key is still active, create a second access key, which is active by default. Call the following operation:
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html)

     At this point, the user has two active access keys.

1. <a name="step-update-apps-2"></a>Update all applications and tools to use the new access key.

1. <a name="step-determine-use-2"></a>Determine whether the first access key is still in use by calling this operation:
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html)

   One approach is to wait several days and then check the old access key for any use before proceeding.

1. Even if step [Step 3](#step-determine-use-2) indicates no use of the old key, we recommend that you do not immediately delete the first access key. Instead, change the state of the first access key to `Inactive` calling this operation:
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html)

1. Use only the new access key to confirm that your applications are working. Any applications and tools that still use the original access key will stop working at this point because they no longer have access to AWS resources. If you find such an application or tool, you can switch its state back to `Active` to reactivate the first access key. Then return to step [Step 2](#step-update-apps-2) and update this application to use the new key.

1. After you wait some period of time to ensure that all applications and tools have been updated, you can delete the first access key calling this operation:
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html)

# Secure access keys
<a name="securing_access-keys"></a>

Anyone who has your access keys has the same level of access to your AWS resources that you do. Consequently, AWS goes to significant lengths to protect your access keys, and, in keeping with our [shared-responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/), you should as well. 

Expand the following sections for guidance to help you protect your access keys. 

**Note**  
Your organization may have different security requirements and policies than those described in this topic. The suggestions provided here are intended as general guidelines. 

## Remove (or don't generate) AWS account root user access keys
<a name="root-password"></a>

**One of the best ways to protect your account is to not have access keys for your AWS account root user.** Unless you must have root user access keys (which is rare), it is best not to generate them. Instead, create an administrative user in AWS IAM Identity Center for daily administrative tasks.For information about how to create an administrative user in IAM Identity Center, see [Getting started](https://docs.aws.amazon.com//singlesignon/latest/userguide/getting-started.html) in the *IAM Identity Center User Guide*.

If you already have root user access keys for your account, we recommend the following: Find places in your applications where you are currently using access keys (if any), and replace the root user access keys with IAM user access keys. Then disable and remove the root user access keys. For more information about how to update access keys, see [Update access keys](id-credentials-access-keys-update.md)



## Use temporary security credentials (IAM roles) instead of long-term access keys
<a name="use-roles"></a>

In many scenarios, you don't need long-term access keys that never expire (as you have with an IAM user). Instead, you can create IAM roles and generate temporary security credentials. Temporary security credentials consist of an access key ID and a secret access key, but they also include a security token that indicates when the credentials expire. 

Long-term access keys, such as those associated with IAM users and the root user, remain valid until you manually revoke them. However, temporary security credentials obtained through IAM roles and other features of the AWS Security Token Service expire after a short period of time. Use temporary security credentials to help reduce your risk in case credentials are accidentally exposed.

Use an IAM role and temporary security credentials in these scenarios:
+ **You have an application or AWS CLI scripts running on an Amazon EC2 instance.** Don't use access keys directly in your application. Don't pass access keys to the application, embed them in the application, or let the application read access keys from any source. Instead, define an IAM role that has appropriate permissions for your application and launch the Amazon Elastic Compute Cloud (Amazon EC2) instance with [roles for EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html). Doing this associates an IAM role with the Amazon EC2 instance. This practice also enables the application to get temporary security credentials that it can in turn use to make programmatic calls to AWS. The AWS SDKs and the AWS Command Line Interface (AWS CLI) can get temporary credentials from the role automatically. 
+ **You need to grant cross-account access.** Use an IAM role to establish trust between accounts, and then grant users in one account limited permissions to access the trusted account. For more information, see [IAM tutorial: Delegate access across AWS accounts using IAM roles](tutorial_cross-account-with-roles.md).
+ **You have a mobile app.** Don't embed access keys with the app, even in encrypted storage. Instead, use [Amazon Cognito](https://aws.amazon.com/cognito/) to manage user identities in your app. This service lets you authenticate users using Login with Amazon, Facebook, Google, or any OpenID Connect (OIDC)–compatible identity provider. You can then use the Amazon Cognito credentials provider to manage credentials that your app uses to make requests to AWS.
+ **You want to federate into AWS and your organization supports SAML 2.0.** If you work for an organization that has an identity provider that supports SAML 2.0, configure the provider to use SAML. You can use SAML to exchange authentication information with AWS and get back a set of temporary security credentials. For more information, see [SAML 2.0 federation](id_roles_providers_saml.md).
+ **You want to federate into AWS and your organization has an on-premises identity store.** If users can authenticate inside your organization, you can write an application that can issue them temporary security credentials for access to AWS resources. For more information, see [Enable custom identity broker access to the AWS console](id_roles_providers_enable-console-custom-url.md).
+ **Use conditions in IAM policies to only allow access from expected networks.** You can limit where and how your access keys are used by implementing [IAM policies with conditions](reference_policies_elements_condition_operators.md) that specify and allow only expected networks, such as your public IP addresses or Virtual Private Clouds (VPCs). This way you know access keys can only be used from expected and acceptable networks. 

**Note**  
Are you using an Amazon EC2 instance with an application that requires programmatic access to AWS resources? If so, use [IAM roles for EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html).

## Manage IAM user access keys properly
<a name="iam-user-access-keys"></a>

If you must create access keys for programmatic access to AWS, create them for IAM users, granting the users only the permissions they require.

Observe these precautions to help protect IAM user access keys:
+ **Don't embed access keys directly into code.** The [AWS SDKs](https://aws.amazon.com/tools/#sdk) and the [AWS Command Line Tools](https://aws.amazon.com/tools/#cli) enable you to put access keys in known locations so that you don't have to keep them in code. 

  Put access keys in one of the following locations:
  + **The AWS credentials file.** The AWS SDKs and AWS CLI automatically use the credentials that you store in the AWS credentials file. 

    For information about using the AWS credentials file, see the documentation for your SDK. Examples include [Set AWS Credentials and Region](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/setup-credentials.html) in the *AWS SDK for Java Developer Guide* and [Configuration and credential files](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) in the *AWS Command Line Interface User Guide*.

    To store credentials for the AWS SDK for .NET and the AWS Tools for Windows PowerShell, we recommend that you use the SDK Store. For more information, see [Using the SDK Store](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/sdk-store.html) in the *AWS SDK for .NET Developer Guide*.
  + **Environment variables.** On a multi-tenant system, choose user environment variables, not system environment variables. 

    For more information about using environment variables to store credentials, see [Environment Variables](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html) in the *AWS Command Line Interface User Guide*. 
+ **Use different access keys for different applications.** Do this so that you can isolate the permissions and revoke the access keys for individual applications if they are exposed. Having separate access keys for different applications also generates distinct entries in [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) log files. This configuration makes it easier for you to determine which application performed specific actions. 
+ **Update access keys when needed.** If there is a risk that the access key could be compromised, update the access key and delete the previous access key. For details, see [Update access keys](id-credentials-access-keys-update.md) 
+ **Remove unused access keys.** If a user leaves your organization, remove the corresponding IAM user so that the user can no longer access your resources. To find out when an access key was last used, use the [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html) API (AWS CLI command: [https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)).
+ **Use temporary credentials and configure multi-factor authentication for your most sensitive API operations.** With IAM policies, you can specify which API operations a user is allowed to call. In some cases, you might want the additional security of requiring users to be authenticated with AWS MFA before you allow them to perform particularly sensitive actions. For example, you might have a policy that allows a user to perform the Amazon EC2 `RunInstances`, `DescribeInstances`, and `StopInstances` actions. But you might want to restrict a destructive action like `TerminateInstances` and ensure that users can perform that action only if they authenticate with an AWS MFA device. For more information, see [Secure API access with MFA](id_credentials_mfa_configure-api-require.md).

## Access the mobile app using AWS access keys
<a name="access-keys-mobile-app"></a>

You can access a limited set of AWS services and features using the AWS mobile app. The mobile app helps you support incident response while on the go. For more information and to download the app, see [AWS Console Mobile Application](https://aws.amazon.com/console/mobile/).

You can sign in to the mobile app using your console password or your access keys. As a best practice, do not use root user access keys. Instead, we strongly recommend that in addition to using a password or biometric lock on your mobile device, you create an IAM user specifically for managing AWS resources using the mobile app. If you lose your mobile device, you can remove the IAM user's access.

**To sign in using access keys (mobile app)**

1. Open the app on your mobile device.

1. If this is the first time that you're adding an identity to the device, choose **Add an identity** and then choose **Access keys**.

   If you have already signed in using another identity, choose the menu icon and choose **Switch identity**. Then choose **Sign in as a different identity** and then **Access keys**.

1. On the **Access keys** page, enter your information:
   + **Access key ID** – Enter your access key ID.
   + **Secret access key** – Enter your secret access key.
   + **Identity name** – Enter the name of the identity that will appear in the mobile app. This does not need to match your IAM user name.
   + **Identity PIN** – Create a personal identification number (PIN) that you will use for future sign-ins.
**Note**  
If you enable biometrics for the AWS mobile app, you will be prompted to use your fingerprint or facial recognition for verification instead of the PIN. If the biometrics fail, you might be prompted for the PIN instead.

1. Choose **Verify and add keys**.

   You can now access a select set of your resources using the mobile app.

## Related information
<a name="more-resources"></a>

The following topics provide guidance for setting up the AWS SDKs and the AWS CLI to use access keys:
+ [Set AWS credentials and Region](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/setup-credentials.html) in the *AWS SDK for Java Developer Guide*
+ [Using the SDK Store](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/sdk-store.html) in the *AWS SDK for .NET Developer Guide*
+ [Providing Credentials to the SDK](https://docs.aws.amazon.com/aws-sdk-php/v2/guide/credentials.html) in the *AWS SDK for PHP Developer Guide*
+ [Configuration](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html#configuration) in the Boto 3 (AWS SDK for Python) documentation
+ [Using AWS Credentials](https://docs.aws.amazon.com/powershell/latest/userguide/specifying-your-aws-credentials.html) in the *AWS Tools for Windows PowerShell User Guide* 
+ [Configuration and credential files](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) in the *AWS Command Line Interface User Guide* 
+ [Granting access using an IAM role](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-hosm.html) in the *AWS SDK for .NET Developer Guide*
+ [Configure IAM roles for Amazon EC2](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) in the *AWS SDK for Java 2.x*

## Using access keys and secret key credentials for console access
<a name="console-access-security-keys"></a>

It is possible to use access key and secret key credentials for direct AWS Management Console access, not just the AWS CLI. This can be achieved using the AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API call. By constructing a console URL using the temporary credentials and token provided by `GetFederationToken`, IAM principals can access the console. For more information, see [Enable custom identity broker access to the AWS console](id_roles_providers_enable-console-custom-url.md).

It is worth clarifying that when signing into the console directly using IAM or root user credentials with MFA enabled, MFA will be required. However, if the method described above (using temporary credentials with `GetFederationToken`) is used, MFA will NOT be required.



## Auditing access keys
<a name="Using_access-keys-audit"></a>

You can review the AWS access keys in your code to determine whether the keys are from an account that you own. You can pass an access key ID using the [https://docs.aws.amazon.com/cli/latest/reference/sts/get-access-key-info.html](https://docs.aws.amazon.com/cli/latest/reference/sts/get-access-key-info.html) AWS CLI command or the [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetAccessKeyInfo.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetAccessKeyInfo.html) AWS API operation.

The AWS CLI and AWS API operations return the ID of the AWS account to which the access key belongs. Access key IDs beginning with `AKIA` are long-term credentials for an IAM user or an AWS account root user. Access key IDs beginning with `ASIA` are temporary credentials that are created using AWS STS operations. If the account in the response belongs to you, you can sign in as the root user and review your root user access keys. Then, you can pull a [credentials report](id_credentials_getting-report.md) to learn which IAM user owns the keys. To learn who requested the temporary credentials for an `ASIA` access key, view the AWS STS events in your CloudTrail logs.

For security purposes, you can [review AWS CloudTrail logs](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) to learn who performed an action in AWS. You can use the `sts:SourceIdentity` condition key in the role trust policy to require users to specify an identity when they assume a role. For example, you can require that IAM users specify their own user name as their source identity. This can help you determine which user performed a specific action in AWS. For more information, see [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity).

This operation does not indicate the state of the access key. The key might be active, inactive, or deleted. Active keys might not have permissions to perform an operation. Providing a deleted access key might return an error that the key doesn't exist.

# AWS Multi-factor authentication in IAM
<a name="id_credentials_mfa"></a>

For increased security, we recommend that you configure multi-factor authentication (MFA) to help protect your AWS resources. You can enable MFA for the AWS account root user of all AWS accounts, including standalone accounts, management accounts, and member accounts, as well as for your IAM users. We recommend that you use phishing-resistant MFA such as passkeys and security keys whenever possible. These FIDO-based authenticators use public key cryptography and are resistant to phishing, man-in-the-middle, and replay attacks, providing a stronger level of security than TOTP-based options.

MFA is enforced for all account types for their root user. For more information, see [Secure your AWS Organizations account root user credentials](root-user-best-practices.md#ru-bp-organizations). 

When you enable MFA for the root user, it affects only the root user credentials. IAM users in the account are distinct identities with their own credentials, and each identity has its own MFA configuration. For more information about using MFA to protect the root user, see [Multi-factor authentication for AWS account root user](enable-mfa-for-root.md).

Your AWS account root user and IAM users can register up to eight MFA devices of any type. Registering multiple MFA devices can provide flexibility and help you reduce the risk of access interruption if a device is lost or broken. You only need one MFA device to sign in to the AWS Management Console or create a session through the AWS CLI.

**Note**  
We recommend that you require your human users to use temporary credentials when accessing AWS. Have you considered using AWS IAM Identity Center? You can use IAM Identity Center to centrally manage access to multiple AWS accounts and provide users with MFA-protected, single sign-on access to all their assigned accounts from one place. With IAM Identity Center, you can create and manage user identities in IAM Identity Center or easily connect to your existing SAML 2.0 compatible identity provider. For more information, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center User Guide*.

MFA adds extra security that requires users to provide unique authentication from an AWS supported MFA mechanism in addition to their sign-in credentials when they access AWS websites or services.

## MFA types
<a name="id_credentials_mfa-types"></a>

AWS supports the following MFA types:

**Contents**
+ [

### Passkeys and security keys
](#passkeys-security-keys-for-iam-users)
+ [

### Virtual authenticator applications
](#virtual-auth-apps-for-iam-users)
+ [

### Hardware TOTP tokens
](#hardware-totp-token-for-iam-users)

### Passkeys and security keys
<a name="passkeys-security-keys-for-iam-users"></a>

AWS Identity and Access Management supports passkeys and security keys for MFA. Based on FIDO standards, passkeys use public key cryptography to provide strong, phishing-resistant authentication that is more secure than passwords. AWS supports two types of passkeys: device-bound passkeys (security keys) and synced passkeys.
+ **Security keys**: These are physical devices, like a YubiKey, used as a second factor for authentication. A single security key can support multiple root user accounts and IAM users.
+ **Synced passkeys**: These use credential managers from providers such as Google, Apple, Microsoft accounts, and third-party services like 1Password, Dashlane, and Bitwarden as a second factor.

You can use built-in biometric authenticators, like Touch ID on Apple MacBooks, to unlock your credential manager and sign in to AWS. Passkeys are created with your chosen provider using your fingerprint, face, or device PIN. You can also use a cross-device authentication (CDA) passkey from one device, like a mobile device or hardware security key, to sign in on another device like a laptop. For more information, see [cross-device authentication](https://passkeys.dev/docs/reference/terms/#cross-device-authentication-cda) (CDA).

You can sync passkeys across your devices to facilitate sign-ins with AWS, enhancing usability and recoverability. For more information about enabling passkeys and security keys, see [Enable a passkey or security key for the root user (console)](enable-fido-mfa-for-root.md).

The FIDO Alliance maintains a list of all [FIDO Certified products](https://fidoalliance.org/certification/fido-certified-products/) that are compatible with FIDO specifications.

### Virtual authenticator applications
<a name="virtual-auth-apps-for-iam-users"></a>

A virtual authenticator application runs on a phone or other device and emulates a physical device. Virtual authenticator apps implement the [time-based one-time password (TOTP) algorithm](https://datatracker.ietf.org/doc/html/rfc6238) and support multiple tokens on a single device. The user must type a valid code from the device when prompted during sign-in. Each token assigned to a user must be unique. A user can't type a code from another user's token to authenticate.

We recommend that you use phishing-resistant MFA such as [passkeys or security keys](#passkeys-security-keys-for-iam-users) for the strongest protection. If you are not yet able to use passkeys or security keys, we recommend that you use a virtual MFA device as an interim measure while waiting for hardware purchase approval or while you wait for your hardware to arrive. For a list of a few supported apps that you can use as virtual MFA devices, see [Multi-Factor Authentication (MFA)](https://aws.amazon.com/iam/features/mfa/?audit=2019q1).

For instructions on setting up a virtual MFA device for an IAM user, see [Assign a virtual MFA device in the AWS Management Console](id_credentials_mfa_enable_virtual.md).

**Note**  
Unassigned virtual MFA devices in your AWS account are deleted when you’re adding new virtual MFA devices either via the AWS Management Console or during the sign-in process. Unassigned virtual MFA devices are devices in your account but not used by account root user or IAM users for the sign-in process. They’re deleted so new virtual MFA devices can be added to your account. It also allows you to reuse device names.  
To view unassigned virtual MFA devices in your account, you can use either the [list-virtual-mfa-devices](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-virtual-mfa-devices.html) AWS CLI command or [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html) call.
To deactivate a virtual MFA device, you can use either the [deactivate-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html) AWS CLI command or [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html) call. The device will become unassigned.
To attach an unassigned virtual MFA device to your AWS account root user or IAM users, you'll need the authentication code generated by the device along with either the [enable-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/enable-mfa-device.html) AWS CLI command or [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) call.

### Hardware TOTP tokens
<a name="hardware-totp-token-for-iam-users"></a>

A hardware device generates a six-digit numeric code based on the [time-based one-time password (TOTP) algorithm](https://datatracker.ietf.org/doc/html/rfc6238). The user must type a valid code from the device on a second webpage during sign-in.

These tokens are used exclusively with AWS accounts. You can only use tokens that have their unique token seeds shared securely with AWS. Token seeds are secret keys generated at the time of token production. Tokens purchased from other sources will not function with IAM. To ensure compatibility, you must purchase your hardware MFA device from one of the following links: [OTP token](https://www.amazon.com/SafeNet-IDProve-Time-based-6-Digit-Services/dp/B002CRN5X8) or [OTP display card](https://www.amazon.com/SafeNet-IDProve-Card-Amazon-Services/dp/B00J4NGUO4).
+ Each MFA device assigned to a user must be unique. A user cannot type a code from another user's device to be authenticated. For information on supported hardware MFA devices, see [Multi-Factor Authentication (MFA)](https://aws.amazon.com/iam/features/mfa/?audit=2019q1).
+ If you want to use a physical MFA device, we recommend that you use security keys as an alternative to hardware TOTP devices. Security keys have no battery requirements, are phishing resistant, and support multiple users on a single device.

You can enable a passkey or security key from the AWS Management Console only, not from the AWS CLI or AWS API. Before you can enable a security key, you must have physical access to the device.

For instructions on setting up a hardware TOTP token for an IAM user, see [Assign a hardware TOTP token in the AWS Management Console](id_credentials_mfa_enable_physical.md).

**Note**  
**SMS text message-based MFA** – AWS ended support for enabling SMS multi-factor authentication (MFA). We recommend that customers who have IAM users that use SMS text message-based MFA switch to one of the following alternative methods: [Passkey or security key](id_credentials_mfa_enable_fido.md), [virtual (software-based) MFA device](id_credentials_mfa_enable_virtual.md), or [hardware MFA device](id_credentials_mfa_enable_physical.md). You can identify the users in your account with an assigned SMS MFA device. In the IAM console, choose **Users** from the navigation pane, and look for users with **SMS** in the **MFA** column of the table.

## MFA recommendations
<a name="id_credentials_mfa-recommendations"></a>

To help secure your AWS identities, follow these recommendations for MFA authentication. 
+ We recommend that you use phishing-resistant MFA, such as [passkeys and security keys](#passkeys-security-keys-for-iam-users), as your MFA device. These FIDO-based authenticators provide the strongest protection against attacks such as phishing.
+ We recommend that you enable multiple MFA devices to the AWS account root user and IAM users in your AWS accounts. This allows you to raise the security bar in your AWS accounts and simplify managing access to highly privileged users, such as the AWS account root user.
+ You can register up to **eight** MFA devices of any combination of the [ currently supported MFA types](https://aws.amazon.com/iam/features/mfa/) with your AWS account root user and IAM users. With multiple MFA devices, you only need one MFA device to sign in to the AWS Management Console or create a session through the AWS CLI as that user. An IAM user must authenticate with an existing MFA device to enable or disable an additional MFA device.
+ In the event of a lost, stolen, or inaccessible MFA device you can use one of the remaining MFA devices to access the AWS account without performing the AWS account recovery procedure. If an MFA device is lost or stolen, it should be disassociated from the IAM principal with which it is associated.
+ The use of multiple MFAs allows your employees in geographically dispersed locations or working remotely to use hardware-based MFA to access AWS without having to coordinate the physical exchange of a single hardware device between employees.
+ The use of additional MFA devices for IAM principals allows you to use one or more MFAs for everyday usage, while also maintaining physical MFA devices in a secure physical location such as a vault or safe for backup and redundancy.

**Notes**  
You cannot pass the MFA information for a security key or passkey to AWS STS API operations to request temporary credentials. You can obtain credentials for use with the AWS CLI and AWS SDKs when using a security key or passkey by running the `aws login` command.
You cannot use AWS CLI commands or AWS API operations to enable [FIDO security keys](id_credentials_mfa_enable_fido.md).
You cannot use the same name for more than one root user or IAM MFA device.

## Additional resources
<a name="id_credentials_mfa-resources"></a>

The following resources can help you learn more about MFA.
+ For more information about using MFA to access AWS, see [MFA enabled sign-in](console_sign-in-mfa.md).
+  You can leverage IAM Identity Center to enable secure MFA access to your AWS access portal, IAM Identity Center integrated apps, and the AWS CLI. For more information, see [Enable MFA in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-getting-started.html).

# Assign a passkey or security key in the AWS Management Console
<a name="id_credentials_mfa_enable_fido"></a>

Passkeys are a type of [multi-factor authentication (MFA) device](id_credentials_mfa.md) that you can use to protect your AWS resources. AWS supports synced passkeys and device-bound passkeys also known as security keys. 

Synced passkeys allow IAM users to access their FIDO sign-in credentials on many of their devices, even new ones, without having to re-enroll every device on every account. Synced passkeys include first-party credential managers like Google, Apple, and Microsoft and third-party credential managers such as 1Password, Dashlane, and Bitwarden as a second factor. You can also use on-device biometrics (e.g., TouchID, FaceID) to unlock your chosen credential manager to use passkeys. 

Alternatively, device-bound passkeys are bound to a FIDO security key that you plug into a USB port on your computer and then tap when prompted to securely complete the sign-in process. If you already use a FIDO security key with other services, and it has an [AWS supported configuration](id_credentials_mfa_fido_supported_configurations.md) (for example, the YubiKey 5 Series from Yubico), you can also use it with AWS. Otherwise, you need to purchase a FIDO security key if you want to use WebAuthn for MFA in AWS. Additionally, FIDO security keys can support multiple IAM or root users on the same device, enhancing their utility for account security. For specifications and purchase information for both device types, see [Multi-Factor Authentication](http://aws.amazon.com/iam/details/mfa/).

You can register up to **eight** MFA devices of any combination of the [currently supported MFA types](https://aws.amazon.com/iam/features/mfa/) with your AWS account root user and IAM users. With multiple MFA devices, you only need one MFA device to sign in to the AWS Management Console or create a session through the AWS CLI as that user. We recommend that you register multiple MFA devices. For example, you can register a built-in authenticator and also register a security key that you keep in a physically secure location. If you’re unable to use your built-in authenticator, then you can use your registered security key. For authenticator applications, we also recommend enabling the cloud backup or sync feature in those apps to help you avoid losing access to your account if you lose or break your device with the authenticator apps.

**Note**  
We recommend that you require your human users to use temporary credentials when accessing AWS. Your users can federate into AWS with an identity provider where they authenticate with their corporate credentials and MFA configurations. To manage access to AWS and business applications, we recommend that you use IAM Identity Center. For more information, see the [IAM Identity Center User Guide](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html). 

**Topics**
+ [

## Permissions required
](#enable-fido-mfa-for-iam-user-permissions-required)
+ [

## Enable a passkey or security key for your own IAM user (console)
](#enable-fido-mfa-for-own-iam-user)
+ [

## Enable a passkey or security key for another IAM user (console)
](#enable-fido-mfa-for-iam-user)
+ [

## Replace a passkey or security key
](#replace-fido-mfa)
+ [

# Supported configurations for using passkeys and security keys
](id_credentials_mfa_fido_supported_configurations.md)

## Permissions required
<a name="enable-fido-mfa-for-iam-user-permissions-required"></a>

To manage a FIDO passkey for your own IAM user while protecting sensitive MFA-related actions, you must have the permissions from the following policy:

**Note**  
The ARN values are static values and are not an indicator of what protocol was used to register the authenticator. We have deprecated U2F, so all new implementations use WebAuthn.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowManageOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice",
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "DenyAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}
```

------

## Enable a passkey or security key for your own IAM user (console)
<a name="enable-fido-mfa-for-own-iam-user"></a>

You can enable a passkey or security key for your own IAM user from the AWS Management Console only, not from the AWS CLI or AWS API. Before you can enable a security key, you must have physical access to the device.

**To enable a passkey or security key for your own IAM user (console)**

1. Use your AWS account ID or account alias, your IAM user name, and your password to sign in to the [IAM console](https://console.aws.amazon.com/iam).
**Note**  
For your convenience, the AWS sign-in page uses a browser cookie to remember your IAM user name and account information. If you previously signed in as a different user, choose **Sign in to a different account** near the bottom of the page to return to the main sign-in page. From there, you can type your AWS account ID or account alias to be redirected to the IAM user sign-in page for your account.

   To get your AWS account ID, contact your administrator.

1. In the navigation bar on the upper right, choose your user name, and then choose **Security credentials**.   
![\[AWS Management Console Security credentials link\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. On the selected IAM user's page, choose the **Security credentials** tab.

1. Under **Multi-factor authentication (MFA)**, choose **Assign MFA device**.

1. On the **MFA device name** page, enter a **Device name**, choose **Passkey or Security Key**, and then choose **Next**.

1. On **Set up device**, set up your passkey. Create a passkey with biometric data like your face or fingerprint, with a device pin, or by inserting the FIDO security key into your computer's USB port and tapping it.

1. Follow the instructions on your browser and then choose **Continue**.

You have now registered your passkey or security key for use with AWS. For information about using MFA with the AWS Management Console, see [MFA enabled sign-in](console_sign-in-mfa.md). 

## Enable a passkey or security key for another IAM user (console)
<a name="enable-fido-mfa-for-iam-user"></a>

You can enable a passkey or security key for another IAM user from the AWS Management Console only, not from the AWS CLI or AWS API.

**To enable a passkey or security key for another IAM user (console)**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**.

1. Under **Users**, choose the name of the user for whom you want to enable MFA.

1. On the selected IAM user page, choose the **Security Credentials** tab. 

1. Under **Multi-factor authentication (MFA)**, choose **Assign MFA device**.

1. On the **MFA device name** page, enter a **Device name**, choose **Passkey or Security Key**, and then choose **Next**.

1. On **Set up device**, set up your passkey. Create a passkey with biometric data like your face or fingerprint, with a device pin, or by inserting the FIDO security key into your computer's USB port and tapping it.

1. Follow the instructions on your browser and then choose **Continue**.

You have now registered a passkey or security key for another IAM user to use with AWS. For information about using MFA with the AWS Management Console, see [MFA enabled sign-in](console_sign-in-mfa.md).

## Replace a passkey or security key
<a name="replace-fido-mfa"></a>

You can have up to eight MFA devices of any combination of the [ currently supported MFA types](https://aws.amazon.com/iam/features/mfa/) assigned to a user at a time with your AWS account root user and IAM users. If the user loses a FIDO authenticator or needs to replace it for any reason, you must first deactivate the old FIDO authenticator. Then you can add a new MFA device for the user.
+ To deactivate the device currently associated with an IAM user, see [Deactivate an MFA device](id_credentials_mfa_disable.md).
+ To add a new FIDO security key for an IAM user, see [Enable a passkey or security key for your own IAM user (console)](#enable-fido-mfa-for-own-iam-user).

If you don't have access to a new passkey or security key, you can enable a new virtual MFA device or hardware TOTP token. See one of the following for instructions:
+ [Assign a virtual MFA device in the AWS Management Console](id_credentials_mfa_enable_virtual.md) 
+ [Assign a hardware TOTP token in the AWS Management Console](id_credentials_mfa_enable_physical.md) 

# Supported configurations for using passkeys and security keys
<a name="id_credentials_mfa_fido_supported_configurations"></a>

You can use FIDO2 device-bound passkeys, also known as security keys, as a multi-factor authentication (MFA) method with IAM using currently supported configurations. These include FIDO2 devices supported by IAM and browsers that support FIDO2. Before you register your FIDO2 device, check that you’re using the latest browser and operating system (OS) version. Features may behave differently across different browsers, authenticators, and OS clients. If your device registration fails on one browser, you can try to register with another browser. 

FIDO2 is an open authentication standard and an extension of FIDO U2F, offering the same high level of security based on public key cryptography. FIDO2 consists of the W3C Web Authentication specification (WebAuthn API) and the FIDO Alliance Client-to-Authenticator Protocol (CTAP), an application layer protocol. CTAP enables communication between client or platform, like a browser or operating system, with an external authenticator. When you enable a FIDO Certified authenticator in AWS, the security key creates a new key pair for use with only AWS. First, you enter your credentials. When prompted, you tap the security key, which responds to the authentication challenge issued by AWS. To learn more about the FIDO2 standard, see the [FIDO2 Project](https://en.wikipedia.org/wiki/FIDO2_Project).

## FIDO2 devices supported by AWS
<a name="id_credentials_mfa_fido_supported_devices"></a>

IAM supports FIDO2 security devices that connect to your devices through USB, Bluetooth, or NFC. IAM also supports platform authenticators such as TouchID or FaceID. IAM does not support local passkey registration for Windows Hello. To create and use passkeys, Windows users should use [cross-device authentication](https://passkeys.dev/docs/reference/terms/#cross-device-authentication-cda) where you use a passkey from one device like a mobile device or hardware security key to sign in on another device like a laptop.

**Note**  
AWS requires access to the physical USB port on your computer to verify your FIDO2 device. Security keys will not work with a virtual machine, a remote connection, or a browser's incognito mode.

The FIDO Alliance maintains a list of all [FIDO2 products](https://fidoalliance.org/certification/fido-certified-products/) that are compatible with FIDO specifications.

## Browsers that support FIDO2
<a name="id_credentials_mfa_fido_browsers"></a>

The availability of FIDO2 security devices that run in a web browser depends on the combination of browser and operating system. The following browsers currently support the use of security keys:


****  

| Web browser | macOS 10.15\$1 | Windows 10 | Linux | iOS 14.5\$1 | Android 7\$1 | 
| --- | --- | --- | --- | --- | --- | 
| Chrome | Yes | Yes | Yes | Yes | No | 
| Safari | Yes | No | No | Yes | No | 
| Edge | Yes | Yes | No | Yes | No | 
| Firefox | Yes | Yes | No | Yes | No | 

**Note**  
Most Firefox versions that currently support FIDO2 don't enable support by default. For instructions on enabling FIDO2 support in Firefox, see [Troubleshoot Passkeys and FIDO Security Keys](troubleshoot_mfa-fido.md).  
Firefox on macOS may not fully support cross-device authentication workflows for passkeys. You may get a prompt to touch a security key instead of proceeding with cross-device authentication. We recommend using a different browser, such as Chrome or Safari, for signing in with passkeys on macOS.

For more information about browser support for a FIDO2-Certified device like YubiKey, see [Operating system and web browser support for FIDO2 and U2F](https://support.yubico.com/hc/en-us/articles/360016615020-Operating-system-and-web-browser-support-for-FIDO2-and-U2F).

### Browser plugins
<a name="id_credentials_mfa_fido_plugins"></a>

AWS supports only browsers that natively support FIDO2. AWS doesn't support using plugins to add FIDO2 browser support. Some browser plugins are incompatible with the FIDO2 standard and can cause unexpected results with FIDO2 security keys. 

For information on disabling browser plugins and other troubleshooting tips, see [I can't enable my FIDO security key](troubleshoot_mfa-fido.md#troubleshoot_mfa-fido-cant-enable). 

## Device certifications
<a name="id_credentials_mfa_fido_certifications"></a>

We capture and assign device-related certifications, such as FIPS validation and FIDO certification level, only during the registration of a security key. Your device certification is retrieved from the [FIDO Alliance Metadata Service (MDS)](https://fidoalliance.org/metadata/). If the certification status or level of your security key changes, it will not be reflected in the device tags automatically. To update the certification information of a device, register the device again to fetch the updated certification information. 

AWS provides the following certification types as condition keys during device registration, obtained from the FIDO MDS: FIPS-140-2, FIPS-140-3, and FIDO certification levels. You have the ability to specify the registration of specific authenticators in their IAM policies, based on your preferred certification type and level. For more information, see the policies below.

### Example policies for device certifications
<a name="id_credentials_mfa_fido_certifications_policies"></a>

The following use cases show sample policies that allow you to register MFA devices with FIPS certifications.

**Topics**
+ [

#### Use case 1: Allow registering only devices that have FIPS-140-2 L2 certifications
](#id_credentials_mfa_fido_certifications_policies_use_case_1)
+ [

#### Use case 2: Allow registering devices that have FIPS-140-2 L2 and FIDO L1 certifications
](#id_credentials_mfa_fido_certifications_policies_use_case_2)
+ [

#### Use case 3: Allow registering devices that have either FIPS-140-2 L2 or FIPS-140-3 L2 certifications
](#id_credentials_mfa_fido_certifications_policies_use_case_3)
+ [

#### Use case 4: Allow registering devices that have FIPS-140-2 L2 certification and support other MFA types like virtual authenticators and hardware TOTP
](#id_credentials_mfa_fido_certifications_policies_use_case_4)

#### Use case 1: Allow registering only devices that have FIPS-140-2 L2 certifications
<a name="id_credentials_mfa_fido_certifications_policies_use_case_1"></a>

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-2-certification": "L2"
                }
            }
        }
    ]
}
```

------

#### Use case 2: Allow registering devices that have FIPS-140-2 L2 and FIDO L1 certifications
<a name="id_credentials_mfa_fido_certifications_policies_use_case_2"></a>

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-2-certification": "L2",
                    "iam:FIDO-certification": "L1"
                }
            }
        }
    ]
}
```

------

#### Use case 3: Allow registering devices that have either FIPS-140-2 L2 or FIPS-140-3 L2 certifications
<a name="id_credentials_mfa_fido_certifications_policies_use_case_3"></a>

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-2-certification": "L2"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-3-certification": "L2"
                }
            }
        }
    ]
}
```

------

#### Use case 4: Allow registering devices that have FIPS-140-2 L2 certification and support other MFA types like virtual authenticators and hardware TOTP
<a name="id_credentials_mfa_fido_certifications_policies_use_case_4"></a>

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:EnableMFADevice",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:RegisterSecurityKey": "Create"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "iam:EnableMFADevice",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:RegisterSecurityKey": "Activate",
          "iam:FIDO-FIPS-140-2-certification": "L2"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "iam:EnableMFADevice",
      "Resource": "*",
      "Condition": {
        "Null": {
          "iam:RegisterSecurityKey": "true"
        }
      }
    }
  ]
}
```

------

## AWS CLI and AWS API
<a name="id_credentials_mfa_fido_cliapi"></a>

AWS supports using passkeys and security keys only in the AWS Management Console. Using passkeys and security keys for MFA is not supported in the [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/) and [AWS API](https://aws.amazon.com/tools/), or for access to [MFA-protected API operations](id_credentials_mfa_configure-api-require.md).

## Additional resources
<a name="id_credentials_mfa_fido_additional_resources"></a>
+ For more information on using passkeys and security keys in AWS, see [Assign a passkey or security key in the AWS Management Console](id_credentials_mfa_enable_fido.md).
+ For help with troubleshooting passkeys and security keys in AWS, see [Troubleshoot Passkeys and FIDO Security Keys](troubleshoot_mfa-fido.md).
+ For general industry information on FIDO2 support, see [FIDO2 Project](https://en.wikipedia.org/wiki/FIDO2_Project). 

# Assign a virtual MFA device in the AWS Management Console
<a name="id_credentials_mfa_enable_virtual"></a>

**Important**  
AWS recommends that you use a passkey or security key for MFA to AWS, wherever possible. For more information, see [Assign a passkey or security key in the AWS Management Console](id_credentials_mfa_enable_fido.md).

You can use a phone or other device as a virtual multi-factor authentication (MFA) device. To do this, install a mobile app that is compliant with [RFC 6238, a standards-based TOTP (time-based one-time password) algorithm](https://datatracker.ietf.org/doc/html/rfc6238). These apps generate a six-digit authentication code. Because authenticators can run on unsecured mobile devices, and the codes could potentially be shared with unauthorized parties, TOTP-based MFA does not provide the same level of security as phishing-resistant options such as [FIDO2](https://en.wikipedia.org/wiki/FIDO_Alliance#FIDO2) security keys and passkeys. We recommend that you use passkeys or security keys for MFA for the strongest protection against attacks such as phishing.

If you are not yet able to use passkeys or security keys, we recommend that you use a virtual MFA device as an interim measure while you wait for any hardware purchase approvals or for your hardware to arrive.

Most virtual MFA apps support creating multiple virtual devices, allowing you to use the same app for multiple AWS accounts or users. You can register up to **eight** MFA devices of any combination of [MFA types](https://aws.amazon.com/iam/features/mfa/) with your AWS account root user and IAM users. You only need one MFA device to sign in to the AWS Management Console or create a session through the AWS CLI. We recommend that you register multiple MFA devices. For authenticator applications, we also recommend enabling the cloud backup or sync feature to help you avoid losing access to your account if you lose or break your device.

AWS requires a virtual MFA app that produces a six-digit OTP. For a list of virtual MFA apps that you can use, see [Multi-Factor Authentication](https://aws.amazon.com/iam/features/mfa/?audit=2019q1). 

**Topics**
+ [

## Permissions required
](#mfa_enable_virtual_permissions-required)
+ [

## Enable a virtual MFA device for an IAM user (console)
](#enable-virt-mfa-for-iam-user)
+ [

## Replace a virtual MFA device
](#replace-virt-mfa)

## Permissions required
<a name="mfa_enable_virtual_permissions-required"></a>

To manage virtual MFA devices for your IAM user, you must have the permissions from the following policy: [AWS: Allows MFA-authenticated IAM users to manage their own MFA device on the Security credentials page](reference_policies_examples_aws_my-sec-creds-self-manage-mfa-only.md).

## Enable a virtual MFA device for an IAM user (console)
<a name="enable-virt-mfa-for-iam-user"></a>

You can use IAM in the AWS Management Console to enable and manage a virtual MFA device for an IAM user in your account. You can attach tags to your IAM resources, including virtual MFA devices, to identify, organize, and control access to them. You can tag virtual MFA devices only when you use the AWS CLI or AWS API. To enable and manage an MFA device using the AWS CLI or AWS API, see [Assign MFA devices in the AWS CLI or AWS API](id_credentials_mfa_enable_cliapi.md). For more information about tagging IAM resources, see [Tags for AWS Identity and Access Management resources](id_tags.md). 

**Note**  
You must have physical access to the hardware that will host the user's virtual MFA device in order to configure MFA. For example, you might configure MFA for a user who will use a virtual MFA device running on a smartphone. In that case, you must have the smartphone available in order to finish the wizard. Because of this, you might want to let users configure and manage their own virtual MFA devices. In that case, you must grant users the permissions to perform the necessary IAM actions. For more information and for an example of an IAM policy that grants these permissions, see the [IAM tutorial: Permit users to manage their credentials and MFA settings](tutorial_users-self-manage-mfa-and-creds.md) and example policy [AWS: Allows MFA-authenticated IAM users to manage their own MFA device on the Security credentials page](reference_policies_examples_aws_my-sec-creds-self-manage-mfa-only.md). 

**To enable a virtual MFA device for an IAM user (console)**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**.

1. In the **Users** list, choose the name of the IAM user.

1. Choose the **Security Credentials** tab. Under **Multi-factor authentication (MFA)**, choose **Assign MFA device**.

1. In the wizard, type a **Device name**, choose **Authenticator app**, and then choose **Next**.

   IAM generates and displays configuration information for the virtual MFA device, including a QR code graphic. The graphic is a representation of the "secret configuration key" that is available for manual entry on devices that do not support QR codes.

1. Open your virtual MFA app. For a list of apps that you can use for hosting virtual MFA devices, see [Multi-Factor Authentication](http://aws.amazon.com/iam/details/mfa/). 

   If the virtual MFA app supports multiple virtual MFA devices or accounts, choose the option to create a new virtual MFA device or account.

1. Determine whether the MFA app supports QR codes, and then do one of the following:
   + From the wizard, choose **Show QR code**, and then use the app to scan the QR code. This might be a camera icon or **Scan code** option that uses the device's camera to scan the code.
   + From the wizard, choose **Show secret key**, and then type the secret key into your MFA app.

   When you are finished, the virtual MFA device starts generating one-time passwords. 

1. On the **Set up device** page, in the **MFA code 1** box, type the one-time password that currently appears in the virtual MFA device. Wait up to 30 seconds for the device to generate a new one-time password. Then type the second one-time password into the **MFA code 2** box. Choose **Add MFA**. 
**Important**  
Submit your request immediately after generating the codes. If you generate the codes and then wait too long to submit the request, the MFA device successfully associates with the user but the MFA device is out of sync. This happens because time-based one-time passwords (TOTP) expire after a short period of time. If this happens, you can [resync the device](id_credentials_mfa_sync.md).

The virtual MFA device is now ready for use with AWS. For information about using MFA with the AWS Management Console, see [MFA enabled sign-in](console_sign-in-mfa.md).

**Note**  
Unassigned virtual MFA devices in your AWS account are deleted when you’re adding new virtual MFA devices either via the AWS Management Console or during the sign-in process. Unassigned virtual MFA devices are devices in your account but not used by account root user or IAM users for the sign-in process. They’re deleted so new virtual MFA devices can be added to your account. It also allows you to reuse device names.  
To view unassigned virtual MFA devices in your account, you can use either the [list-virtual-mfa-devices](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-virtual-mfa-devices.html) AWS CLI command or [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html) call.
To deactivate a virtual MFA device, you can use either the [deactivate-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html) AWS CLI command or [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html) call. The device will become unassigned.
To attach an unassigned virtual MFA device to your AWS account root user or IAM users, you'll need the authentication code generated by the device along with either the [enable-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/enable-mfa-device.html) AWS CLI command or [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) call.

## Replace a virtual MFA device
<a name="replace-virt-mfa"></a>

Your AWS account root user and IAM users can register up to **eight** MFA devices of any combination of MFA types. If the user loses a device or needs to replace it for any reason, deactivate the old device. Then you can add the new device for the user.
+ To deactivate the device currently associated with another IAM user, see [Deactivate an MFA device](id_credentials_mfa_disable.md).
+ To add a replacement virtual MFA device for another IAM user, follow the steps in the procedure [Enable a virtual MFA device for an IAM user (console)](#enable-virt-mfa-for-iam-user) above.
+ To add a replacement virtual MFA device for the AWS account root user, follow the steps in the procedure [Enable a virtual MFA device for the root user (console)](enable-virt-mfa-for-root.md).

# Assign a hardware TOTP token in the AWS Management Console
<a name="id_credentials_mfa_enable_physical"></a>

**Important**  
AWS recommends that you use a passkey or security key for MFA to AWS, wherever possible. For more information, see [Assign a passkey or security key in the AWS Management Console](id_credentials_mfa_enable_fido.md).

A hardware TOTP token generates a six-digit numeric code based upon a time-based one-time password (TOTP) algorithm. The user must type a valid code from the device when prompted during the sign-in process. Each MFA device assigned to a user must be unique; a user cannot type a code from another user's device to be authenticated. MFA devices cannot be shared across accounts or users.

Hardware TOTP tokens and [FIDO security keys](id_credentials_mfa_enable_fido.md) are both physical devices that you purchase. Hardware MFA devices generate TOTP codes for authentication when you sign in to AWS. They rely on batteries, which may need replacement and resynchronization with AWS over time. FIDO security keys, which utilize public key cryptography, do not require batteries and offer a seamless authentication process. We recommend using FIDO security keys for their phishing resistance, which provides a more secure alternative to TOTP devices. Additionally, FIDO security keys can support multiple IAM or root users on the same device, enhancing their utility for account security. For specifications and purchase information for both device types, see [Multi-Factor Authentication](http://aws.amazon.com/iam/details/mfa/).



You can enable a hardware TOTP token for an IAM user from the AWS Management Console, the command line, or the IAM API. To enable an MFA device for your AWS account root user, see [Enable a hardware TOTP token for the root user (console)](enable-hw-mfa-for-root.md).

You can register up to **eight** MFA devices of any combination of the [ currently supported MFA types](https://aws.amazon.com/iam/features/mfa/) with your AWS account root user and IAM users. With multiple MFA devices, you only need one MFA device to sign in to the AWS Management Console or create a session through the AWS CLI as that user.

**Important**  
We recommend that you enable multiple MFA devices for your users for continued access to your account in case of a lost or inaccessible MFA device.

**Note**  
If you want to enable the MFA device from the command line, use [https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html). To enable the MFA device with the IAM API, use the [https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) operation. 

**Topics**
+ [

## Permissions required
](#enable-hw-mfa-for-iam-user-permissions-required)
+ [

## Enable a hardware TOTP token for your own IAM user (console)
](#enable-hw-mfa-for-own-iam-user)
+ [

## Enable a hardware TOTP token for another IAM user (console)
](#enable-hw-mfa-for-iam-user)
+ [

## Replace a physical MFA device
](#replace-phys-mfa)

## Permissions required
<a name="enable-hw-mfa-for-iam-user-permissions-required"></a>

To manage a hardware TOTP token for your own IAM user while protecting sensitive MFA-related actions, you must have the permissions from the following policy:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowManageOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice",
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "DenyAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}
```

------

## Enable a hardware TOTP token for your own IAM user (console)
<a name="enable-hw-mfa-for-own-iam-user"></a>

 You can enable your own hardware TOTP token from the AWS Management Console.

**Note**  
Before you can enable a hardware TOTP token, you must have physical access to the device.

**To enable a hardware TOTP token for your own IAM user (console)**

1. Use your AWS account ID or account alias, your IAM user name, and your password to sign in to the [IAM console](https://console.aws.amazon.com/iam).
**Note**  
For your convenience, the AWS sign-in page uses a browser cookie to remember your IAM user name and account information. If you previously signed in as a different user, choose **Sign in to a different account** near the bottom of the page to return to the main sign-in page. From there, you can type your AWS account ID or account alias to be redirected to the IAM user sign-in page for your account.

   To get your AWS account ID, contact your administrator.

1. In the navigation bar on the upper right, choose your user name, and then choose **Security credentials**.   
![\[AWS Management Console Security credentials link\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. On the **AWS IAM credentials** tab, in the **Multi-factor authentication (MFA)** section, choose **Assign MFA device**.

1. In the wizard, type a **Device name**, choose **Hardware TOTP token**, and then choose **Next**.

1. Type the device serial number. The serial number is usually on the back of the device.

1. In the **MFA code 1** box, type the six-digit number displayed by the MFA device. You might need to press the button on the front of the device to display the number.  
![\[IAM Dashboard, MFA Device\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/MFADevice.png)

1. Wait 30 seconds while the device refreshes the code, and then type the next six-digit number into the **MFA code 2** box. You might need to press the button on the front of the device again to display the second number.

1. Choose **Add MFA**.
**Important**  
Submit your request immediately after generating the authentication codes. If you generate the codes and then wait too long to submit the request, the MFA device successfully associates with the user but the MFA device becomes out of sync. This happens because time-based one-time passwords (TOTP) expire after a short period of time. If this happens, you can [resync the device](id_credentials_mfa_sync.md).

The device is ready for use with AWS. For information about using MFA with the AWS Management Console, see [MFA enabled sign-in](console_sign-in-mfa.md).

## Enable a hardware TOTP token for another IAM user (console)
<a name="enable-hw-mfa-for-iam-user"></a>

 You can enable a hardware TOTP token for another IAM user from the AWS Management Console.

**To enable a hardware TOTP token for another IAM user (console)**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**.

1. Choose the name of the user for whom you want to enable MFA.

1. Choose the **Security Credentials** tab. Under **Multi-factor authentication (MFA)**, choose **Assign MFA device**.

1. In the wizard, type a **Device name**, choose **Hardware TOTP token**, and then choose **Next**.

1. Type the device serial number. The serial number is usually on the back of the device.

1. In the **MFA code 1** box, type the six-digit number displayed by the MFA device. You might need to press the button on the front of the device to display the number.  
![\[IAM Dashboard, MFA Device\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/MFADevice.png)

1. Wait 30 seconds while the device refreshes the code, and then type the next six-digit number into the **MFA code 2** box. You might need to press the button on the front of the device again to display the second number.

1. Choose **Add MFA**.
**Important**  
Submit your request immediately after generating the authentication codes. If you generate the codes and then wait too long to submit the request, the MFA device successfully associates with the user but the MFA device becomes out of sync. This happens because time-based one-time passwords (TOTP) expire after a short period of time. If this happens, you can [resync the device](id_credentials_mfa_sync.md).

The device is ready for use with AWS. For information about using MFA with the AWS Management Console, see [MFA enabled sign-in](console_sign-in-mfa.md).

## Replace a physical MFA device
<a name="replace-phys-mfa"></a>

You can have up to eight MFA devices of any combination of the [currently supported MFA types](https://aws.amazon.com/iam/features/mfa/) assigned to a user at a time with your AWS account root user and IAM users. If the user loses a device or needs to replace it for any reason, you must first deactivate the old device. Then you can add the new device for the user.
+ To deactivate the device currently associated with a user, see [Deactivate an MFA device](id_credentials_mfa_disable.md).
+ To add a replacement hardware TOTP token for an IAM user, follow the steps in the procedure [Enable a hardware TOTP token for another IAM user (console)](#enable-hw-mfa-for-iam-user) earlier in this topic.
+ To add a replacement hardware TOTP token for the AWS account root user, follow the steps in the procedure [Enable a hardware TOTP token for the root user (console)](enable-hw-mfa-for-root.md) earlier in this topic.

# Assign MFA devices in the AWS CLI or AWS API
<a name="id_credentials_mfa_enable_cliapi"></a>

You can use AWS CLI commands or AWS API operations to enable a virtual MFA device for an IAM user. You cannot enable an MFA device for the AWS account root user with the AWS CLI, AWS API, Tools for Windows PowerShell, or any other command line tool. However, you can use the AWS Management Console to enable an MFA device for the root user. 

When you enable an MFA device from the AWS Management Console, the console performs multiple steps for you. If you instead create a virtual device using the AWS CLI, Tools for Windows PowerShell, or AWS API, then you must perform the steps manually and in the correct order. For example, to create a virtual MFA device, you must create the IAM object and extract the code as either a string or a QR code graphic. Then you must sync the device and associate it with an IAM user. See the **Examples** section of [New-IAMVirtualMFADevice](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=New-IAMVirtualMFADevice.html&tocid=New-IAMVirtualMFADevice) for more details. For a physical device, you skip the creation step and go directly to syncing the device and associating it with the user. 

You can attach tags to your IAM resources, including virtual MFA devices, to identify, organize, and control access to them. You can tag virtual MFA devices only when you use the AWS CLI or AWS API.

An IAM user using the SDK or CLI can enable an additional MFA device by calling [https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) or deactivate an existing MFA device by calling [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html). To do this successfully, they must first call [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) and submit MFA codes with an existing MFA device. This call returns temporary security credentials that can then be used to sign API operations that require MFA authentication. For an example request and response, see [`GetSessionToken`—temporary credentials for users in untrusted environments](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_getsessiontoken). 

**To create the virtual device entity in IAM to represent a virtual MFA device**  
These commands provide an ARN for the device that is used in place of a serial number in many of the following commands.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/create-virtual-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-virtual-mfa-device.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateVirtualMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateVirtualMFADevice.html) 

**To enable an MFA device for use with AWS**  
These commands synchronize the device with AWS and associate it with a user. If the device is virtual, use the ARN of the virtual device as the serial number.

**Important**  
Submit your request immediately after generating the authentication codes. If you generate the codes and then wait too long to submit the request, the MFA device successfully associates with the user but the MFA device becomes out of sync. This happens because time-based one-time passwords (TOTP) expire after a short period of time. If this happens, you can resynchronize the device using the commands described below.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) 

**To deactivate a device**  
Use these commands to disassociate the device from the user and deactivate it. If the device is virtual, use the ARN of the virtual device as the serial number. You must also separately delete the virtual device entity. 
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)

**To list virtual MFA device entities**  
Use these commands to list virtual MFA device entities.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/list-virtual-mfa-devices.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-virtual-mfa-devices.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html) 

**To tag a virtual MFA device**  
Use these commands to tag a virtual MFA device.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/tag-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-mfa-device.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagMFADevice.html) 

**To list tags for a virtual MFA device**  
Use these commands to list the tags attached to a virtual MFA device.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-device-tags.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-device-tags.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADeviceTags.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADeviceTags.html) 

**To untag a virtual MFA device**  
Use these commands to remove tags attached to a virtual MFA device.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/untag-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-mfa-device.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagMFADevice.html) 

**To resynchronize an MFA device**  
Use these commands if the device is generating codes that are not accepted by AWS. If the device is virtual, use the ARN of the virtual device as the serial number.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/resync-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/resync-mfa-device.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResyncMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResyncMFADevice.html) 

**To delete a virtual MFA device entity in IAM**  
After the device is disassociated from the user, you can delete the device entity.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-virtual-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-virtual-mfa-device.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteVirtualMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteVirtualMFADevice.html) 

**To recover a virtual MFA device that is lost or not working**  
Sometimes, a user's device that hosts the virtual MFA app is lost, replaced, or not working. When this happens, the user can't recover it on their own. The user must contact an administrator to deactivate the device. For more information, see [Recover an MFA protected identity in IAM](id_credentials_mfa_lost-or-broken.md).

# Check MFA status
<a name="id_credentials_mfa_checking-status"></a>

Use the IAM console to check whether an AWS account root user or IAM user has a valid MFA device enabled.

**To check the MFA status of a root user**

1. Sign in to the AWS Management Console with your root user credentials and then open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 

1. In the navigation bar on the upper right, choose your user name, and then choose **Security credentials**.

1. Check under **Multi-factor Authentication (MFA)** to see whether MFA is enabled or disabled. If MFA has not been activated, an alert symbol (![\[Alert icon\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/console-alert-icon.console.png)) is displayed. 

If you want to enable MFA for the account, see one of the following:
+ [Enable a virtual MFA device for the root user (console)](enable-virt-mfa-for-root.md)
+ [Enable a passkey or security key for the root user (console)](enable-fido-mfa-for-root.md)
+ [Enable a hardware TOTP token for the root user (console)](enable-hw-mfa-for-root.md)

**To check the MFA status of IAM users**

1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 

1. In the navigation pane, choose **Users**.

1. If necessary, add the **MFA** column to the users table by completing the following steps:

   1. Above the table on the far right, choose the settings icon (![\[Settings icon\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/console-settings-icon.console.png)).

   1. In **Manage Columns**, select **MFA**.

   1. (Optional) Clear the checkbox for any column headings that you do not want to appear in the users table.

   1. Choose **Close** to return to the list of users.

1. The **MFA** column tells you about the MFA device that is enabled. If no MFA device is active for the user, the console displays **None**. If the user has an MFA device enabled, the **MFA** column shows the type of device that is enabled with a value of **Virtual**, **Security key**, **Hardware**, or **SMS**.
**Note**  
AWS ended support for enabling SMS multi-factor authentication (MFA). We recommend that customers who have IAM users that use SMS text message-based MFA switch to one of the following alternative methods: [virtual (software-based) MFA device](id_credentials_mfa_enable_virtual.md), [FIDO security key](id_credentials_mfa_enable_fido.md), or [hardware MFA device](id_credentials_mfa_enable_physical.md). You can identify the users in your account with an assigned SMS MFA device. To do so, go to the IAM console, choose **Users** from the navigation pane, and look for users with **SMS** in the **MFA** column of the table.

1. To view additional information about the MFA device for a user, choose the name of the user whose MFA status you want to check. Then choose the **Security credentials** tab. 

1. If no MFA device is active for the user, the console displays **No MFA devices. Assign an MFA device to improve the security of your AWS environment** in the **Multi-factor authentication (MFA)** section. If the user has MFA devices enabled, the **Multi-factor authentication (MFA)** section shows details about the devices:
   + The device name
   + The device type
   + The identifier for the device, such as a serial number for a physical device or the ARN in AWS for a virtual device
   + When the device was created

To remove or resync a device, choose the radio button next to the device and choose **Remove** or **Resync**.

For more information on enabling MFA, see the following: 
+ [Assign a virtual MFA device in the AWS Management Console](id_credentials_mfa_enable_virtual.md)
+ [Assign a passkey or security key in the AWS Management Console](id_credentials_mfa_enable_fido.md)
+ [Assign a hardware TOTP token in the AWS Management Console](id_credentials_mfa_enable_physical.md)

# Resynchronize virtual and hardware MFA devices
<a name="id_credentials_mfa_sync"></a>

You can use AWS to resynchronize your virtual and hardware multi-factor authentication (MFA) devices. If your device is not synchronized when you try to use it, the sign-in attempt fails and IAM prompts you to resynchronize the device.

**Note**  
FIDO security keys do not go out of sync. If a FIDO security key is lost or broken, you can deactivate it. For instructions on deactivating any MFA device type, see [To deactivate an MFA device for another IAM user (console)](id_credentials_mfa_disable.md#deactivate-mfa-for-user).

As an AWS administrator, you can resynchronize your IAM users' virtual and hardware MFA devices if they get out of synchronization.

If your AWS account root user MFA device is not working, you can resynchronize your device using the IAM console with or without completing the sign-in process. If you aren’t able to successfully resynchronize your device, you may need to de-associate and re-associate it. For more information on how to do this, see [Deactivate an MFA device](id_credentials_mfa_disable.md) and [AWS Multi-factor authentication in IAM](id_credentials_mfa.md).

**Topics**
+ [

## Permissions required
](#id_credentials_mfa_sync_console-permissions-required)
+ [

## Resynchronizing virtual and hardware MFA devices (IAM console)
](#id_credentials_mfa_sync_console)
+ [

## Resynchronizing virtual and hardware MFA devices (AWS CLI)
](#id_credentials_mfa_sync_cli)
+ [

## Resynchronizing virtual and hardware MFA devices (AWS API)
](#id_credentials_mfa_sync_api)

## Permissions required
<a name="id_credentials_mfa_sync_console-permissions-required"></a>

To resynchronize virtual or hardware MFA devices for your own IAM user, you must have the permissions from the following policy. This policy does not allow you to create or deactivate a device.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowListActions",
            "Effect": "Allow",
            "Action": [
                "iam:ListVirtualMFADevices"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowUserToViewAndManageTheirOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "BlockAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:ListMFADevices",
                "iam:ListVirtualMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}
```

------

## Resynchronizing virtual and hardware MFA devices (IAM console)
<a name="id_credentials_mfa_sync_console"></a>

You can use the IAM console to resynchronize virtual and hardware MFA devices.

**To resynchronize a virtual or hardware MFA device for your own IAM user (console)**

1. Use your AWS account ID or account alias, your IAM user name, and your password to sign in to the [IAM console](https://console.aws.amazon.com/iam).
**Note**  
For your convenience, the AWS sign-in page uses a browser cookie to remember your IAM user name and account information. If you previously signed in as a different user, choose **Sign in to a different account** near the bottom of the page to return to the main sign-in page. From there, you can type your AWS account ID or account alias to be redirected to the IAM user sign-in page for your account.

   To get your AWS account ID, contact your administrator.

1. In the navigation bar on the upper right, choose your user name, and then choose **Security credentials**.   
![\[AWS Management Console Security credentials link\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. On the **AWS IAM credentials** tab, in the **Multi-factor authentication (MFA)** section, choose the radio button next to the MFA device and choose **Resync**.

1. Type the next two sequentially generated codes from the device into **MFA code 1** and **MFA code 2**. Then choose **Resync**.
**Important**  
Submit your request immediately after generating the codes. If you generate the codes and then wait too long to submit the request, the request appears to work but the device remains out of sync. This happens because time-based one-time passwords (TOTP) expire after a short period of time.

**To resynchronize a virtual or hardware MFA device for another IAM user (console)**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**, and then choose the name of the user whose MFA device needs to be resynchronized.

1. Choose the **Security credentials** tab. In the **Multi-factor authentication (MFA)** section, choose the radio button next to the MFA device and choose **Resync**.

1. Type the next two sequentially generated codes from the device into **MFA code 1** and **MFA code 2**. Then choose **Resync**.
**Important**  
Submit your request immediately after generating the codes. If you generate the codes and then wait too long to submit the request, the request appears to work but the device remains out of sync. This happens because time-based one-time passwords (TOTP) expire after a short period of time.

**To resynchronize your root user MFA before signing in (console)**

1. On the **Amazon Web Services Sign In With Authentication Device** page, choose **Having problems with your authentication device? Click here**.
**Note**  
You might see different text, such as **Sign in using MFA** and **Troubleshoot your authentication device**. However, the same features are provided.

1. In the **Re-Sync With Our Servers** section, type the next two sequentially generated codes from the device into **MFA code 1** and **MFA code 2**. Then choose **Re-sync authentication device**.

1. If necessary, type your password again and choose **Sign in**. Then complete the sign-in using your MFA device.

**To resynchronize your root user MFA device after signing in (console)**

1. Sign in to the [IAM console](https://console.aws.amazon.com/iam/) as the account owner by choosing **Root user** and entering your AWS account email address. On the next page, enter your password.
**Note**  
As the root user, you can't sign in to the **Sign in as IAM user** page. If you see the **Sign in as IAM user** page, choose **Sign in using root user email** near the bottom of the page. For help signing in as the root user, see [Signing in to the AWS Management Console as the root user](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-          root-user-sign-in-tutorial.html) in the *AWS Sign-In User Guide*.

1. On the right side of the navigation bar, choose on your account name, and then choose **Security credentials**. If necessary, choose **Continue to Security credentials**.  
![\[Security credentials in the navigation menu\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. Expand the **Multi-factor authentication (MFA)** section on the page.

1. Choose the radio button next to the device and choose **Resync**.

1. In the **Resync MFA device** dialog box, type the next two sequentially generated codes from the device into **MFA code 1** and **MFA code 2**. Then choose **Resync**.
**Important**  
Submit your request immediately after generating the codes. If you generate the codes and then wait too long to submit the request, the MFA device is successfully associated with the user, but the MFA device is out of sync. This happens because time-based one-time passwords (TOTP) expire after a short period of time.

## Resynchronizing virtual and hardware MFA devices (AWS CLI)
<a name="id_credentials_mfa_sync_cli"></a>

You can resynchronize virtual and hardware MFA devices from the AWS CLI.

**To resynchronize a virtual or hardware MFA device for an IAM user (AWS CLI)**  
At a command prompt, issue the [aws iam resync-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/resync-mfa-device.html) command:
+ Virtual MFA device: Specify Amazon Resource Name (ARN) of device as the serial number.

  ```
  aws iam resync-mfa-device --user-name Richard --serial-number arn:aws:iam::123456789012:mfa/RichardsMFA --authentication-code1 123456 --authentication-code2 987654
  ```
+ Hardware MFA device: Specify hardware device's serial number as serial number. The format is vendor-specific. For example, you can purchase a gemalto token from Amazon. Its serial number is typically four letters followed by four numbers.

  ```
  aws iam resync-mfa-device --user-name Richard --serial-number ABCD12345678 --authentication-code1 123456 --authentication-code2 987654
  ```

**Important**  
Submit your request immediately after generating the codes. If you generate the codes and then wait too long to submit the request, the request fails because the codes expire after a short time.

## Resynchronizing virtual and hardware MFA devices (AWS API)
<a name="id_credentials_mfa_sync_api"></a>

IAM has an API call that performs synchronization. In this case, we recommend that you give your virtual and hardware MFA device users permission to access this API call. Then build a tool based on that API call so your users can resynchronize their devices whenever they need to.

**To resynchronize a virtual or hardware MFA device for an IAM user (AWS API)**
+ Send the [ResyncMFADevice](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResyncMFADevice.html) request.

# Deactivate an MFA device
<a name="id_credentials_mfa_disable"></a>

If you are having trouble signing in with a multi-factor authentication (MFA) device as an IAM user, contact your administrator for help.

As an administrator, you can deactivate the device for another IAM user. This allows the user to sign in without using MFA. You might do this as a temporary solution while the MFA device is replaced, or if the device is temporarily unavailable. However, we recommend that you enable a new device for the user as soon as possible. To learn how to enable a new MFA device, see [AWS Multi-factor authentication in IAM](id_credentials_mfa.md).

**Note**  
If you use the API or AWS CLI to delete a user from your AWS account, you must deactivate or delete the user's MFA device. You make this change as part of the process of removing the user. For more information about removing users, see [Remove or deactivate an IAM user](id_users_remove.md).

**Topics**
+ [

## Deactivating MFA devices (console)
](#deactive-mfa-console)
+ [

## Deactivating MFA devices (AWS CLI)
](#deactivate-mfa-cli)
+ [

## Deactivating MFA devices (AWS API)
](#deactivate-mfa-api)

## Deactivating MFA devices (console)
<a name="deactive-mfa-console"></a><a name="deactivate-mfa-for-user"></a>

**To deactivate an MFA device for another IAM user (console)**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**.

1. To deactivate the MFA device for a user, choose the name of the user whose MFA you want to remove.

1. Choose the **Security credentials** tab.

1. Under **​Multi-factor authentication (MFA)**, choose the radio button next to the MFA device, choose **Remove**, and then choose **Remove**.

   The device is removed from AWS. It cannot be used to sign in or authenticate requests until it is reactivated and associated with an AWS user or AWS account root user.<a name="deactivate-mfa-for-root"></a>

**To deactivate the MFA device for your AWS account root user (console)**

1. Sign in to the [IAM console](https://console.aws.amazon.com/iam/) as the account owner by choosing **Root user** and entering your AWS account email address. On the next page, enter your password.
**Note**  
As the root user, you can't sign in to the **Sign in as IAM user** page. If you see the **Sign in as IAM user** page, choose **Sign in using root user email** near the bottom of the page. For help signing in as the root user, see [Signing in to the AWS Management Console as the root user](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-          root-user-sign-in-tutorial.html) in the *AWS Sign-In User Guide*.

1. On the right side of the navigation bar, choose on your account name, and then choose **Security credentials**. If necessary, choose **Continue to Security credentials**.  
![\[Security credentials in the navigation menu\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. In the **Multi-factor authentication (MFA)** section, choose the radio button next the MFA device that you want to deactivate and choose **Remove**.

1. Choose **Remove**.

   The MFA device is deactivated for the AWS account. Check the email that is associated with your AWS account for a confirmation message from Amazon Web Services. The email informs you that your Amazon Web Services multi-factor authentication (MFA) has been deactivated. The message will come from `@amazon.com` or `@aws.amazon.com`.

**Note**  
Unassigned virtual MFA devices in your AWS account are deleted when you’re adding new virtual MFA devices either via the AWS Management Console or during the sign-in process. Unassigned virtual MFA devices are devices in your account but not used by account root user or IAM users for the sign-in process. They’re deleted so new virtual MFA devices can be added to your account. It also allows you to reuse device names.

## Deactivating MFA devices (AWS CLI)
<a name="deactivate-mfa-cli"></a>

**To deactivate an MFA device for an IAM user (AWS CLI)**
+ Run this command: [https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html)

## Deactivating MFA devices (AWS API)
<a name="deactivate-mfa-api"></a>

**To deactivate an MFA device for an IAM user (AWS API)**
+ Call this operation: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)

# Recover an MFA protected identity in IAM
<a name="id_credentials_mfa_lost-or-broken"></a>

If your [virtual MFA device](id_credentials_mfa_enable_virtual.md) or [hardware TOTP token](id_credentials_mfa_enable_physical.md) appears to be functioning properly, but you can't use it to access your AWS resources, it might be out of synchronization with AWS. For information about synchronizing a virtual MFA device or hardware MFA device, see [Resynchronize virtual and hardware MFA devices](id_credentials_mfa_sync.md). [FIDO security keys](id_credentials_mfa_enable_fido.md) do not go out of sync.

If the [MFA device](id_credentials_mfa.md) for a AWS account root user is lost, damaged, or not working, you can recover access to your account. IAM users must contact an administrator to deactivate the device.

**Important**  
We recommend that you activate multiple MFA devices. Registering multiple MFA devices helps ensure continued access if a device is lost or broken. Your AWS account root user and IAM users can register up to eight MFA devices of any type.

## Prerequisite – Use another MFA device
<a name="mfa-lost-or-broken-prerequisites"></a>

If your [multi-factor authentication (MFA) device](id_credentials_mfa.md) is lost, damaged, or not working, you can sign in using another MFA device registered to the same root user or IAM user.

**To sign in using another MFA device**

1. Sign in to the [AWS Management Console](url-comsole-domain;iam) with your AWS account ID or account alias and password.

1. On the **Additional verification required** page or **Multi-factor authentication** page, choose **Try another MFA method**.

1. Authenticate with the type of MFA device that you selected.

1. The next step varies based on whether you successfully signed in with an alternate MFA device.
   + If you have successfully signed in, you can [Resynchronize virtual and hardware MFA devices](id_credentials_mfa_sync.md), which may resolve the issue. If your MFA device is lost or broken, you can deactivate it. For instructions on deactivating any MFA device type, see [Deactivate an MFA device](id_credentials_mfa_disable.md).
   + If you can't sign in with MFA, use the steps in [Recovering a root user MFA device](#root-mfa-lost-or-broken) or [Recovering an IAM user MFA device](#iam-user-mfa-lost-or-broken) to recover your MFA protected identity.



## Recovering a root user MFA device
<a name="root-mfa-lost-or-broken"></a>

If you can't sign in with MFA, you can use alternative methods of authentication to sign in by verifying your identity using the email and the primary contact phone number registered with your account.

Confirm you are able to access the email and primary contact phone number associated with your account before you use alternative authentication factors to sign in as a root user. If you need to update the primary contact phone number, sign in as an IAM user with *Administrator* access instead of the root user. For additional instructions on updating the account contact information, see [Editing contact information](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html) in the *AWS Billing User Guide*. If you do not have access to an email and primary contact phone number, you must contact [AWS Support](https://support.aws.amazon.com/#/contacts/aws-mfa-support).

**Important**  
We recommend that you keep the email address and contact phone number linked to your root user up to date for a successful account recovery. For more information, see [Update the primary contact for your AWS account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html) in the *AWS Account Management Reference Guide*.

**To sign in using alternative factors of authentication as an AWS account root user**

1.  Sign in to the [AWS Management Console](https://console.aws.amazon.com/) as the account owner by choosing **Root user** and entering your AWS account email address. On the next page, enter your password.

1. On the **Additional verification required** page, select an MFA method to authenticate with and choose **Next**. 
**Note**  
You might see alternative text, such as **Sign in using MFA**, **Troubleshoot your authentication device**, or **Troubleshoot MFA**, but the functionality is the same. If you can't use alternative authentication factors to verify your account email address and primary contact phone number, contact [AWS Support](https://support.aws.amazon.com/#/contacts/aws-mfa-support) to deactivate your MFA device.

1. Depending on the type of MFA you are using, you will see a different page, but the **Troubleshoot MFA** option functions the same. On the **Additional verification required** page or **Multi-factor authentication** page, choose **Troubleshoot MFA**.

1. If required, type your password again and choose **Sign in**.

1. On the **Troubleshoot your authentication device** page, in the **Sign in using alternative factors of authentication** section, choose **Sign in using alternative factors**.

1. On the **Sign in using alternative factors of authentication** page, authenticate your account by verifying the email address, choose **Send verification email**. 

1. Check the email that is associated with your AWS account for a message from Amazon Web Services (recover-mfa-no-reply@verify.signin.aws). Follow the directions in the email.

   If you don't see the email in your account, check your spam folder, or return to your browser and choose **Resend the email**.

1. After you verify your email address, you can continue authenticating your account. To verify your primary contact phone number, choose **Call me now**.

1. Answer the call from AWS and, when prompted, enter the 6-digit number from the AWS website on your phone keypad. 

   If you don't receive a call from AWS, choose **Sign in **to sign in to the console again and start over. Or see [Lost or unusable Multi-Factor Authentication (MFA) device](https://support.aws.amazon.com/#/contacts/aws-mfa-support) to contact support for help.

1. After you verify your phone number, you can sign in to your account by choosing **Sign in to the console**.

1. The next step varies depending on the type of MFA you are using:
   + For a virtual MFA device, remove the account from your device. Then go to the [AWS Security Credentials](https://console.aws.amazon.com/iam/home?#security_credential) page and delete the old MFA virtual device entity before you create a new one.
   + For a FIDO security key, go to the [AWS Security Credentials](https://console.aws.amazon.com/iam/home?#security_credential) page and deactivate the old FIDO security key before enabling a new one.
   + For a hardware TOTP token, contact the third-party provider for help with fixing or replacing the device. You can continue to sign in using alternative factors of authentication until you receive your new device. After you have the new hardware MFA device, go to the [AWS Security Credentials](https://console.aws.amazon.com/iam/home?#security_credential) page and delete the old MFA device.
**Note**  
You don't have to replace a lost or stolen MFA device with the same type of device. For example, if you break your FIDO security key and order a new one, you can use virtual MFA or a hardware TOTP token until the new FIDO key arrives.

**Important**  
If your MFA device is missing or stolen, change your root user password after signing in and establishing your replacement MFA device. An attacker may have stolen the authentication device and might also have your current password. For more information, see [Change the password for the AWS account root user](root-user-password.md).

## Recovering an IAM user MFA device
<a name="iam-user-mfa-lost-or-broken"></a>

If you are an IAM user that can't sign in with MFA, you can't recover an MFA device by yourself. You must contact an administrator to deactivate the device. Then you can enable a new device.

**To get help for an MFA device as an IAM user**

1. Contact the AWS administrator or other person who gave you the user name and password for the IAM user. The administrator must deactivate the MFA device as described in [Deactivate an MFA device](id_credentials_mfa_disable.md) so that you can sign in.

1. The next step varies depending on the type of MFA you are using:
   + For a virtual MFA device, remove the account from your device. Then enable the virtual device as described in [Assign a virtual MFA device in the AWS Management Console](id_credentials_mfa_enable_virtual.md).
   + For a FIDO security key, contact the third-party provider for help with replacing the device. When you receive the new FIDO security key, enable it as described in [Assign a passkey or security key in the AWS Management Console](id_credentials_mfa_enable_fido.md).
   + For a hardware TOTP token, contact the third-party provider for help with fixing or replacing the device. After you have the new physical MFA device, enable the device as described in [Assign a hardware TOTP token in the AWS Management Console](id_credentials_mfa_enable_physical.md).
**Note**  
You don't have to replace a lost or stolen MFA device with the same type of device. You can have up to eight MFA devices of any combination. For example, if you break your FIDO security key and order a new one, you can use virtual MFA or a hardware TOTP token until the new FIDO key arrives.

1. If your MFA device is missing or stolen, also change your password in case an attacker has stolen the authentication device and might also have your current password. For more information, see [Manage passwords for IAM users](id_credentials_passwords_admin-change-user.md)

# Secure API access with MFA
<a name="id_credentials_mfa_configure-api-require"></a>

With IAM policies, you can specify which API operations a user is allowed to call. You can apply additional security by requiring users to authenticate with multi-factor authentication (MFA) before you allow them to perform particularly sensitive actions.

For example, you might have a policy that allows a user to perform the Amazon EC2 `RunInstances`, `DescribeInstances`, and `StopInstances` actions. But you might want to restrict a destructive action like `TerminateInstances` and ensure that users can perform that action only if they authenticate with an AWS MFA device.

**Topics**
+ [

## Overview
](#MFAProtectedAPI-overview)
+ [

## Scenario: MFA protection for cross-account delegation
](#MFAProtectedAPI-cross-account-delegation)
+ [

## Scenario: MFA protection for access to API operations in the current account
](#MFAProtectedAPI-user-mfa)
+ [

## Scenario: MFA protection for resources that have resource-based policies
](#MFAProtectedAPI-resource-policies)

## Overview
<a name="MFAProtectedAPI-overview"></a>

Adding MFA protection to API operations involves these tasks:

1. The administrator configures an AWS MFA device for each user who must make API requests that require MFA authentication. For more information, see [AWS Multi-factor authentication in IAM](id_credentials_mfa.md). 

1. The administrator creates policies for the users that include a `Condition` element that checks whether the user authenticated with an AWS MFA device.

1. The user calls one of the AWS STS API operations that support the MFA parameters: [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) or [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html). As part of the call, the user includes the device identifier for the device that's associated with the user. The user also includes the time-based one-time password (TOTP) that the device generates. In either case, the user gets back temporary security credentials that the user can then use to make additional requests to AWS.
**Note**  
MFA protection for a service's API operations is available only if the service supports temporary security credentials. For a list of these services, see [ Using Temporary Security Credentials to Access AWS](https://docs.aws.amazon.com/STS/latest/UsingSTS/UsingTokens.html).

If authorization fails, AWS returns an access denied error message (as it does for any unauthorized access). With MFA-protected API policies in place, AWS denies access to the API operations specified in the policies if the user attempts to call an API operation without valid MFA authentication. The operation is also denied if the time stamp of the request for the API operation is outside of the allowed range specified in the policy. The user must be reauthenticated with MFA by requesting new temporary security credentials with an MFA code and device serial number.

### IAM policies with MFA conditions
<a name="MFAProtectedAPI-policies"></a>

Policies with MFA conditions can be attached to the following:
+ An IAM user or group
+ A resource such as an Amazon S3 bucket, Amazon SQS queue, or Amazon SNS topic
+ The trust policy of an IAM role that can be assumed by a user

You can use an MFA condition in a policy to check the following properties:
+ Existence—To simply verify that the user did authenticate with MFA, check that the `aws:MultiFactorAuthPresent` key is `True` in a `Bool` condition. The key is only present when the user authenticates with short-term credentials. Long-term credentials, such as access keys, do not include this key.
+ Duration—If you want to grant access only within a specified time after MFA authentication, use a numeric condition type to compare the `aws:MultiFactorAuthAge` key's age to a value (such as 3600 seconds). Note that the `aws:MultiFactorAuthAge` key is not present if MFA was not used.

The following example shows the trust policy of an IAM role that includes an MFA condition to test for the existence of MFA authentication. With this policy, users from the AWS account specified in the `Principal` element (replace `ACCOUNT-B-ID` with a valid AWS account ID) can assume the role that this policy is attached to. However such users can only assume the role if the user is authenticated using MFA.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "ACCOUNT-B-ID"},
    "Action": "sts:AssumeRole",
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }
}
```

------

For more information on the condition types for MFA, see [AWS global condition context keys](reference_policies_condition-keys.md), [Numeric condition operators](reference_policies_elements_condition_operators.md#Conditions_Numeric), and [Condition operator to check existence of condition keys](reference_policies_elements_condition_operators.md#Conditions_Null). 

### Choosing between GetSessionToken and AssumeRole
<a name="scenarios"></a>

AWS STS provides two API operations that let users pass MFA information: `GetSessionToken` and `AssumeRole`. The API operation that the user calls to get temporary security credentials depends on which of the following scenarios applies. 

**Use `GetSessionToken` for the following scenarios:**
+ Call API operations that access resources in the same AWS account as the IAM user who makes the request. Note that temporary credentials from a `GetSessionToken` request can access IAM and AWS STS API operations *only* if you include MFA information in the request for credentials. Because temporary credentials returned by `GetSessionToken` include MFA information, you can check for MFA in individual API operations made by the credentials. 
+ Access to resources that are protected with resource-based policies that include an MFA condition.

The purpose of the `GetSessionToken` operation is to authenticate the user using MFA. You cannot use policies to control authentication operations.

**Use `AssumeRole` for the following scenarios:**
+ Call API operations that access resources in the same or a different AWS account. The API calls can include any IAM or AWS STS API. Note that to protect access you enforce MFA at the time when the user assumes the role. The temporary credentials returned by `AssumeRole` do not include MFA information in the context, so you cannot check individual API operations for MFA. This is why you must use `GetSessionToken` to restrict access to resources protected by resource-based policies.

**Note**  
AWS CloudTrail logs will contain MFA information when the IAM user sign in with MFA. If the IAM user assumes an IAM role, CloudTrail will also log `mfaAuthenticated: true` in the `sessionContext` attributes for actions performed using the assumed role. However, CloudTrail logging is separate from what IAM requires when API calls are made with the assumed role's credentials. For more information, see [CloudTrail userIdentity Element](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).

Details about how to implement these scenarios are provided later in this document.

### Important points about MFA-protected API access
<a name="MFAProtectedAPI-important-points"></a>

It's important to understand the following aspects of MFA protection for API operations:
+ MFA protection is available only with temporary security credentials, which must be obtained with `AssumeRole` or `GetSessionToken`. 
+ You cannot use MFA-protected API access with AWS account root user credentials.
+ You cannot use MFA-protected API access with U2F security keys.
+ Federated users cannot be assigned an MFA device for use with AWS services, so they cannot access AWS resources controlled by MFA. (See next point.) 
+ Other AWS STS API operations that return temporary credentials do not support MFA. For `AssumeRoleWithWebIdentity` and `AssumeRoleWithSAML`, the user is authenticated by an external provider and AWS cannot determine whether that provider required MFA. For `GetFederationToken`, MFA is not necessarily associated with a specific user. 
+ Similarly, long-term credentials (IAM user access keys and root user access keys) cannot be used with MFA-protected API access because they don't expire.
+ `AssumeRole` and `GetSessionToken` can also be called without MFA information. In that case, the caller gets back temporary security credentials, but the session information for those temporary credentials does not indicate that the user authenticated with MFA.
+ To establish MFA protection for API operations, you add MFA conditions to policies. A policy must include the `aws:MultiFactorAuthPresent` condition key to enforce the use of MFA. For cross-account delegation, the role's trust policy must include the condition key.
+ When you allow another AWS account to access resources in your account, the security of your resources depends on the configuration of the trusted account (the other account, not yours). This is true even when you require multi-factor authentication. Any identity in the trusted account that has permission to create virtual MFA devices can construct an MFA claim to satisfy that part of your role's trust policy. Before you allow members of another account access to your AWS resources that require multi-factor authentication, you should ensure that the trusted account's owner follows security best practices. For example, the trusted account should restrict access to sensitive API operations, such as MFA device-management API operations, to specific, trusted identities.
+ If a policy includes an MFA condition, a request is denied if users have not been MFA authenticated, or if they provide an invalid MFA device identifier or invalid TOTP.

## Scenario: MFA protection for cross-account delegation
<a name="MFAProtectedAPI-cross-account-delegation"></a>

In this scenario, you want to delegate access to IAM users in another account, but only if the users are authenticated with an AWS MFA device. For more information about cross-account delegation, see [Roles terms and concepts](id_roles.md#id_roles_terms-and-concepts). 

Imagine that you have account A (the trusting account that owns the resource to be accessed), with the IAM user Anaya, who has administrator permission. She wants to grant access to user Richard in account B (the trusted account), but wants to make sure that Richard is authenticated with MFA before he assumes the role. 

1. In the trusting account A, Anaya creates an IAM role named `CrossAccountRole` and sets the principal in the role's trust policy to the account ID of account B. The trust policy grants permission to the AWS STS `AssumeRole` action. Anaya also adds an MFA condition to the trust policy, as in the following example. 

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": {
       "Effect": "Allow",
       "Principal": {"AWS": "ACCOUNT-B-ID"},
       "Action": "sts:AssumeRole",
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }
   }
   ```

------

1. Anaya adds a permissions policy to the role that specifies what the role is allowed to do. The permissions policy for a role with MFA protection is no different than any other role-permission policy. The following example shows the policy that Anaya adds to the role; it allows an assuming user to perform any Amazon DynamoDB action on the table `Books` in account A. This policy also allows the `dynamodb:ListTables` action, which is required to perform actions in the console. 
**Note**  
The permissions policy does not include an MFA condition. It is important to understand that the MFA authentication is used only to determine whether a user can assume the role. Once the user has assumed the role, no further MFA checks are made. 

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "TableActions",
               "Effect": "Allow",
               "Action": "dynamodb:*",
               "Resource": "arn:aws:dynamodb:*:111122223333:table/Books"
           },
           {
               "Sid": "ListTables",
               "Effect": "Allow",
               "Action": "dynamodb:ListTables",
               "Resource": "*"
           }
       ]
   }
   ```

------

1. In trusted account B, the administrator makes sure that IAM user Richard is configured with an AWS MFA device and that he knows the ID of the device. The device ID is the serial number if it's a hardware MFA device, or the device's ARN if it's a virtual MFA device.

1. In account B, the administrator attaches the following policy to user Richard (or a group that he's a member of) that allows him to call the `AssumeRole` action. The resource is set to the ARN of the role that Anaya created in step 1. Notice that this policy does not contain an MFA condition.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "sts:AssumeRole"
               ],
               "Resource": [
                   "arn:aws:iam::111122223333:role/CrossAccountRole"
               ]
           }
       ]
   }
   ```

------

1. In account B, Richard (or an application that Richard is running) calls `AssumeRole`. The API call includes the ARN of the role to assume (`arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole`), the ID of the MFA device, and the current TOTP that Richard gets from his device. 

   When Richard calls `AssumeRole`, AWS determines whether he has valid credentials, including the requirement for MFA. If so, Richard successfully assumes the role and can perform any DynamoDB action on the table named `Books` in account A while using the role's temporary credentials. 

   For an example of a program that calls `AssumeRole`, see [Calling AssumeRole with MFA authentication](id_credentials_mfa_sample-code.md#MFAProtectedAPI-example-assumerole).

## Scenario: MFA protection for access to API operations in the current account
<a name="MFAProtectedAPI-user-mfa"></a>

In this scenario, you should ensure that a user in your AWS account can access sensitive API operations only when the user is authenticated using an AWS MFA device.

Imagine that you have account A that contains a group of developers who need to work with EC2 instances. Ordinary developers can work with the instances, but they are not granted permissions for the `ec2:StopInstances` or `ec2:TerminateInstances` actions. You want to limit those "destructive" privileged actions to just a few trusted users, so you add MFA protection to the policy that allows these sensitive Amazon EC2 actions. 

In this scenario, one of those trusted users is user Sofía. User Anaya is an administrator in account A. 

1. Anaya makes sure that Sofía is configured with an AWS MFA device and that Sofía knows the ID of the device. The device ID is the serial number if it's a hardware MFA device, or the device's ARN if it's a virtual MFA device. 

1. Anaya creates a group named `EC2-Admins` and adds user Sofía to the group.

1. Anaya attaches the following policy to the `EC2-Admins` group. This policy grants users permission to call the Amazon EC2 `StopInstances` and `TerminateInstances` actions only if the user has authenticated using MFA. 

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [{
       "Effect": "Allow",
       "Action": [
         "ec2:StopInstances",
         "ec2:TerminateInstances"
       ],
       "Resource": ["*"],
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }]
   }
   ```

------

1. 
**Note**  
For this policy to take effect, users must first sign out and then sign in again.

   If user Sofía needs to stop or terminate an Amazon EC2 instance, she (or an application that she is running) calls `GetSessionToken`. This API operation passes the ID of the MFA device and the current TOTP that Sofía gets from her device.

1. User Sofía (or an application that Sofía is using) uses the temporary credentials provided by `GetSessionToken` to call the Amazon EC2 `StopInstances` or `TerminateInstances` action. 

   For an example of a program that calls `GetSessionToken`, see [Calling GetSessionToken with MFA authentication](id_credentials_mfa_sample-code.md#MFAProtectedAPI-example-getsessiontoken) later in this document.

## Scenario: MFA protection for resources that have resource-based policies
<a name="MFAProtectedAPI-resource-policies"></a>

In this scenario, you are the owner of an S3 bucket, an SQS queue, or an SNS topic. You want to make sure that any user from any AWS account who accesses the resource is authenticated by an AWS MFA device. 

This scenario illustrates a way to provide cross-account MFA protection without requiring users to assume a role first. In this case, the user can access the resource if three conditions are met: The user must be authenticated by MFA, be able to get temporary security credentials from `GetSessionToken`, and be in an account that is trusted by the resource's policy. 

Imagine that you are in account A and you create an S3 bucket. You want to grant access to this bucket to users who are in several different AWS accounts, but only if those users are authenticated with MFA.

In this scenario, user Anaya is an administrator in account A. User Nikhil is an IAM user in account C.

1. In account A, Anaya creates a bucket named `Account-A-bucket`.

1. Anaya adds the bucket policy to the bucket. The policy allows any user in account A, account B, or account C to perform the Amazon S3 `PutObject` and `DeleteObject` actions in the bucket. The policy includes an MFA condition. 

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [{
       "Effect": "Allow",
       "Principal": {"AWS": [
         "ACCOUNT-A-ID",
         "ACCOUNT-B-ID",
         "ACCOUNT-C-ID"
       ]},
       "Action": [
         "s3:PutObject",
         "s3:DeleteObject"
       ],
       "Resource": ["arn:aws:s3:::ACCOUNT-A-BUCKET-NAME/*"],
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }]
   }
   ```

------
**Note**  
Amazon S3 offers an MFA Delete feature for *root* account access (only). You can enable Amazon S3 MFA Delete when you set the versioning state of the bucket. Amazon S3 MFA Delete cannot be applied to an IAM user, and is managed independently from MFA-protected API access. An IAM user with permissions to delete a bucket cannot delete a bucket with Amazon S3 MFA Delete enabled. For more information on Amazon S3 MFA Delete, see [MFA Delete](https://docs.aws.amazon.com/AmazonS3/latest/dev/MultiFactorAuthenticationDelete.html).

1. In account C, an administrator makes sure that user Nikhil is configured with an AWS MFA device and that he knows the ID of the device. The device ID is the serial number if it's a hardware MFA device, or the device's ARN if it's a virtual MFA device. 

1. In account C, Nikhil (or an application that he is running) calls `GetSessionToken`. The call includes the ID or ARN of the MFA device and the current TOTP that Nikhil gets from his device. 

1. Nikhil (or an application that he is using) uses the temporary credentials returned by `GetSessionToken` to call the Amazon S3 `PutObject` action to upload a file to `Account-A-bucket`. 

   For an example of a program that calls `GetSessionToken`, see [Calling GetSessionToken with MFA authentication](id_credentials_mfa_sample-code.md#MFAProtectedAPI-example-getsessiontoken) later in this document.
**Note**  
The temporary credentials that `AssumeRole` returns won't work in this case. Although the user can provide MFA information to assume a role, the temporary credentials returned by `AssumeRole` don't include the MFA information. That information is required in order to meet the MFA condition in the policy. 

# Sample code: Requesting credentials with multi-factor authentication
<a name="id_credentials_mfa_sample-code"></a>

The following examples show how to call `GetSessionToken` and `AssumeRole` operations and pass MFA authentication parameters. No permissions are required to call `GetSessionToken`, but you must have a policy that allows you to call `AssumeRole`. The credentials returned are then used to list all S3 buckets in the account.

## Calling GetSessionToken with MFA authentication
<a name="MFAProtectedAPI-example-getsessiontoken"></a>

The following example shows how to call `GetSessionToken` and pass MFA authentication information. The temporary security credentials returned by the `GetSessionToken` operation are then used to list all S3 buckets in the account.

The policy attached to the user who runs this code (or to a group that the user is in) provides the permissions for the returned temporary credentials. For this example code, the policy must grant the user permission to request the Amazon S3 `ListBuckets` operation. 

The following code examples show how to use `GetSessionToken`.

------
#### [ CLI ]

**AWS CLI**  
**To get a set of short term credentials for an IAM identity**  
The following `get-session-token` command retrieves a set of short-term credentials for the IAM identity making the call. The resulting credentials can be used for requests where multi-factor authentication (MFA) is required by policy. The credentials expire 15 minutes after they are generated.  

```
aws sts get-session-token \
    --duration-seconds 900 \
    --serial-number "YourMFADeviceSerialNumber" \
    --token-code 123456
```
Output:  

```
{
    "Credentials": {
        "AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY",
        "SessionToken": "AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/LTo6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3zrkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtpZ3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE",
        "Expiration": "2020-05-19T18:06:10+00:00"
    }
}
```
For more information, see [Requesting Temporary Security Credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_getsessiontoken) in the *AWS IAM User Guide*.  
+  For API details, see [GetSessionToken](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/get-session-token.html) in *AWS CLI Command Reference*. 

------
#### [ PowerShell ]

**Tools for PowerShell V4**  
**Example 1: Returns an `Amazon.RuntimeAWSCredentials` instance containing temporary credentials valid for a set period of time. The credentials used to request temporary credentials are inferred from the current shell defaults. To specify other credentials, use the -ProfileName or -AccessKey/-SecretKey parameters.**  

```
Get-STSSessionToken
```
**Output:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**Example 2: Returns an `Amazon.RuntimeAWSCredentials` instance containing temporary credentials valid for one hour. The credentials used to make the request are obtained from the specified profile.**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile
```
**Output:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**Example 3: Returns an `Amazon.RuntimeAWSCredentials` instance containing temporary credentials valid for one hour using the identification number of the MFA device associated with the account whose credentials are specified in the profile 'myprofilename' and the value provided by the device.**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile -SerialNumber YourMFADeviceSerialNumber -TokenCode 123456
```
**Output:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
+  For API details, see [GetSessionToken](https://docs.aws.amazon.com/powershell/v4/reference) in *AWS Tools for PowerShell Cmdlet Reference (V4)*. 

**Tools for PowerShell V5**  
**Example 1: Returns an `Amazon.RuntimeAWSCredentials` instance containing temporary credentials valid for a set period of time. The credentials used to request temporary credentials are inferred from the current shell defaults. To specify other credentials, use the -ProfileName or -AccessKey/-SecretKey parameters.**  

```
Get-STSSessionToken
```
**Output:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**Example 2: Returns an `Amazon.RuntimeAWSCredentials` instance containing temporary credentials valid for one hour. The credentials used to make the request are obtained from the specified profile.**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile
```
**Output:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**Example 3: Returns an `Amazon.RuntimeAWSCredentials` instance containing temporary credentials valid for one hour using the identification number of the MFA device associated with the account whose credentials are specified in the profile 'myprofilename' and the value provided by the device.**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile -SerialNumber YourMFADeviceSerialNumber -TokenCode 123456
```
**Output:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
+  For API details, see [GetSessionToken](https://docs.aws.amazon.com/powershell/v5/reference) in *AWS Tools for PowerShell Cmdlet Reference (V5)*. 

------
#### [ Python ]

**SDK for Python (Boto3)**  
 There's more on GitHub. Find the complete example and learn how to set up and run in the [AWS Code Examples Repository](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python/example_code/sts#code-examples). 
Get a session token by passing an MFA token and use it to list Amazon S3 buckets for the account.  

```
def list_buckets_with_session_token_with_mfa(mfa_serial_number, mfa_totp, sts_client):
    """
    Gets a session token with MFA credentials and uses the temporary session
    credentials to list Amazon S3 buckets.

    Requires an MFA device serial number and token.

    :param mfa_serial_number: The serial number of the MFA device. For a virtual MFA
                              device, this is an Amazon Resource Name (ARN).
    :param mfa_totp: A time-based, one-time password issued by the MFA device.
    :param sts_client: A Boto3 STS instance that has permission to assume the role.
    """
    if mfa_serial_number is not None:
        response = sts_client.get_session_token(
            SerialNumber=mfa_serial_number, TokenCode=mfa_totp
        )
    else:
        response = sts_client.get_session_token()
    temp_credentials = response["Credentials"]

    s3_resource = boto3.resource(
        "s3",
        aws_access_key_id=temp_credentials["AccessKeyId"],
        aws_secret_access_key=temp_credentials["SecretAccessKey"],
        aws_session_token=temp_credentials["SessionToken"],
    )

    print(f"Buckets for the account:")
    for bucket in s3_resource.buckets.all():
        print(bucket.name)
```
+  For API details, see [GetSessionToken](https://docs.aws.amazon.com/goto/boto3/sts-2011-06-15/GetSessionToken) in *AWS SDK for Python (Boto3) API Reference*. 

------

## Calling AssumeRole with MFA authentication
<a name="MFAProtectedAPI-example-assumerole"></a>

The following examples show how to call `AssumeRole` and pass MFA authentication information. The temporary security credentials returned by `AssumeRole` are then used to list all Amazon S3 buckets in the account.

For more information about this scenario, see [Scenario: MFA protection for cross-account delegation](id_credentials_mfa_configure-api-require.md#MFAProtectedAPI-cross-account-delegation). 

The following code examples show how to use `AssumeRole`.

------
#### [ .NET ]

**SDK for .NET**  
 There's more on GitHub. Find the complete example and learn how to set up and run in the [AWS Code Examples Repository](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3/STS#code-examples). 

```
using System;
using System.Threading.Tasks;
using Amazon;
using Amazon.SecurityToken;
using Amazon.SecurityToken.Model;

namespace AssumeRoleExample
{
    class AssumeRole
    {
        /// <summary>
        /// This example shows how to use the AWS Security Token
        /// Service (AWS STS) to assume an IAM role.
        ///
        /// NOTE: It is important that the role that will be assumed has a
        /// trust relationship with the account that will assume the role.
        ///
        /// Before you run the example, you need to create the role you want to
        /// assume and have it trust the IAM account that will assume that role.
        ///
        /// See https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html
        /// for help in working with roles.
        /// </summary>

        // A region property may be used if the profile or credentials loaded do not specify a region,
        // or to use a specific region.
        private static readonly RegionEndpoint REGION = RegionEndpoint.USWest2;

        static async Task Main()
        {
            // Create the SecurityToken client and then display the identity of the
            // default user.
            var roleArnToAssume = "arn:aws:iam::123456789012:role/testAssumeRole";

            var client = new Amazon.SecurityToken.AmazonSecurityTokenServiceClient(REGION);

            // Get and display the information about the identity of the default user.
            var callerIdRequest = new GetCallerIdentityRequest();
            var caller = await client.GetCallerIdentityAsync(callerIdRequest);
            Console.WriteLine($"Original Caller: {caller.Arn}");

            // Create the request to use with the AssumeRoleAsync call.
            var assumeRoleReq = new AssumeRoleRequest()
            {
                DurationSeconds = 1600,
                RoleSessionName = "Session1",
                RoleArn = roleArnToAssume
            };

            var assumeRoleRes = await client.AssumeRoleAsync(assumeRoleReq);

            // Now create a new client based on the credentials of the caller assuming the role.
            var client2 = new AmazonSecurityTokenServiceClient(credentials: assumeRoleRes.Credentials, REGION);

            // Get and display information about the caller that has assumed the defined role.
            var caller2 = await client2.GetCallerIdentityAsync(callerIdRequest);
            Console.WriteLine($"AssumedRole Caller: {caller2.Arn}");
        }
    }
}
```
+  For API details, see [AssumeRole](https://docs.aws.amazon.com/goto/DotNetSDKV3/sts-2011-06-15/AssumeRole) in *AWS SDK for .NET API Reference*. 

------
#### [ Bash ]

**AWS CLI with Bash script**  
 There's more on GitHub. Find the complete example and learn how to set up and run in the [AWS Code Examples Repository](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/aws-cli/bash-linux/iam#code-examples). 

```
###############################################################################
# function iecho
#
# This function enables the script to display the specified text only if
# the global variable $VERBOSE is set to true.
###############################################################################
function iecho() {
  if [[ $VERBOSE == true ]]; then
    echo "$@"
  fi
}

###############################################################################
# function errecho
#
# This function outputs everything sent to it to STDERR (standard error output).
###############################################################################
function errecho() {
  printf "%s\n" "$*" 1>&2
}

###############################################################################
# function sts_assume_role
#
# This function assumes a role in the AWS account and returns the temporary
#  credentials.
#
# Parameters:
#       -n role_session_name -- The name of the session.
#       -r role_arn -- The ARN of the role to assume.
#
# Returns:
#       [access_key_id, secret_access_key, session_token]
#     And:
#       0 - If successful.
#       1 - If an error occurred.
###############################################################################
function sts_assume_role() {
  local role_session_name role_arn response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function sts_assume_role"
    echo "Assumes a role in the AWS account and returns the temporary credentials:"
    echo "  -n role_session_name -- The name of the session."
    echo "  -r role_arn -- The ARN of the role to assume."
    echo ""
  }

  while getopts n:r:h option; do
    case "${option}" in
      n) role_session_name=${OPTARG} ;;
      r) role_arn=${OPTARG} ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done

  response=$(aws sts assume-role \
    --role-session-name "$role_session_name" \
    --role-arn "$role_arn" \
    --output text \
    --query "Credentials.[AccessKeyId, SecretAccessKey, SessionToken]")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-role operation failed.\n$response"
    return 1
  fi

  echo "$response"

  return 0
}
```
+  For API details, see [AssumeRole](https://docs.aws.amazon.com/goto/aws-cli/sts-2011-06-15/AssumeRole) in *AWS CLI Command Reference*. 

------
#### [ C\$1\$1 ]

**SDK for C\$1\$1**  
 There's more on GitHub. Find the complete example and learn how to set up and run in the [AWS Code Examples Repository](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp/example_code/sts#code-examples). 

```
bool AwsDoc::STS::assumeRole(const Aws::String &roleArn,
                             const Aws::String &roleSessionName,
                             const Aws::String &externalId,
                             Aws::Auth::AWSCredentials &credentials,
                             const Aws::Client::ClientConfiguration &clientConfig) {
    Aws::STS::STSClient sts(clientConfig);
    Aws::STS::Model::AssumeRoleRequest sts_req;

    sts_req.SetRoleArn(roleArn);
    sts_req.SetRoleSessionName(roleSessionName);
    sts_req.SetExternalId(externalId);

    const Aws::STS::Model::AssumeRoleOutcome outcome = sts.AssumeRole(sts_req);

    if (!outcome.IsSuccess()) {
        std::cerr << "Error assuming IAM role. " <<
                  outcome.GetError().GetMessage() << std::endl;
    }
    else {
        std::cout << "Credentials successfully retrieved." << std::endl;
        const Aws::STS::Model::AssumeRoleResult result = outcome.GetResult();
        const Aws::STS::Model::Credentials &temp_credentials = result.GetCredentials();

        // Store temporary credentials in return argument.
        // Note: The credentials object returned by assumeRole differs
        // from the AWSCredentials object used in most situations.
        credentials.SetAWSAccessKeyId(temp_credentials.GetAccessKeyId());
        credentials.SetAWSSecretKey(temp_credentials.GetSecretAccessKey());
        credentials.SetSessionToken(temp_credentials.GetSessionToken());
    }

    return outcome.IsSuccess();
}
```
+  For API details, see [AssumeRole](https://docs.aws.amazon.com/goto/SdkForCpp/sts-2011-06-15/AssumeRole) in *AWS SDK for C\$1\$1 API Reference*. 

------
#### [ CLI ]

**AWS CLI**  
**To assume a role**  
The following `assume-role` command retrieves a set of short-term credentials for the IAM role `s3-access-example`.  

```
aws sts assume-role \
    --role-arn arn:aws:iam::123456789012:role/xaccounts3access \
    --role-session-name s3-access-example
```
Output:  

```
{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA3XFRBF535PLBIFPI4:s3-access-example",
        "Arn": "arn:aws:sts::123456789012:assumed-role/xaccounts3access/s3-access-example"
    },
    "Credentials": {
        "SecretAccessKey": "9drTJvcXLB89EXAMPLELB8923FB892xMFI",
        "SessionToken": "AQoXdzELDDY//////////wEaoAK1wvxJY12r2IrDFT2IvAzTCn3zHoZ7YNtpiQLF0MqZye/qwjzP2iEXAMPLEbw/m3hsj8VBTkPORGvr9jM5sgP+w9IZWZnU+LWhmg+a5fDi2oTGUYcdg9uexQ4mtCHIHfi4citgqZTgco40Yqr4lIlo4V2b2Dyauk0eYFNebHtYlFVgAUj+7Indz3LU0aTWk1WKIjHmmMCIoTkyYp/k7kUG7moeEYKSitwQIi6Gjn+nyzM+PtoA3685ixzv0R7i5rjQi0YE0lf1oeie3bDiNHncmzosRM6SFiPzSvp6h/32xQuZsjcypmwsPSDtTPYcs0+YN/8BRi2/IcrxSpnWEXAMPLEXSDFTAQAM6Dl9zR0tXoybnlrZIwMLlMi1Kcgo5OytwU=",
        "Expiration": "2016-03-15T00:05:07Z",
        "AccessKeyId": "ASIAJEXAMPLEXEG2JICEA"
    }
}
```
The output of the command contains an access key, secret key, and session token that you can use to authenticate to AWS.  
For AWS CLI use, you can set up a named profile associated with a role. When you use the profile, the AWS CLI will call assume-role and manage credentials for you. For more information, see [Use an IAM role in the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html) in the *AWS CLI User Guide*.  
+  For API details, see [AssumeRole](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-role.html) in *AWS CLI Command Reference*. 

------
#### [ Java ]

**SDK for Java 2.x**  
 There's more on GitHub. Find the complete example and learn how to set up and run in the [AWS Code Examples Repository](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2/example_code/sts#code-examples). 

```
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.sts.StsClient;
import software.amazon.awssdk.services.sts.model.AssumeRoleRequest;
import software.amazon.awssdk.services.sts.model.StsException;
import software.amazon.awssdk.services.sts.model.AssumeRoleResponse;
import software.amazon.awssdk.services.sts.model.Credentials;
import java.time.Instant;
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;
import java.time.format.FormatStyle;
import java.util.Locale;

/**
 * To make this code example work, create a Role that you want to assume.
 * Then define a Trust Relationship in the AWS Console. You can use this as an
 * example:
 *
 * {
 * "Version":"2012-10-17",		 	 	 
 * "Statement": [
 * {
 * "Effect": "Allow",
 * "Principal": {
 * "AWS": "<Specify the ARN of your IAM user you are using in this code example>"
 * },
 * "Action": "sts:AssumeRole"
 * }
 * ]
 * }
 *
 * For more information, see "Editing the Trust Relationship for an Existing
 * Role" in the AWS Directory Service guide.
 *
 * Also, set up your development environment, including your credentials.
 *
 * For information, see this documentation topic:
 *
 * https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html
 */
public class AssumeRole {
    public static void main(String[] args) {
        final String usage = """

                Usage:
                    <roleArn> <roleSessionName>\s

                Where:
                    roleArn - The Amazon Resource Name (ARN) of the role to assume (for example, arn:aws:iam::000008047983:role/s3role).\s
                    roleSessionName - An identifier for the assumed role session (for example, mysession).\s
                """;

        if (args.length != 2) {
            System.out.println(usage);
            System.exit(1);
        }

        String roleArn = args[0];
        String roleSessionName = args[1];
        Region region = Region.US_EAST_1;
        StsClient stsClient = StsClient.builder()
                .region(region)
                .build();

        assumeGivenRole(stsClient, roleArn, roleSessionName);
        stsClient.close();
    }

    public static void assumeGivenRole(StsClient stsClient, String roleArn, String roleSessionName) {
        try {
            AssumeRoleRequest roleRequest = AssumeRoleRequest.builder()
                    .roleArn(roleArn)
                    .roleSessionName(roleSessionName)
                    .build();

            AssumeRoleResponse roleResponse = stsClient.assumeRole(roleRequest);
            Credentials myCreds = roleResponse.credentials();

            // Display the time when the temp creds expire.
            Instant exTime = myCreds.expiration();
            String tokenInfo = myCreds.sessionToken();

            // Convert the Instant to readable date.
            DateTimeFormatter formatter = DateTimeFormatter.ofLocalizedDateTime(FormatStyle.SHORT)
                    .withLocale(Locale.US)
                    .withZone(ZoneId.systemDefault());

            formatter.format(exTime);
            System.out.println("The token " + tokenInfo + "  expires on " + exTime);

        } catch (StsException e) {
            System.err.println(e.getMessage());
            System.exit(1);
        }
    }
}
```
+  For API details, see [AssumeRole](https://docs.aws.amazon.com/goto/SdkForJavaV2/sts-2011-06-15/AssumeRole) in *AWS SDK for Java 2.x API Reference*. 

------
#### [ JavaScript ]

**SDK for JavaScript (v3)**  
 There's more on GitHub. Find the complete example and learn how to set up and run in the [AWS Code Examples Repository](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3/example_code/sts#code-examples). 
Create the client.  

```
import { STSClient } from "@aws-sdk/client-sts";
// Set the AWS Region.
const REGION = "us-east-1";
// Create an AWS STS service client object.
export const client = new STSClient({ region: REGION });
```
Assume the IAM role.  

```
import { AssumeRoleCommand } from "@aws-sdk/client-sts";

import { client } from "../libs/client.js";

export const main = async () => {
  try {
    // Returns a set of temporary security credentials that you can use to
    // access Amazon Web Services resources that you might not normally
    // have access to.
    const command = new AssumeRoleCommand({
      // The Amazon Resource Name (ARN) of the role to assume.
      RoleArn: "ROLE_ARN",
      // An identifier for the assumed role session.
      RoleSessionName: "session1",
      // The duration, in seconds, of the role session. The value specified
      // can range from 900 seconds (15 minutes) up to the maximum session
      // duration set for the role.
      DurationSeconds: 900,
    });
    const response = await client.send(command);
    console.log(response);
  } catch (err) {
    console.error(err);
  }
};
```
+  For API details, see [AssumeRole](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/sts/command/AssumeRoleCommand) in *AWS SDK for JavaScript API Reference*. 

**SDK for JavaScript (v2)**  
 There's more on GitHub. Find the complete example and learn how to set up and run in the [AWS Code Examples Repository](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascript/example_code/sts#code-examples). 

```
// Load the AWS SDK for Node.js
const AWS = require("aws-sdk");
// Set the region
AWS.config.update({ region: "REGION" });

var roleToAssume = {
  RoleArn: "arn:aws:iam::123456789012:role/RoleName",
  RoleSessionName: "session1",
  DurationSeconds: 900,
};
var roleCreds;

// Create the STS service object
var sts = new AWS.STS({ apiVersion: "2011-06-15" });

//Assume Role
sts.assumeRole(roleToAssume, function (err, data) {
  if (err) console.log(err, err.stack);
  else {
    roleCreds = {
      accessKeyId: data.Credentials.AccessKeyId,
      secretAccessKey: data.Credentials.SecretAccessKey,
      sessionToken: data.Credentials.SessionToken,
    };
    stsGetCallerIdentity(roleCreds);
  }
});

//Get Arn of current identity
function stsGetCallerIdentity(creds) {
  var stsParams = { credentials: creds };
  // Create STS service object
  var sts = new AWS.STS(stsParams);

  sts.getCallerIdentity({}, function (err, data) {
    if (err) {
      console.log(err, err.stack);
    } else {
      console.log(data.Arn);
    }
  });
}
```
+  For API details, see [AssumeRole](https://docs.aws.amazon.com/goto/AWSJavaScriptSDK/sts-2011-06-15/AssumeRole) in *AWS SDK for JavaScript API Reference*. 

------
#### [ PowerShell ]

**Tools for PowerShell V4**  
**Example 1: Returns a set of temporary credentials (access key, secret key and session token) that can be used for one hour to access AWS resources that the requesting user might not normally have access to. The returned credentials have the permissions that are allowed by the access policy of the role being assumed and the policy that was supplied (you cannot use the supplied policy to grant permissions in excess of those defined by the access policy of the role being assumed).**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -Policy "...JSON policy..." -DurationInSeconds 3600
```
**Example 2: Returns a set of temporary credentials, valid for one hour, that have the same permissions that are defined in the access policy of the role being assumed.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600
```
**Example 3: Returns a set of temporary credentials supplying the serial number and generated token from an MFA associated with the user credentials used to execute the cmdlet.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -SerialNumber "GAHT12345678" -TokenCode "123456"
```
**Example 4: Returns a set of temporary credentials that have assumed a role defined in a customer account. For each role that the third party can assume, the customer account must create a role using an identifier that must be passed in the -ExternalId parameter each time the role is assumed.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -ExternalId "ABC123"
```
+  For API details, see [AssumeRole](https://docs.aws.amazon.com/powershell/v4/reference) in *AWS Tools for PowerShell Cmdlet Reference (V4)*. 

**Tools for PowerShell V5**  
**Example 1: Returns a set of temporary credentials (access key, secret key and session token) that can be used for one hour to access AWS resources that the requesting user might not normally have access to. The returned credentials have the permissions that are allowed by the access policy of the role being assumed and the policy that was supplied (you cannot use the supplied policy to grant permissions in excess of those defined by the access policy of the role being assumed).**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -Policy "...JSON policy..." -DurationInSeconds 3600
```
**Example 2: Returns a set of temporary credentials, valid for one hour, that have the same permissions that are defined in the access policy of the role being assumed.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600
```
**Example 3: Returns a set of temporary credentials supplying the serial number and generated token from an MFA associated with the user credentials used to execute the cmdlet.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -SerialNumber "GAHT12345678" -TokenCode "123456"
```
**Example 4: Returns a set of temporary credentials that have assumed a role defined in a customer account. For each role that the third party can assume, the customer account must create a role using an identifier that must be passed in the -ExternalId parameter each time the role is assumed.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -ExternalId "ABC123"
```
+  For API details, see [AssumeRole](https://docs.aws.amazon.com/powershell/v5/reference) in *AWS Tools for PowerShell Cmdlet Reference (V5)*. 

------
#### [ Python ]

**SDK for Python (Boto3)**  
 There's more on GitHub. Find the complete example and learn how to set up and run in the [AWS Code Examples Repository](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python/example_code/sts#code-examples). 
Assume an IAM role that requires an MFA token and use temporary credentials to list Amazon S3 buckets for the account.  

```
def list_buckets_from_assumed_role_with_mfa(
    assume_role_arn, session_name, mfa_serial_number, mfa_totp, sts_client
):
    """
    Assumes a role from another account and uses the temporary credentials from
    that role to list the Amazon S3 buckets that are owned by the other account.
    Requires an MFA device serial number and token.

    The assumed role must grant permission to list the buckets in the other account.

    :param assume_role_arn: The Amazon Resource Name (ARN) of the role that
                            grants access to list the other account's buckets.
    :param session_name: The name of the STS session.
    :param mfa_serial_number: The serial number of the MFA device. For a virtual MFA
                              device, this is an ARN.
    :param mfa_totp: A time-based, one-time password issued by the MFA device.
    :param sts_client: A Boto3 STS instance that has permission to assume the role.
    """
    response = sts_client.assume_role(
        RoleArn=assume_role_arn,
        RoleSessionName=session_name,
        SerialNumber=mfa_serial_number,
        TokenCode=mfa_totp,
    )
    temp_credentials = response["Credentials"]
    print(f"Assumed role {assume_role_arn} and got temporary credentials.")

    s3_resource = boto3.resource(
        "s3",
        aws_access_key_id=temp_credentials["AccessKeyId"],
        aws_secret_access_key=temp_credentials["SecretAccessKey"],
        aws_session_token=temp_credentials["SessionToken"],
    )

    print(f"Listing buckets for the assumed role's account:")
    for bucket in s3_resource.buckets.all():
        print(bucket.name)
```
+  For API details, see [AssumeRole](https://docs.aws.amazon.com/goto/boto3/sts-2011-06-15/AssumeRole) in *AWS SDK for Python (Boto3) API Reference*. 

------
#### [ Ruby ]

**SDK for Ruby**  
 There's more on GitHub. Find the complete example and learn how to set up and run in the [AWS Code Examples Repository](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby/example_code/iam#code-examples). 

```
  # Creates an AWS Security Token Service (AWS STS) client with specified credentials.
  # This is separated into a factory function so that it can be mocked for unit testing.
  #
  # @param key_id [String] The ID of the access key used by the STS client.
  # @param key_secret [String] The secret part of the access key used by the STS client.
  def create_sts_client(key_id, key_secret)
    Aws::STS::Client.new(access_key_id: key_id, secret_access_key: key_secret)
  end

  # Gets temporary credentials that can be used to assume a role.
  #
  # @param role_arn [String] The ARN of the role that is assumed when these credentials
  #                          are used.
  # @param sts_client [AWS::STS::Client] An AWS STS client.
  # @return [Aws::AssumeRoleCredentials] The credentials that can be used to assume the role.
  def assume_role(role_arn, sts_client)
    credentials = Aws::AssumeRoleCredentials.new(
      client: sts_client,
      role_arn: role_arn,
      role_session_name: 'create-use-assume-role-scenario'
    )
    @logger.info("Assumed role '#{role_arn}', got temporary credentials.")
    credentials
  end
```
+  For API details, see [AssumeRole](https://docs.aws.amazon.com/goto/SdkForRubyV3/sts-2011-06-15/AssumeRole) in *AWS SDK for Ruby API Reference*. 

------
#### [ Rust ]

**SDK for Rust**  
 There's more on GitHub. Find the complete example and learn how to set up and run in the [AWS Code Examples Repository](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1/examples/sts/#code-examples). 

```
async fn assume_role(config: &SdkConfig, role_name: String, session_name: Option<String>) {
    let provider = aws_config::sts::AssumeRoleProvider::builder(role_name)
        .session_name(session_name.unwrap_or("rust_sdk_example_session".into()))
        .configure(config)
        .build()
        .await;

    let local_config = aws_config::from_env()
        .credentials_provider(provider)
        .load()
        .await;
    let client = Client::new(&local_config);
    let req = client.get_caller_identity();
    let resp = req.send().await;
    match resp {
        Ok(e) => {
            println!("UserID :               {}", e.user_id().unwrap_or_default());
            println!("Account:               {}", e.account().unwrap_or_default());
            println!("Arn    :               {}", e.arn().unwrap_or_default());
        }
        Err(e) => println!("{:?}", e),
    }
}
```
+  For API details, see [AssumeRole](https://docs.rs/aws-sdk-sts/latest/aws_sdk_sts/client/struct.Client.html#method.assume_role) in *AWS SDK for Rust API reference*. 

------
#### [ Swift ]

**SDK for Swift**  
 There's more on GitHub. Find the complete example and learn how to set up and run in the [AWS Code Examples Repository](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/swift/example_code/iam#code-examples). 

```
import AWSSTS

    public func assumeRole(role: IAMClientTypes.Role, sessionName: String)
        async throws -> STSClientTypes.Credentials
    {
        let input = AssumeRoleInput(
            roleArn: role.arn,
            roleSessionName: sessionName
        )
        do {
            let output = try await stsClient.assumeRole(input: input)

            guard let credentials = output.credentials else {
                throw ServiceHandlerError.authError
            }

            return credentials
        } catch {
            print("Error assuming role: ", dump(error))
            throw error
        }
    }
```
+  For API details, see [AssumeRole](https://sdk.amazonaws.com/swift/api/awssts/latest/documentation/awssts/stsclient/assumerole(input:)) in *AWS SDK for Swift API reference*. 

------

# Service-specific credentials for IAM users
<a name="id_credentials_service-specific-creds"></a>

Service-specific credentials are specialized authentication mechanisms designed for specific AWS services. These credentials provide simplified authentication compared to standard AWS credentials, and are tailored to the authentication requirements of individual AWS services. Unlike access keys, which can be used across multiple AWS services, service-specific credentials are designed for use with only the service for which they were created. This targeted approach enhances security by limiting the scope of the credentials.

Service-specific credentials typically consist of a user name and password pair or specialized API keys that are formatted according to the requirements of the specific service. When you create service-specific credentials, they are active by default and can be used immediately. You can have a maximum of two sets of service-specific credentials for each supported service per IAM user. This limit allows you to maintain one active set while rotating to a new set when needed. AWS currently supports service-specific credentials for the following services:

## When to use service-specific credentials
<a name="id_credentials_service-specific-creds-usecase"></a>

Service-specific credentials are intended for compatibility with third-party libraries, SDKs, tools, or applications that are not natively compatible with AWS credentials, AWS SDKs, or AWS APIs. Such use cases include migrating to AWS services from self-hosted infrastructure or from services hosted by other providers.

When starting from scratch, and wherever possible, we recommend that you use AWS temporary credentials, such as those provided by an IAM role, to authenticate with an AWS service using an AWS SDK or a library that supports AWS temporary credentials.

## Rotating service-specific credentials
<a name="id_credentials_service-specific-creds-rotation"></a>

As a security best practice, rotate service-specific credentials regularly. To rotate credentials without disrupting your applications:

1. Create a second set of service-specific credentials for the same service and IAM user

1. Update all applications to use the new credentials and verify they work correctly

1. Change the status of the original credentials to "Inactive"

1. Verify that all applications are still functioning properly

1. Delete the inactive service-specific credentials when you're confident they're no longer needed

## Monitoring service-specific credentials
<a name="id_credentials_service-specific-creds-monitoring"></a>

You can use AWS CloudTrail to monitor the use of service-specific credentials in your AWS account. To view CloudTrail events related to service-specific credential usage, review the CloudTrail logs for events from the service where the credentials are used. For more information, see [Logging IAM and AWS STS API calls with AWS CloudTrail](cloudtrail-integration.md).

For additional security, consider setting up CloudWatch alarms to notify you of specific credential usage patterns that might indicate unauthorized access or other security concerns. For more information, see [Monitoring CloudTrail Log Files with Amazon CloudWatch Logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html) in the *AWS CloudTrail User Guide*.

The following topics provide information about service-specific credentials.

**Topics**
+ [

## When to use service-specific credentials
](#id_credentials_service-specific-creds-usecase)
+ [

## Rotating service-specific credentials
](#id_credentials_service-specific-creds-rotation)
+ [

## Monitoring service-specific credentials
](#id_credentials_service-specific-creds-monitoring)
+ [

# API keys for AWS services
](id_credentials_api_keys_for_aws_services.md)
+ [

# Use IAM with Amazon Keyspaces (for Apache Cassandra)
](id_credentials_keyspaces.md)

# API keys for AWS services
<a name="id_credentials_api_keys_for_aws_services"></a>

You can access AWS services through the AWS Management Console and programmatically using the AWS CLI or AWS API. When making programmatic requests to services like Amazon Bedrock and Amazon CloudWatch Logs, you can authenticate using IAM credentials (for example, temporary security credentials or long-term access keys) or API keys. There are two types of API keys:
+ **Long-term API keys** – Long-term API keys are associated with an IAM user and generated using IAM [service-specific credentials](id_credentials_service-specific-creds.md). These credentials are designed for use with only a single AWS service, enhancing security by limiting credential scope. You can set an expiration time for the long-term API key. You can use the IAM or service-specific console (for example, Amazon Bedrock or CloudWatch Logs console), the AWS CLI, or AWS API to generate long-term API keys.
+ **Short-term API keys** (only supported by Amazon Bedrock) – A short-term API key is a pre-signed URL that uses AWS Signature Version 4. Short-term API keys share the same permissions and expiration as the credentials of the identity that generates the API key and are valid for up to 12 hours or the remaining time of your console session, whichever is shorter. You can use the Amazon Bedrock console, Python package `aws-bedrock-token-generator`, and packages for other programming languages to generate short-term API keys. For more information, see [Generate Amazon Bedrock API keys for easy access to the Amazon Bedrock API](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html) in the *Amazon Bedrock User Guide*.

**Note**  
Long-term API keys have a higher security risk compared to short-term API keys. We recommend using short-term API keys or temporary security credentials when possible. If you use long-term API keys, we recommend implementing regular key rotation practices.

## Supported services
<a name="id_credentials_api_keys_supported_services"></a>

The following table lists the AWS services that support API keys and the type of API key each service supports.


| \$1 | Service | Long-term API keys | Short-term API keys | Managed policy auto-attached | 
| --- | --- | --- | --- | --- | 
| 1 | Amazon Bedrock | Yes | Yes | [AmazonBedrockLimitedAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonBedrockLimitedAccess.html) | 
| 2 | Amazon CloudWatch Logs | Yes | N/A | [CloudWatchLogsAPIKeyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchLogsAPIKeyAccess.html) | 

When you generate a long-term API key for a service, the corresponding AWS managed policy is automatically attached to the IAM user, granting access to core operations for that service. If you require additional access, you can modify the permissions for the IAM user. For information about modifying permissions, see [Adding and removing IAM identity permissions](access_policies_manage-attach-detach.md). For more information on how to use an Amazon Bedrock key, see [Use an Amazon Bedrock API key](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys-use.html) in the *Amazon Bedrock User Guide*. For more information on how to use bearer token for Amazon CloudWatch Logs, see [Bearer token authentication](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_HTTP_Endpoints_BearerTokenAuth.html) in the *CloudWatch Logs User Guide*.

## Prerequisites for long-term API keys
<a name="id_credentials_api_keys_prerequisites"></a>

Before you can generate a long-term API key in the IAM console, you must meet these prerequisites:
+ An IAM user to associate with the long-term API key. For instructions on creating an IAM user, see [Create an IAM user in your AWS account](id_users_create.md).
+ You must have the following IAM policy permissions to manage service-specific credentials for an IAM user. The example policy grants permission to create, list, update, delete, and reset service-specific credentials. Replace the `username` value in the Resource element with the name of the IAM user you will generate long-term API keys for:

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Sid": "ManageBedrockServiceSpecificCredentials",
              "Effect": "Allow",
              "Action": [
                  "iam:CreateServiceSpecificCredential",
                  "iam:ListServiceSpecificCredentials",
                  "iam:UpdateServiceSpecificCredential",
                  "iam:DeleteServiceSpecificCredential",
                  "iam:ResetServiceSpecificCredential"
              ],
              "Resource": "arn:aws:iam::*:user/username"
          }
      ]
  }
  ```

------

## Generating a long-term API key (console)
<a name="id_credentials_api_keys_console_create"></a>

**To generate a long-term API key for a specific service in the IAM console**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane of the IAM console, choose **Users**.

1. Choose the IAM user you want to generate a long-term API key for.

1. Choose the **Security credentials** tab.

1. In the **API keys** section, choose **Generate API key**.

1. From the **AWS service** dropdown list, choose the service that you want the API key to authenticate to.

1. For **API key expiration**, do one of the following:
   + Choose an API key expiration duration of **1**, **5**, **30**, **90**, or **365** days.
   + Choose **Custom duration** to specify a custom API key expiration date.
   + Choose **Never expires** (not recommended).

1. Choose **Generate API key**.

1. Copy or download your API key. This is the only time you can view the API key value.
**Important**  
Store your API key securely. After you close the dialog box, you cannot retrieve the API key again. If you lose or forget your API key, you cannot retrieve it. Instead, generate a new API key and make the old key inactive.

## Generating a long-term API key (AWS CLI)
<a name="id_credentials_api_keys_cli_create"></a>

To generate a long-term API key using the AWS CLI, use the following steps:

1. Create an IAM user that will be used with Amazon Bedrock or Amazon CloudWatch Logs using the [ create-user](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-user.html) command:

   ```
   aws iam create-user \
       --user-name APIKeyUser_1
   ```

1. Attach the AWS managed policy to the IAM user using the [ attach-user-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/attach-user-policy.html) command.

   For Amazon Bedrock:

   ```
   aws iam attach-user-policy --user-name APIKeyUser_1 \
       --policy-arn arn:aws:iam::aws:policy/AmazonBedrockLimitedAccess
   ```

   For Amazon CloudWatch Logs:

   ```
   aws iam attach-user-policy --user-name APIKeyUser_1 \
       --policy-arn arn:aws:iam::aws:policy/CloudWatchLogsAPIKeyAccess
   ```

1. Generate the long-term API key using the [ create-service-specific-credential](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-service-specific-credential.html) command.

   For Amazon Bedrock:

   ```
   aws iam create-service-specific-credential \
       --user-name APIKeyUser_1 \
       --service-name bedrock.amazonaws.com \
       --credential-age-days 30
   ```

   For Amazon CloudWatch Logs:

   ```
   aws iam create-service-specific-credential \
       --user-name APIKeyUser_1 \
       --service-name logs.amazonaws.com \
       --credential-age-days 30
   ```
**Note**  
The `--credential-age-days` parameter is optional. You can specify a value between 1–36600 days. If you omit this parameter, the API key does not expire.

The returned `ServiceApiKeyValue` in the response is your long-term API key for the respective service. Store the `ServiceApiKeyValue` value securely, as you cannot retrieve it later.

### List long-term API keys (AWS CLI)
<a name="id_credentials_api_keys_cli_list"></a>

To list long-term API keys metadata for a specific user, use the [ list-service-specific-credentials](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-service-specific-credentials.html) command with the `--user-name` parameter:

```
aws iam list-service-specific-credentials \
    --service-name bedrock.amazonaws.com \
    --user-name APIKeyUser_1
```

**Note**  
Replace `bedrock.amazonaws.com` with the appropriate service name (for example, `logs.amazonaws.com` for Amazon CloudWatch Logs).

To list all long-term API keys metadata in the account, use the [ list-service-specific-credentials](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-service-specific-credentials.html) command with the `--all-users` parameter:

```
aws iam list-service-specific-credentials \
    --service-name bedrock.amazonaws.com \
    --all-users
```

### Update long-term API key status (AWS CLI)
<a name="id_credentials_api_keys_cli_update"></a>

To update the status of a long-term API key, use the [ update-service-specific-credential](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/update-service-specific-credential.html) command:

```
aws iam update-service-specific-credential \
    --user-name "APIKeyUser_1" \
    --service-specific-credential-id "ACCA1234EXAMPLE1234" \
    --status Inactive|Active
```

## Generating a long-term API key (AWS API)
<a name="id_credentials_api_keys_api"></a>

You can use the following IAM API operations to manage long-term API keys for any supported service:
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServiceSpecificCredentials.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServiceSpecificCredentials.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateServiceSpecificCredential.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceSpecificCredential.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResetServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResetServiceSpecificCredential.html) 

## Short-term API keys (Amazon Bedrock)
<a name="id_credentials_api_keys_short_term"></a>

Short-term API keys are currently supported by Amazon Bedrock only. For information on generating and using short-term API keys, see [Generate an API key](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys-generate.html) in the *Amazon Bedrock User Guide*.

## Service-specific information
<a name="id_credentials_api_keys_service_info"></a>
+ For more information about using API keys with Amazon Bedrock, see [Use an Amazon Bedrock API key](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys-use.html) in the *Amazon Bedrock User Guide*.
+ For more information about using API keys with Amazon CloudWatch Logs, see [Log ingestion through HTTP endpoints](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_HTTP_Endpoints.html) in the *Amazon CloudWatch Logs User Guide*.

# Use IAM with Amazon Keyspaces (for Apache Cassandra)
<a name="id_credentials_keyspaces"></a>

Amazon Keyspaces (for Apache Cassandra) is a scalable, highly available, and managed Apache Cassandra-compatible database service. You can access Amazon Keyspaces through the AWS Management Console, or programmatically. To access Amazon Keyspaces programmatically with service-specific credentials, you can use `cqlsh` or open-source Cassandra drivers. *Service-specific credentials* include a user name and password like those that Cassandra uses for authentication and access management. You can have a maximum of two sets of service-specific credentials for each supported service per user.

To access Amazon Keyspaces programmatically with AWS access keys, you can use the AWS SDK, the AWS Command Line Interface (AWS CLI) or open-source Cassandra drivers with the SigV4 plugin. To learn more, see [Create and configure AWS credentials for Amazon Keyspaces](https://docs.aws.amazon.com//keyspaces/latest/devguide/access.credentials.html) in the *Amazon Keyspaces (for Apache Cassandra) Developer Guide*.

**Note**  
If you plan to interact with Amazon Keyspaces only through the console, you don't need to generate service-specific credentials. For more information, see [Accessing Amazon Keyspaces using the console](https://docs.aws.amazon.com/keyspaces/latest/devguide/console_keyspaces.html) in the *Amazon Keyspaces (for Apache Cassandra) Developer Guide*.

For more information about the permissions required to access Amazon Keyspaces, see [Amazon Keyspaces (for Apache Cassandra) Identity-Based Policy Examples](https://docs.aws.amazon.com/keyspaces/latest/devguide/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-console) in the *Amazon Keyspaces (for Apache Cassandra) Developer Guide*.

## Generating Amazon Keyspaces credentials (console)
<a name="keyspaces_credentials_console"></a>

You can use the AWS Management Console to generate Amazon Keyspaces (for Apache Cassandra) credentials for your IAM users.

**To generate Amazon Keyspaces service-specific credentials (console)**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users** and then choose the name of the user that requires the credentials.

1. On the **Security Credentials** tab beneath **Credentials for Amazon Keyspaces (for Apache Cassandra)**, choose **Generate credentials**.

1. Your service-specific credentials are now available. This is the only time that the password can be viewed or downloaded. You cannot recover it later. However, you can reset your password at any time. Save the user and password in a secure location, because you'll need them later.

## Generating Amazon Keyspaces credentials (AWS CLI)
<a name="keyspaces_credentials_cli"></a>

You can use the AWS CLI to generate Amazon Keyspaces (for Apache Cassandra) credentials for your IAM users.

**To generate Amazon Keyspaces service-specific credentials (AWS CLI)**
+ Use the following command:
  + [aws iam create-service-specific-credential](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-specific-credential.html)

## Generating Amazon Keyspaces credentials (AWS API)
<a name="keyspaces_credentials_api"></a>

You can use the AWS API to generate Amazon Keyspaces (for Apache Cassandra) credentials for your IAM users.

**To generate Amazon Keyspaces service-specific credentials (AWS API)**
+ Complete the following operation:
  + [CreateServiceSpecificCredential](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html) 

# Find unused AWS credentials
<a name="id_credentials_finding-unused"></a>

To increase the security of your AWS account, remove IAM user credentials (that is, passwords and access keys) that are not needed. For example, when users leave your organization or no longer need AWS access, find the credentials that they were using and ensure that they are no longer operational. Ideally, you delete credentials if they are no longer needed. You can always recreate them at a later date if the need arises. At the very least, you should change the password or deactivate the access keys so that the former users no longer have access.

Of course, the definition of *unused* can vary and usually means a credential that has not been used within a specified period of time.

## Finding unused passwords
<a name="finding-unused-passwords"></a>

You can use the AWS Management Console to view password usage information for your users. If you have a large number of users, you can use the console to download a credential report with information about when each user last used their console password. You can also access the information from the AWS CLI or the IAM API.

**To find unused passwords (console)**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**.

1. If necessary, add the **Console last sign-in** column to the users table:

   1. Above the table on the far right, choose the settings icon (![\[Settings icon\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/console-settings-icon.console.png)).

   1. In **Select visible columns**, select **Console last sign-in**.

   1. Choose **Confirm** to return to the list of users.

1. The **Console last sign-in** column shows the date when the user last signed in to AWS through the console. You can use this information to find users with passwords who have not signed in for more than a specified period of time. The column displays **Never** for users with passwords that have never signed in. **None** indicates users with no passwords. Passwords that have not been used recently might be good candidates for removal.
**Important**  
Due to a service issue, password last used data does not include password use from May 3rd 2018 22:50 PDT to May 23rd 2018 14:08 PDT. This affects [last sign-in](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) dates shown in the IAM console and password last used dates in the [IAM credential report](https://docs.aws.amazon.com/IAM/latest/UserGuide/SupportedTypes.xmlid_credentials_getting-report.html), and returned by the [GetUser API operation](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html). If users signed in during the affected time, the password last used date that is returned is the date the user last signed in before May 3rd 2018. For users that signed in after May 23rd 2018 14:08 PDT, the returned password last used date is accurate.  
If you use password last used information to identify unused credentials for deletion, such as deleting users who did not sign in to AWS in the last 90 days, we recommend that you adjust your evaluation window to include dates after May 23rd 2018. Alternatively, if your users use access keys to access AWS programmatically you can refer to access key last used information because it is accurate for all dates. 

**To find unused passwords by downloading the credentials report (console)**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Credential report**.

1. Choose **Download Report** to download a comma-separated value (CSV) file named `status_reports_<date>T<time>.csv`. The fifth column contains the `password_last_used` column with the dates or one of the following:
   + **N/A** – Users that do not have a password assigned at all.
   + **no\$1information** – Users that have not used their password since IAM began tracking password age on October 20, 2014.

**To find unused passwords (AWS CLI)**  
Run the following command to find unused passwords:
+ `[aws iam list-users](https://docs.aws.amazon.com/cli/latest/reference/iam/list-users.html)` returns a list of users, each with a `PasswordLastUsed` value. If the value is missing, then the user either has no password or the password has not been used since IAM began tracking password age on October 20, 2014.

**To find unused passwords (AWS API)**  
Call the following operation to find unused passwords:
+  ` [ListUsers](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html)` returns a collection of users, each of which has a `<PasswordLastUsed>` value. If the value is missing, then the user either has no password or the password has not been used since IAM began tracking password age on October 20, 2014.

For information about the commands to download the credentials report, see [Getting credential reports (AWS CLI)](id_credentials_getting-report.md#getting-credential-reports-cliapi).

## Finding unused access keys
<a name="finding-unused-access-keys"></a>

You can use the AWS Management Console to view access key usage information for your users. If you have a large number of users, you can use the console to download a credentials report to find when each user last used their access keys. You can also access the information from the AWS CLI or the IAM API.

**To find unused access keys (console)**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Users**.

1. If necessary, add the **Access key last used** column to the users table:

   1. Above the table on the far right, choose the settings icon (![\[Settings icon\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/console-settings-icon.console.png)).

   1. In **Select visible columns**, select **Access key last used**.

   1. Choose **Confirm** to return to the list of users.

1. The **Access key last used** column shows the number of days since the user last accessed AWS programmatically. You can use this information to find users with access keys that have not been used for more than a specified period of time. The column displays **–** for users with no access keys. Access keys that have not been used recently might be good candidates for removal.

**To find unused access keys by downloading the credentials report (console)**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Credential Report**.

1. Choose **Download Report** to download a comma-separated value (CSV) file named `status_reports_<date>T<time>.csv`. Columns 11 through 13 contain the last used date, Region, and service information for access key 1. Columns 16 through 18 contain the same information for access key 2. The value is **N/A** if the user does not have an access key or the user has not used the access key since IAM began tracking access key age on April 22, 2015.

**To find unused access keys (AWS CLI)**  
Run the following commands to find unused access keys:
+ `[aws iam list-access-keys](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)` returns information about the access keys for a user, including the `AccessKeyID`.
+ `[aws iam get-access-key-last-used](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)` takes an access key ID and returns output that includes the `LastUsedDate`, the `Region` in which the access key was last used, and the `ServiceName` of the last service requested. If `LastUsedDate` is missing, then the access key has not been used since IAM began tracking access key age on April 22, 2015.

**To find unused access keys (AWS API)**  
Call the following operations to find unused access keys:
+ `[ListAccessKeys](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html)` returns a list of `AccessKeyID` values for access keys that are associated with the specified user. 
+ `[GetAccessKeyLastUsed](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html)` takes an access key ID and returns a collection of values. Included are the `LastUsedDate`, the `Region` in which the access key was last used, and the `ServiceName` of the last service requested. If the value is missing, then either the user has no access key or the access key has not been used since IAM began tracking access key age on April 22, 2015.

For information about the commands to download the credentials report, see [Getting credential reports (AWS CLI)](id_credentials_getting-report.md#getting-credential-reports-cliapi).

# Generate credential reports for your AWS account
<a name="id_credentials_getting-report"></a>

You can generate and download a *credential report* that lists all users in your account and the status of their various credentials, including passwords, access keys, and MFA devices. You can get a credential report from the AWS Management Console, the [AWS SDKs](https://aws.amazon.com/tools) and [Command Line Tools](https://aws.amazon.com/tools/#Command_Line_Tools), or the IAM API. 

**Note**  
The IAM credential report only includes the following IAM-managed credentials: passwords, the first two access keys per user, MFA devices, and X.509 signing certificates. The report does not include service-specific credentials (such as CodeCommit passwords, Amazon Bedrock long-term API keys, or Amazon CloudWatch Logs long-term API keys) or any other user access keys beyond the first two. For complete credential visibility, use the [ListServiceSpecificCredentials](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServiceSpecificCredentials.html) and [ListAccessKeys](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html) APIs.

You can use credential reports to assist in your auditing and compliance efforts. You can use the report to audit the effects of credential lifecycle requirements, such as password and access key updates. You can provide the report to an external auditor, or grant permissions to an auditor so that he or she can download the report directly.

You can generate a credential report as often as once every four hours. When you request a report, IAM first checks whether a report for the AWS account has been generated within the past four hours. If so, the most recent report is downloaded. If the most recent report for the account is older than four hours, or if there are no previous reports for the account, IAM generates and downloads a new report. 

**Topics**
+ [

## Required permissions
](#id_credentials_required_permissions)
+ [

## Understanding the report format
](#id_credentials_understanding_the_report_format)
+ [

## Getting credential reports (console)
](#getting-credential-reports-console)
+ [

## Getting credential reports (AWS CLI)
](#getting-credential-reports-cliapi)
+ [

## Getting credential reports (AWS API)
](#getting-credential-reports-api)

## Required permissions
<a name="id_credentials_required_permissions"></a>

The following permissions are needed to create and download reports:
+ To create a credential report: `iam:GenerateCredentialReport` 
+ To download the report: `iam:GetCredentialReport`

## Understanding the report format
<a name="id_credentials_understanding_the_report_format"></a>

Credential reports are formatted as comma-separated values (CSV) files. You can open CSV files with common spreadsheet software to perform analysis, or you can build an application that consumes the CSV files programmatically and performs custom analysis. 

The CSV file contains the following columns:

**user**  
The friendly name of the user. 

**arn**  
The Amazon Resource Name (ARN) of the user. For more information about ARNs, see [IAM ARNs](reference_identifiers.md#identifiers-arns). 

**user\$1creation\$1time**  
The date and time when the user was created, in [ISO 8601 date-time format](https://en.wikipedia.org/wiki/ISO_8601).

**password\$1enabled**  
When the user has a password, this value is `TRUE`. Otherwise it is `FALSE`. This value is `FALSE` for new member accounts created as part of your organization as they have no root user credentials by default.

**password\$1last\$1used**  
The date and time when the AWS account root user or user's password was last used to sign in to an AWS website, in [ISO 8601 date-time format](http://www.iso.org/iso/iso8601). AWS websites that capture a user's last sign-in time are the AWS Management Console, the AWS Discussion Forums, and the AWS Marketplace. When a password is used more than once in a 5-minute span, only the first use is recorded in this field.   
+ The value in this field is `no_information` in these cases:
  + The user's password has never been used.
  + There is no sign-in data associated with the password, such as when user's password has not been used after IAM started tracking this information on October 20, 2014.
+ The value in this field is `N/A` (not applicable) when the user does not have a password.

**Important**  
Due to a service issue, password last used data does not include password use from May 3rd 2018 22:50 PDT to May 23rd 2018 14:08 PDT. This affects [last sign-in](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) dates shown in the IAM console and password last used dates in the [IAM credential report](https://docs.aws.amazon.com/IAM/latest/UserGuide/SupportedTypes.xmlid_credentials_getting-report.html), and returned by the [GetUser API operation](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html). If users signed in during the affected time, the password last used date that is returned is the date the user last signed in before May 3rd 2018. For users that signed in after May 23rd 2018 14:08 PDT, the returned password last used date is accurate.  
If you use password last used information to identify unused credentials for deletion, such as deleting users who did not sign in to AWS in the last 90 days, we recommend that you adjust your evaluation window to include dates after May 23rd 2018. Alternatively, if your users use access keys to access AWS programmatically you can refer to access key last used information because it is accurate for all dates. 

**password\$1last\$1changed**  
The date and time when the user's password was last set, in [ISO 8601 date-time format](https://en.wikipedia.org/wiki/ISO_8601). If the user does not have a password, the value in this field is `N/A` (not applicable).

**password\$1next\$1rotation**  
When the account has a [password policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_ManagingPasswordPolicies.html) that requires password rotation, this field contains the date and time, in [ISO 8601 date-time format](https://en.wikipedia.org/wiki/ISO_8601), when the user is required to set a new password. The value for the AWS account (root) is always `not_supported`.

**mfa\$1active**  
When a [multi-factor authentication](id_credentials_mfa.md) (MFA) device has been enabled for the user, this value is `TRUE`. Otherwise it is `FALSE`.

**access\$1key\$11\$1active**  
When the user has an access key and the access key's status is `Active`, this value is `TRUE`. Otherwise it is `FALSE`. Applies to both account root user and IAM users.

**access\$1key\$11\$1last\$1rotated**  
The date and time, in [ISO 8601 date-time format](https://en.wikipedia.org/wiki/ISO_8601), when the user's access key was created or last changed. If the user does not have an active access key, the value in this field is `N/A` (not applicable). Applies to both account root user and IAM users.

**access\$1key\$11\$1last\$1used\$1date**  
The date and time, in [ISO 8601 date-time format](https://en.wikipedia.org/wiki/ISO_8601), when the user's access key was most recently used to sign an AWS API request. When an access key is used more than once in a 15-minute span, only the first use is recorded in this field. Applies to both account root user and IAM users.  
The value in this field is `N/A` (not applicable) in these cases:  
+ The user does not have an access key.
+ The access key has never been used.
+ The access key has not been used after IAM started tracking this information on April 22, 2015.

**access\$1key\$11\$1last\$1used\$1region**  
The [AWS Region](https://docs.aws.amazon.com/general/latest/gr/rande.html) in which the access key was most recently used. When an access key is used more than once in a 15-minute span, only the first use is recorded in this field. Applies to both account root user and IAM users.  
The value in this field is `N/A` (not applicable) in these cases:  
+ The user does not have an access key.
+ The access key has never been used.
+ The access key was last used before IAM started tracking this information on April 22, 2015.
+ The last used service is not Region-specific, such as Amazon S3.

**access\$1key\$11\$1last\$1used\$1service**  
The AWS service that was most recently accessed with the access key. The value in this field uses the service's namespace—for example, `s3` for Amazon S3 and `ec2` for Amazon EC2. When an access key is used more than once in a 15-minute span, only the first use is recorded in this field. Applies to both account root user and IAM users.  
The value in this field is `N/A` (not applicable) in these cases:  
+ The user does not have an access key.
+ The access key has never been used.
+ The access key was last used before IAM started tracking this information on April 22, 2015.

**access\$1key\$12\$1active**  
When the user has a second access key and the second key's status is `Active`, this value is `TRUE`. Otherwise it is `FALSE`. Applies to both account root user and IAM users.  
Users can have up to two access keys, to make rotation easier by updating the key first and then deleting the previous key. For more information about updating access keys, see [Update access keys](id-credentials-access-keys-update.md).

**access\$1key\$12\$1last\$1rotated**  
The date and time, in [ISO 8601 date-time format](https://en.wikipedia.org/wiki/ISO_8601), when the user's second access key was created or last updated. If the user does not have a second active access key, the value in this field is `N/A` (not applicable). Applies to both account root user and IAM users.

**access\$1key\$12\$1last\$1used\$1date**  
The date and time, in [ISO 8601 date-time format](https://en.wikipedia.org/wiki/ISO_8601), when the user's second access key was most recently used to sign an AWS API request. When an access key is used more than once in a 15-minute span, only the first use is recorded in this field. Applies to both account root user and IAM users.  
The value in this field is `N/A` (not applicable) in these cases:  
+ The user does not have a second access key.
+ The user's second access key has never been used.
+ The user's second access key was last used before IAM started tracking this information on April 22, 2015.

**access\$1key\$12\$1last\$1used\$1region**  
The [AWS Region](https://docs.aws.amazon.com/general/latest/gr/rande.html) in which the user's second access key was most recently used. When an access key is used more than once in a 15-minute span, only the first use is recorded in this field. Applies to both account root user and IAM users. The value in this field is `N/A` (not applicable) in these cases:  
+ The user does not have a second access key.
+ The user's second access key has never been used.
+ The user's second access key was last used before IAM started tracking this information on April 22, 2015.
+ The last used service is not Region-specific, such as Amazon S3.

**access\$1key\$12\$1last\$1used\$1service**  
The AWS service that was most recently accessed with the user's second access key. The value in this field uses the service's namespace—for example, `s3` for Amazon S3 and `ec2` for Amazon EC2. When an access key is used more than once in a 15-minute span, only the first use is recorded in this field. Applies to both account root user and IAM users. The value in this field is `N/A` (not applicable) in these cases:  
+ The user does not have a second access key.
+ The user's second access key has never been used.
+ The user's second access key was last used before IAM started tracking this information on April 22, 2015.

**cert\$11\$1active**  
When the user has an X.509 signing certificate and that certificate's status is `Active`, this value is `TRUE`. Otherwise it is `FALSE`.

**cert\$11\$1last\$1rotated**  
The date and time, in [ISO 8601 date-time format](https://en.wikipedia.org/wiki/ISO_8601), when the user's signing certificate was created or last changed. If the user does not have an active signing certificate, the value in this field is `N/A` (not applicable).

**cert\$12\$1active**  
When the user has a second X.509 signing certificate and that certificate's status is `Active`, this value is `TRUE`. Otherwise it is `FALSE`.  
Users can have up to two X.509 signing certificates, to make certificate rotation easier.

**cert\$12\$1last\$1rotated**  
The date and time, in [ISO 8601 date-time format](https://en.wikipedia.org/wiki/ISO_8601), when the user's second signing certificate was created or last changed. If the user does not have a second active signing certificate, the value in this field is `N/A` (not applicable).

**additional\$1credentials\$1info**  
When the user has more than two access keys or certificates, this value is the number of additional access keys or certificates and the actions you can use to list the access keys or certificates associated with the user.

## Getting credential reports (console)
<a name="getting-credential-reports-console"></a>

You can use the AWS Management Console to download a credential report as a comma-separated values (CSV) file.

**To download a credential report (console)**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Credential report**.

1. Choose **Download Report**.

## Getting credential reports (AWS CLI)
<a name="getting-credential-reports-cliapi"></a>

**To download a credentials report (AWS CLI)**

1. Generate a credentials report. AWS stores a single report. If a report exists, generating a credentials report overwrites the previous report. [https://docs.aws.amazon.com/cli/latest/reference/iam/generate-credential-report.html](https://docs.aws.amazon.com/cli/latest/reference/iam/generate-credential-report.html)

1. View the last report that was generated: [https://docs.aws.amazon.com/cli/latest/reference/iam/get-credential-report.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-credential-report.html)

## Getting credential reports (AWS API)
<a name="getting-credential-reports-api"></a>

**To download a credentials report (AWS API)**

1. Generate a credentials report. AWS stores a single report. If a report exists, generating a credentials report overwrites the previous report. [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GenerateCredentialReport.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GenerateCredentialReport.html)

1. View the last report that was generated: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetCredentialReport.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetCredentialReport.html)

# IAM credentials for CodeCommit: Git credentials, SSH keys, and AWS access keys
<a name="id_credentials_ssh-keys"></a>

CodeCommit is a managed version control service that hosts private Git repositories in the AWS cloud. To use CodeCommit, you configure your Git client to communicate with CodeCommit repositories. As part of this configuration, you provide IAM credentials that CodeCommit can use to authenticate you. IAM supports CodeCommit with three types of credentials:
+ Git credentials, an IAM-generated user name and password pair you can use to communicate with CodeCommit repositories over HTTPS.
+ SSH keys, a locally generated public-private key pair that you can associate with your IAM user to communicate with CodeCommit repositories over SSH.
+  [AWS access keys](id_credentials_access-keys.md), which you can use with the credential helper included with the AWS CLI to communicate with CodeCommit repositories over HTTPS.

**Note**  
You cannot use SSH keys or Git credentials to access repositories in another AWS account. To learn how to configure access to CodeCommit repositories for IAM users and groups in another AWS account, see [Configure cross-account access to an AWS CodeCommit repository using roles](https://docs.aws.amazon.com/codecommit/latest/userguide/cross-account.html) in the *AWS CodeCommit User Guide*.

See the following sections for more information about each option. 

## Use Git credentials and HTTPS with CodeCommit (recommended)
<a name="git-credentials-code-commit"></a>

With Git credentials, you generate a static user name and password pair for your IAM user, and then use those credentials for HTTPS connections. You can also use these credentials with any third-party tool or integrated development environment (IDE) that supports static Git credentials.

Because these credentials are universal for all supported operating systems and compatible with most credential management systems, development environments, and other software development tools, this is the recommended method. You can reset the password for Git credentials at any time. You can also make the credentials inactive or delete them if you no longer need them.

**Note**  
You cannot choose your own user name or password for Git credentials. IAM generates these credentials for you to help ensure they meet the security standards for AWS and secure repositories in CodeCommit. You can download the credentials only once, at the time they are generated. Make sure that you save the credentials in a secure location. If necessary, you can reset the password at any time, but doing so invalidates any connections configured with the old password. You must reconfigure connections to use the new password before you can connect.

See the following topics for more information: 
+ To create an IAM user, see [Create an IAM user in your AWS account](id_users_create.md). 
+ To generate and use Git credentials with CodeCommit, see [For HTTPS Users Using Git Credentials](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html) in the *AWS CodeCommit User Guide*. 

**Note**  
Changing the name of an IAM user after generating Git credentials does not change the user name of the Git credentials. The user name and password remain the same and are still valid. 

**To update service specific credentials**

1. Create a second service-specific credential set in addition to the set currently in use.

1. Update all of your applications to use the new set of credentials and validate that the applications are working.

1. Change the state of the original credentials to "Inactive".

1. Ensure that all of your applications are still working.

1. Delete the inactive service-specific credentials.

## Use SSH keys and SSH with CodeCommit
<a name="ssh-keys-code-commit"></a>

With SSH connections, you create public and private key files on your local machine that Git and CodeCommit use for SSH authentication. You associate the public key with your IAM user and store the private key on your local machine. See the following topics for more information: 
+ To create an IAM user, see [Create an IAM user in your AWS account](id_users_create.md). 
+ To create an SSH public key and associate it with an IAM user, see [For SSH Connections on Linux, macOS, or Unix](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-ssh-unixes.html) or see [For SSH Connections on Windows](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-ssh-windows.html) in the *AWS CodeCommit User Guide*. 

**Note**  
The public key must be encoded in ssh-rsa format or PEM format. The minimum bit-length of the public key is 2048 bits, and the maximum length is 16384 bits. This is separate from the size of the file you upload. For example, you can generate a 2048-bit key, and the resulting PEM file is 1679 bytes long. If you provide your public key in another format or size, you will see an error message stating that the key format is not valid.

## Use HTTPS with the AWS CLI credential helper and CodeCommit
<a name="access-keys-code-commit"></a>

As an alternative to HTTPS connections with Git credentials, you can allow Git to use a cryptographically signed version of your IAM user credentials or Amazon EC2 instance role whenever Git needs to authenticate with AWS to interact with CodeCommit repositories. This is the only connection method for CodeCommit repositories that does not require an IAM user. This is also the only method that works with federated access and temporary credentials. See the following topics for more information:
+ To learn more about federated access, see [Identity providers and federation into AWS](id_roles_providers.md) and [Access to externally authenticated users (identity federation)](id_roles_common-scenarios_federated-users.md). 
+ To learn more about temporary credentials, see [Temporary security credentials in IAM](id_credentials_temp.md) and [Temporary Access to CodeCommit Repositories](https://docs.aws.amazon.com/codecommit/latest/userguide/temporary-access.html). 

The AWS CLI credential helper is not compatible with other credential helper systems, such as Keychain Access or Windows Credential Management. There are additional configuration considerations when you configure HTTPS connections with the credential helper. For more information, see [For HTTPS Connections on Linux, macOS, or Unix with the AWS CLI Credential Helper](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-https-unixes.html) or [HTTPS Connections on Windows with the AWS CLI Credential Helper](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-https-windows.html) in the *AWS CodeCommit User Guide*.

# Manage server certificates in IAM
<a name="id_credentials_server-certs"></a>

To enable HTTPS connections to your website or application in AWS, you need an SSL/TLS *server certificate*. For certificates in a Region supported by AWS Certificate Manager (ACM), we recommend that you use ACM to provision, manage, and deploy your server certificates. In unsupported Regions, you must use IAM as a certificate manager. To learn which Regions ACM supports, see [AWS Certificate Manager endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/acm.html) in the *AWS General Reference*.

**Important**  
ACM is the preferred tool to provision, manage, and deploy your server certificates. With ACM you can request a certificate or deploy an existing ACM or external certificate to AWS resources. Certificates provided by ACM are free and automatically renew. In a [supported Region](https://docs.aws.amazon.com/general/latest/gr/acm.html), you can use ACM to manage server certificates from the console or programmatically. For more information about using ACM, see the [https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html). For more information about requesting an ACM certificate, see [Request a Public Certificate](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) or [Request a Private Certificate](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-private.html) in the *AWS Certificate Manager User Guide*. For more information about importing third-party certificates into ACM, see [Importing Certificates](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html) in the *AWS Certificate Manager User Guide*.

Use IAM as a certificate manager only when you must support HTTPS connections in a Region that is not [supported by ACM](https://docs.aws.amazon.com/general/latest/gr/acm.html). IAM securely encrypts your private keys and stores the encrypted version in IAM SSL certificate storage. IAM supports deploying server certificates in all Regions, but you must obtain your certificate from an external provider for use with AWS. You cannot upload an ACM certificate to IAM. Additionally, you cannot manage your certificates from the IAM Console.

For more information about uploading third-party certificates to IAM, see the following topics.

**Topics**
+ [

## Upload a server certificate (AWS API)
](#upload-server-certificate)
+ [

## AWS API operations for server certificates
](#id_credentials_server-certs-api)
+ [

## Troubleshoot server certificates
](#server-certificate-troubleshooting)

## Upload a server certificate (AWS API)
<a name="upload-server-certificate"></a>

To upload a server certificate to IAM, you must provide the certificate and its matching private key. When the certificate is not self-signed, you must also provide a certificate chain. (You don't need a certificate chain when uploading a self-signed certificate.) Before you upload a certificate, ensure that you have all these items and that they meet the following criteria:
+ The certificate must be valid at the time of upload. You cannot upload a certificate before its validity period begins (the certificate's `NotBefore` date) or after it expires (the certificate's `NotAfter` date).
+ The private key must be unencrypted. You cannot upload a private key that is protected by a password or passphrase. For help decrypting an encrypted private key, see [Troubleshoot server certificates](#server-certificate-troubleshooting).
+ The certificate, private key, and certificate chain must all be PEM-encoded. For help converting these items to PEM format, see [Troubleshoot server certificates](#server-certificate-troubleshooting).

To use the [IAM API](https://docs.aws.amazon.com/IAM/latest/APIReference/) to upload a certificate, send an [UploadServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UploadServerCertificate.html) request. The following example shows how to do this with the [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/cli/). The example assumes the following:
+ The PEM-encoded certificate is stored in a file named `Certificate.pem`.
+ The PEM-encoded certificate chain is stored in a file named `CertificateChain.pem`.
+ The PEM-encoded, unencrypted private key is stored in a file named `PrivateKey.pem`.
+ (Optional) You want to tag the server certificate with a key–value pair. For example, you might add the tag key `Department` and the tag value `Engineering` to help you identify and organize your certificates.

To use the following example command, replace these file names with your own. Replace *ExampleCertificate* with a name for your uploaded certificate. If you want to tag the certificate, replace the *ExampleKey* and *ExampleValue* tag key-value pair with your own values. Type the command on one continuous line. The following example includes line breaks and extra spaces to make it easier to read.

```
aws iam upload-server-certificate --server-certificate-name ExampleCertificate
                                    --certificate-body file://Certificate.pem
                                    --certificate-chain file://CertificateChain.pem
                                    --private-key file://PrivateKey.pem
                                    --tags '{"Key": "ExampleKey", "Value": "ExampleValue"}'
```

When the preceding command is successful, it returns metadata about the uploaded certificate, including its [Amazon Resource Name (ARN)](reference_identifiers.md#identifiers-arns), its friendly name, its identifier (ID), its expiration date, tags, and more.

**Note**  
If you are uploading a server certificate to use with Amazon CloudFront, you must specify a path using the `--path` option. The path must begin with `/cloudfront` and must include a trailing slash (for example, `/cloudfront/test/`).

To use the AWS Tools for Windows PowerShell to upload a certificate, use [Publish-IAMServerCertificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Publish-IAMServerCertificate.html&tocid=Publish-IAMServerCertificate).

## AWS API operations for server certificates
<a name="id_credentials_server-certs-api"></a>

Use the following commands to view, tag, rename, and delete server certificates.
+ Use [GetServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServerCertificate.html) to retrieve a certificate. This request returns the certificate, the certificate chain (if one was uploaded), and metadata about the certificate.
**Note**  
You cannot download or retrieve a private key from IAM after you upload it.
+ Use [Get-IAMServerCertificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Get-IAMServerCertificate.html&tocid=Get-IAMServerCertificate) to retrieve a certificate.
+ Use [ListServerCertificates](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServerCertificates.html) to list your uploaded server certificates. The request returns a list that contains metadata about each certificate.
+ Use [Get-IAMServerCertificates](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Get-IAMServerCertificates.html&tocid=Get-IAMServerCertificates) to list your uploaded server certificates.
+ Use [TagServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagServerCertificate.html) to tag an existing server certificate. 
+ Use [UntagServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagServerCertificate.html) to untag a server certificate.
+ Use [UpdateServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateServerCertificate.html) to rename a server certificate or update its path.

   The following example shows how to do this with the AWS CLI.

  To use the following example command, replace the old and new certificate names and the certificate path, and type the command on one continuous line. The following example includes line breaks and extra spaces to make it easier to read.

  ```
  aws iam update-server-certificate --server-certificate-name ExampleCertificate
                                      --new-server-certificate-name CloudFrontCertificate
                                      --new-path /cloudfront/
  ```

  To use the AWS Tools for Windows PowerShell to rename a server certificate or update its path, use [Update-IAMServerCertificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Update-IAMServerCertificate.html&tocid=Update-IAMServerCertificate).
+ Use [DeleteServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServerCertificate.html) to delete a server certificate. 

  To use the AWS Tools for Windows PowerShell to delete a server certificate, use [Remove-IAMServerCertificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Remove-IAMServerCertificate.html&tocid=Remove-IAMServerCertificate).

## Troubleshoot server certificates
<a name="server-certificate-troubleshooting"></a>

Before you can upload a certificate to IAM, you must make sure that the certificate, private key, and certificate chain are all PEM-encoded. You must also ensure that the private key is unencrypted. See the following examples.

**Example PEM-encoded certificate**  

```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
```

**Example PEM-encoded, unencrypted private key**  

```
-----BEGIN RSA PRIVATE KEY-----
Base64-encoded private key
-----END RSA PRIVATE KEY-----
```

**Example PEM-encoded certificate chain**  
A certificate chain contains one or more certificates. You can use a text editor, the copy command in Windows, or the Linux cat command to concatenate your certificate files into a chain. When you include multiple certificates, each certificate must certify the preceding certificate. You accomplish this by concatenating the certificates, including the root CA certificate last.  
The following example contains three certificates, but your certificate chain might contain more or fewer certificates.  

```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
```

If these items are not in the right format for uploading to IAM, you can use [OpenSSL](https://openssl.org/) to convert them to the right format.

**To convert a certificate or certificate chain from DER to PEM**  
Use the [OpenSSL **x509** command](https://openssl.org/docs/manmaster/man1/x509.html), as in the following example. In the following example command, replace `Certificate.der` with the name of the file that contains your DER-encoded certificate. Replace `Certificate.pem` with the preferred name of the output file to contain the PEM-encoded certificate.  

```
openssl x509 -inform DER -in Certificate.der -outform PEM -out Certificate.pem
```
 

**To convert a private key from DER to PEM**  
Use the [OpenSSL **rsa** command](https://openssl.org/docs/manmaster/man1/rsa.html), as in the following example. In the following example command, replace `PrivateKey.der` with the name of the file that contains your DER-encoded private key. Replace `PrivateKey.pem` with the preferred name of the output file to contain the PEM-encoded private key.  

```
openssl rsa -inform DER -in PrivateKey.der -outform PEM -out PrivateKey.pem
```
 

**To decrypt an encrypted private key (remove the password or passphrase)**  
Use the [OpenSSL **rsa** command](https://openssl.org/docs/manmaster/man1/rsa.html), as in the following example. To use the following example command, replace `EncryptedPrivateKey.pem` with the name of the file that contains your encrypted private key. Replace `PrivateKey.pem` with the preferred name of the output file to contain the PEM-encoded unencrypted private key.  

```
openssl rsa -in EncryptedPrivateKey.pem -out PrivateKey.pem
```
 

**To convert a certificate bundle from PKCS\$112 (PFX) to PEM**  
Use the [OpenSSL **pkcs12** command](https://openssl.org/docs/manmaster/man1/pkcs12.html), as in the following example. In the following example command, replace `CertificateBundle.p12` with the name of the file that contains your PKCS\$112-encoded certificate bundle. Replace `CertificateBundle.pem` with the preferred name of the output file to contain the PEM-encoded certificate bundle.  

```
openssl pkcs12 -in CertificateBundle.p12 -out CertificateBundle.pem -nodes
```
 

**To convert a certificate bundle from PKCS\$17 to PEM**  
Use the [OpenSSL **pkcs7** command](https://openssl.org/docs/manmaster/man1/pkcs7.html), as in the following example. In the following example command, replace `CertificateBundle.p7b` with the name of the file that contains your PKCS\$17-encoded certificate bundle. Replace `CertificateBundle.pem` with the preferred name of the output file to contain the PEM-encoded certificate bundle.  

```
openssl pkcs7 -in CertificateBundle.p7b -print_certs -out CertificateBundle.pem
```