# Set up workforce access to AWS resources
Set up how your workforce users authenticate and access AWS resources through IAM Identity Center. This section covers the following components that govern workforce user access to your AWS environment:
+ **Authentication sessions** – Understand how IAM Identity Center manages different types of user sessions, from interactive portal sessions to background application sessions, and how they interact with each other.
+ **User access management** – Configure session durations, disable user accounts, and implement organization-wide access blocks to maintain security and compliance.
+ **Password management** – For users created in the Identity Center directory, set password requirements, handle user credential setup, and manage password resets for users.
+ **Multi-factor authentication** – For users created in the Identity Center directory, enhance security with MFA using authenticator apps, security keys, or built-in authenticators to protect user sign-ins.
**Topics**
+ [Understanding authentication sessions in IAM Identity Center](authconcept.md)
+ [Configure the session duration in IAM Identity Center](configure-user-session.md)
+ [Disable user access to AWS accounts and applications in IAM Identity Center](disableuser.md)
+ [Deny user access with Service Control Policies](authconcept-revoke-access.md)
+ [Managing access for users in the Identity Center directory](managing-workforce-access-identity-center-directory.md)
# Understanding authentication sessions in IAM Identity Center
When a user signs in to the [AWS access portal](using-the-portal.md), IAM Identity Center creates an authentication session that represents the user’s verified identity.
Once authenticated, the user can access all their assigned AWS accounts, [AWS managed applications](awsapps.md), and [customer managed applications](customermanagedapps.md) that administrators have granted them permission to use, without additional sign ins.
## Types of authentication sessions
### User interactive sessions
After a user signs in to the AWS access portal, IAM Identity Center creates a user interactive session. This session represents the user's authenticated state within IAM Identity Center and serves as the foundation for creating other session types. User interactive sessions can last for the duration configured in IAM Identity Center, which can be up to 90 days.
User interactive sessions are the primary authentication mechanism. They end when the user signs out or when an administrator ends their session. The duration of these sessions should be carefully configured based on your organization's security requirements.
For information about configuring user interactive session duration, see [Configure the session duration in IAM Identity Center](configure-user-session.md).
### Application sessions
Application sessions are the authenticated connections between users and AWS managed applications (such as Kiro or Amazon Quick) that IAM Identity Center establishes through single sign-on.
By default, application sessions have a one hour lifetime, but they're automatically refreshed as long as the underlying user interactive session remains valid. This refresh mechanism provides a seamless experience for users while maintaining security controls. When a user interactive session ends, either through user sign-out or administrator action, the application sessions will end at their next refresh attempt, typically within 30 minutes.
### User background sessions
User background sessions are extended-duration sessions designed for applications that need to run processes for hours or days without interruption. Currently, this session type applies primarily to [Amazon SageMaker Studio](https://docs.aws.amazon.com//sagemaker/latest/dg/studio-updated.html), where data scientists might run machine learning training jobs that take many hours to complete.
For information about configuring user background session duration, see [User background sessions](user-background-sessions.md).
### Kiro sessions
You can extend Kiro sessions to allow developers using Kiro in IDEs to maintain authentication for up to 90 days. This feature reduces login interruptions while you work on code.
These sessions are independent of other session types and don't affect user interactive sessions or other AWS managed applications. Depending on when you enabled IAM Identity Center, this feature might be enabled by default.
For information about configuring extended Kiro sessions, see [Extended sessions for Kiro](90-day-extended-session-duration.md).
### IAM Identity Center-created IAM role sessions
IAM Identity Center creates a different type of session when users access the AWS Management Console or AWS CLI. In these cases, IAM Identity Center uses the sign-in session to obtain an IAM session by assuming an IAM role specified in the user's permission set.
**Important**
Unlike application sessions, IAM role sessions operate independently once established. They persist for the duration configured in the permission set, which can be up to 12 hours, regardless of the status of the original sign-in session. This behavior ensures that long-running CLI operations or console sessions aren't unexpectedly ended.
## Ways to end user sessions in IAM Identity Center
### User-initiated
When a user signs out of the AWS access portal, the sign-in session ends, preventing the user from accessing any new resources.
Existing application sessions, however, don't end instantly. Instead, they will end within approximately 30 minutes, when they attempt their next refresh and find the sign-in session is no longer valid. Existing IAM role sessions continue until they expire based on the permission set configuration, which could be up to 12 hours later.
### Administrator-initiated
Anyone with IAM Identity Center administrative permissions in your organization, typically IT administrators or security teams, can [end a user's session](end-active-sessions.md). This action works the same way as if users signed out themselves, allowing administrators to require users to sign in again when needed. This capability is useful when security policies change or when suspicious activity is detected.
When an IAM Identity Center administrator [deletes a user](deleteusers.md) or [disables a user’s access](disableuser.md), the user loses access to the AWS access portal and is prevented from signing back in to start a new application or IAM role session. The user will lose access to existing application sessions within 30 minutes. Any existing IAM role sessions will continue based on the session duration configured in the IAM Identity Center permission set. The maximum session duration can be 12 hours.
## What happens to user access when you end a session
This reference provides detailed information about how IAM Identity Center sessions behave when administrative actions are taken. The tables in this section show the duration and effects of user management actions and permission changes on access to the AWS access portal, applications, and AWS account sessions.
### User management
This table summarizes how user management changes affect access to AWS resources, application sessions, and AWS account sessions.
| Action | User loses IAM Identity Center access | User can't create new application sessions | User can't access existing application sessions | User loses access to existing AWS account sessions |
| --- | --- | --- | --- | --- |
| User's access disabled | Effective immediately | Effective immediately | Within 30 minutes | Within 12 hours or less. Duration depends on IAM role session expiry duration configured for the permission set. |
| User deleted | Effective immediately | Effective immediately | Within 30 minutes | Within 12 hours or less. Duration depends on IAM role session expiry duration configured for the permission set. |
| User session revoked | User must sign in again to regain access | Effective immediately | Within 30 minutes | Within 12 hours or less. Duration depends on IAM role session expiry duration configured for the permission set. |
| User signs out | User must sign in again to regain access | Effective immediately | Within 30 minutes | Within 12 hours or less. Duration depends on IAM role session expiry duration configured for the permission set. |
### Group membership
This table summarizes how changes to user permissions and group memberships affect access to AWS resources, application sessions, and AWS account sessions.
| Action | User loses IAM Identity Center access | User can't create new application sessions | User can't access existing application sessions | User loses access to existing AWS account sessions |
| --- | --- | --- | --- | --- |
| Application or AWS account access removed from user | No - User can continue accessing IAM Identity Center | Effective immediately | Within 1 hour | Within 12 hours or less. Duration depends on IAM role session expiry duration configured for the permission set. |
| User removed from group that had an assigned application or AWS account | No - User can continue accessing IAM Identity Center | Within 1 hour | Within 2 hours | Within 12 hours or less. Duration depends on IAM role session expiry duration configured for the permission set. |
| Application or AWS account access removed from group | No - User can continue accessing IAM Identity Center | Effective immediately | Within 1 hour | Within 12 hours or less. Duration depends on IAM role session expiry duration configured for the permission set. |
**Note**
The AWS access portal and AWS CLI will reflect updated user permissions within 1 hour after you add or remove a user from that group.
**Understanding timing differences**
+ **Effective immediately** – Actions that require immediate re-authentication.
+ **Within 30 minutes - 2 hours** – Application sessions need time to check with IAM Identity Center and discover any changes.
+ **Within 12 hours or less** – IAM role sessions operate independently and only end when their configured duration expires.
## Single logout
IAM Identity Center doesn't support SAML Single Logout (a protocol that automatically signs users out of all connected applications when they sign out of one) initiated by an identity provider that acts as your [identity source](manage-your-identity-source.md). Additionally, it doesn't send SAML Single Logout to [SAML 2.0 applications](customermanagedapps-saml2-oauth2.md) that use IAM Identity Center as an identity provider.
## Best practices for session management
Effective session management requires thoughtful configuration and monitoring. Organizations should configure session durations appropriate to their security requirements, generally using shorter durations for sensitive applications and environments.
Implementing processes to end sessions when users change roles or leave the organization is essential for maintaining security boundaries. Regular review of active sessions should be incorporated into security monitoring practices to detect anomalous behavior that might indicate security issues, such as unusual access patterns, unexpected login times or locations, or access to resources outside normal job functions.
# Configure the session duration in IAM Identity Center
You can configure the session duration for your workforce users when they use the AWS access portal and applications that work with IAM Identity Center, including Kiro. IAM Identity Center provides the following session types: user interactive sessions, user background sessions, and extended sessions for Kiro.
**Topics**
+ [User interactive sessions](user-interactive-sessions.md)
+ [User background sessions](user-background-sessions.md)
+ [Extended sessions for Kiro](90-day-extended-session-duration.md)
+ [View and end active sessions for your workforce users](end-active-sessions.md)
+ [Session duration considerations for using identity sources, the AWS CLI, and AWS SDKs](user-session-duration-prereqs-considerations.md)
# User interactive sessions
User interactive sessions are sessions tied to a user's sign-in to the AWS access portal or access to [AWS managed applications](awsapps.md). The session duration of authentication into the AWS access portal and applications is the maximum length of time that a user can be signed in without re-authenticating. If you end an active AWS access portal session, this also ends any sessions for these managed applications.
The default session duration for user interactive sessions is 8 hours. You can specify a different duration, from a minimum of 15 minutes to a maximum of 90 days. Custom duration values must be entered in minutes and be between 15 minutes and 129,600 minutes (90 days). For more information, see [Understanding authentication sessions in IAM Identity Center](authconcept.md).
For considerations such as how IAM Identity Center identity sources might affect the user interactive session duration, see [Session duration considerations for using identity sources, the AWS CLI, and AWS SDKs](user-session-duration-prereqs-considerations.md).
**To configure the duration of a user interactive session**
1. Open the IAM Identity Center console.
1. Choose **Settings**.
1. On the **Settings** page, choose the **Authentication** tab.
1. Under **Authentication**, next to **Session duration**, choose **Configure**. A **Configure session duration** dialog box appears.
1. In the **Configure session duration** dialog box, under **User interactive sessions**, choose the maximum session duration for your users by selecting the drop-down arrow. Choose the length for the session, and then choose **Save**.
**Note**
Changes to session duration apply only to new sessions. Current sessions keep their original duration.
1. You are returned to the **Authentication** tab. A green notification message appears above the tab indicates that the session settings were updated successfully.
# User background sessions
User background sessions allow a user to initiate a long-running job on an AWS managed application such as [Amazon SageMaker Studio](https://docs.aws.amazon.com//sagemaker/latest/dg/studio-updated.html), without that user having to remain signed in while the job runs. The job runs immediately and uses the [trusted identity propagation](trustedidentitypropagation-overview.md) capability of IAM Identity Center to ensure that the user's permissions are maintained while the job is run in the background. The job can continue to run even if the user turns off their computer, their IAM Identity Center sign-in session expires, or the user signs out of the AWS access portal. This capability enables data scientists, machine learning engineers, and others to start analytics and machine learning workflows that run in the background without active user involvement.
User background sessions are enabled by default for supported AWS managed applications such as Amazon SageMaker Studio. To use this capability, however, you must enable trusted identity propagation in Amazon SageMaker Studio when you create or update a domain. For more information, see [Enable trusted identity propagation in your Amazon SageMaker AI domain](https://docs.aws.amazon.com//sagemaker/latest/dg/trustedidentitypropagation-setup.html#trustedidentitypropagation-setup-enable).
The default session duration for user background sessions is 7 days. You can specify a different duration, from a minimum of 15 minutes to a maximum of 90 days. Custom duration values must be entered in minutes and be between 15 minutes and 129,600 minutes (90 days).
Keep in mind the following considerations for user background sessions:
+ A user background session can be created only when a user manually initiates a job in Amazon SageMaker Studio. This capability is not supported for automated, scheduled workflows.
+ For a list of AWS Regions that support user background sessions, see [Supported AWS Regions](https://docs.aws.amazon.com//sagemaker/latest/dg/trustedidentitypropagation-compatibility.html#trustedidentitypropagation-compatibility-supported-regions).
+ You can view user background sessions in CloudTrail. For information, see [Identifying user background session details](sso-cloudtrail-use-cases.md#identifying-user-background-session-details).
+ You can also end active sessions for a user in your organization. For information, see [End active sessions for your workforce users](end-active-sessions.md).
**To configure the duration of a user background session**
1. Open the IAM Identity Center console.
1. Choose **Settings**.
1. On the **Settings** page, choose the **Authentication** tab.
1. Under **Authentication**, next to **Session duration**, choose **Configure**. The **Configure session duration** dialog box appears.
1. In the **Configure session duration** dialog box, if the **Enable user background sessions** check box is not already selected, select it. Clear the check box to disable user background sessions.
**Note**
Current sessions are not affected if you disable user background sessions.
1. Under **User background sessions**, choose the maximum session duration by selecting the drop-down arrow. Choose the length for the session, and then choose **Save**.
**Note**
Changes to session duration apply only to new sessions. Current sessions keep their original duration.
1. You are returned to the **Authentication** tab. A green notification message appears above the tab indicates that the session settings were updated successfully.
**Note**
A customer managed application can't create a user background session.
# Extended sessions for Kiro
If your developers use Kiro as part of an integrated development environment (IDE), you can set the session duration for Kiro to 90 days. Depending on when you enabled IAM Identity Center, extended session duration for Kiro might be enabled by default. This extended session doesn't affect the session duration of the AWS access portal or other AWS managed applications.
For considerations such as how IAM Identity Center identity sources might affect the extended session duration, see [Session duration considerations for using identity sources, the AWS CLI, and AWS SDKs](user-session-duration-prereqs-considerations.md).
**Note**
Kiro is accessible from consoles set to commercial AWS Regions that are enabled by default. If your IAM Identity Center instance is located in a Region where Kiro isn't currently accessible, enabling 90 day extended session duration won't override the default setting. This means that your session duration remains unchanged, whether you enable 90 day extended session duration or not. For information, [Supported AWS Regions for Kiro](https://docs.aws.amazon.com//amazonq/latest/qdeveloper-ug/regions.html).
**To extend a session for Kiro**
1. Open the IAM Identity Center console.
1. Choose **Settings**.
1. On the **Settings** page, choose the **Authentication** tab.
1. Under **Authentication**, next to **Session duration**, choose **Configure**. A **Configure session duration** dialog box appears.
1. In the **Configure session duration** dialog box, select the **Enable extended sessions for Kiro** check box. Clear the check box to disable extended session sessions for Kiro.
1. Choose **Save** to return to the **Settings** page.
# View and end active sessions for your workforce users
As an IAM Identity Center administrator, you can view the list of your workforce users' active sessions, and if required, end one or more sessions for a user. For example, you might need to end a user's sessions when:
+ The user no longer requires the sessions.
+ The user shouldn't maintain their current authentication state. This can occur when they leave the company or their permissions change.
You can view and end these sessions by using the IAM Identity Center console. Your users can also view and end their own sessions by using the AWS access portal. For information about how your workforce users can view and end their sessions without assistance from an administrator, see [Viewing and ending your active session](end-user-how-to-end-active-sessions-accessportal.md).
**Note**
Ending an active session for an IAM Identity Center user doesn't end any active IAM role sessions in the AWS Management Console or AWS CLI. For more information, see [Understanding authentication sessions in IAM Identity Center](authconcept.md).
**To end an active session for a workforce user (IAM Identity Center console)**
1. Open the IAM Identity Center console.
1. Choose **Users**.
1. On the **Users** page, choose the username of the user whose sessions you want to manage. This takes you to a page with the user's information.
1. On the user's page, choose the **Active sessions** tab. The number in parentheses next to **Active sessions** indicates the number of active sessions for this user.
1.
**Search for user background sessions (optional)**
To search for sessions by the Amazon Resource Name (ARN) of the job that is using the session, in the **Session type** list, choose **User background sessions**, and then enter the job ARN in the search box.
**Note**
You can only end active sessions that are loaded. If a user has many sessions, choose **Load more active sessions** to display additional sessions.
1. Select the check box next to each session that you want to end, and then choose **End sessions**.
1. A dialog box appears that confirms you are ending active sessions for this user. Review the information, and if you want to continue, type `confirm`, and then choose **End sessions**.
1. You are returned to the user's page. A green notification message appears to indicate that the selected sessions were successfully ended.
# Session duration considerations for using identity sources, the AWS CLI, and AWS SDKs
Following are considerations for configuring the session duration if you use Microsoft Active Directory (AD) or an external identity provider (IdP) as the identity source, or the AWS Command Line Interface, AWS Software Development Kits (SDKs), or other AWS development tools to access AWS services programmatically.
## Microsoft Active Directory, user interactive sessions, and extended sessions for Kiro
If you use Microsoft Active Directory (AD) as the identity source and you configure the session duration for user interactive sessions or extended sessions for Kiro, keep the following considerations in mind.
**Note**
These considerations do not apply to user background sessions.
Whether you use AWS Managed Microsoft AD or AD Connector configured in AWS Directory Service, the maximum lifetime for user Kerberos tickets defined in Microsoft AD can affect how long user interactive sessions and extended sessions for Kiro are valid. For more information about this setting, see [Maximum lifetime for user ticket](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket) on the Microsoft website.
+ **AWS Managed Microsoft AD**: If you use AWS Managed Microsoft AD configured in AWS Directory Service, the maximum lifetime for user Kerberos tickets is fixed at 10 hours. Therefore, the user interactive session duration is set to the shorter of the IAM Identity Center setting and 10 hours. For example, if you set the user interactive session duration to 12 hours, your users must re-authenticate in the AWS access portal after 10 hours. The same 10-hour limit applies to extended sessions for Kiro.
+ **AD Connector**: If you use AD Connector configured in AWS Directory Service, the maximum lifetime for user Kerberos tickets is defined in Microsoft AD behind the AD Connector. The default value is 10 hours, and it has the same effect on user interactive sessions and extended sessions as for AWS Managed Microsoft AD. Although this limit might be configurable in Microsoft AD, we recommend that you work with your IT administrator to consider the risks, especially because this setting can affect the session duration for other Microsoft AD client applications.
## External identity providers, user interactive sessions, and extended sessions for Kiro
If you use an external identity provider (IdP) and you configure the session duration for user interactive sessions or extended sessions for Kiro, keep the following considerations in mind.
**Note**
These considerations do not apply to user background sessions.
IAM Identity Center uses `SessionNotOnOrAfter` attribute from SAML assertions to help determine how long the session can be valid.
+ If `SessionNotOnOrAfter` is not passed in a SAML assertion, the duration of an AWS access portal (user interactive) session and an extended session is not impacted by the duration of your external IdP session. For example, if your IdP session duration is 24 hours and you set an 18-hour session duration in IAM Identity Center, your users must re-authenticate in the AWS access portal after 18 hours. Similarly, if you set a 90-day extended session for Kiro, your Kiro users need to re-authenticate after 90 days.
+ If `SessionNotOnOrAfter` is passed in a SAML assertion, the session duration value is set to the shorter of the AWS access portal (user interactive) session or extended session duration and your SAML IdP session duration. If you set a 72-hour session duration in IAM Identity Center and your IdP has a session duration of 18 hours, your users will have access to AWS resources for the 18 hours defined in your IdP. Similarly, if you set a 90-day extended session for Kiro, your Kiro users need to re-authenticate in Kiro after 18 hours.
+ If the session duration of your IdP is longer than the one set in IAM Identity Center, your users can start a new IAM Identity Center session without re-entering their credentials, based on their still-valid login session with your IdP.
## AWS CLI and SDK sessions
If you are using the AWS CLI, AWS SDKs, or other AWS development tools to access AWS services programmatically, the following prerequisites must be met to set session duration for the AWS access portal and the AWS managed applications.
+ You must [configure the AWS access portal session duration](user-interactive-sessions.md) in the IAM Identity Center console.
+ You must define a profile for single sign-on settings in your shared AWS config file. This profile is used to connect to the AWS access portal. We recommend that you use the SSO token provider configuration. With this configuration, your AWS SDK or tool can automatically retrieve refreshed authentication tokens. For more information, see [SSO token provider configuration](https://docs.aws.amazon.com//sdkref/latest/guide/feature-sso-credentials.html#sso-token-config) in the *AWS SDK and Tools Reference Guide*.
+ Users must run a version of the AWS CLI or an SDK that supports session management.
### Minimum versions of the AWS CLI that support session management
Following are the minimum versions of the AWS CLI that support session management.
+ AWS CLI V2 2.9 or later
+ AWS CLI V1 1.27.10 or later
**Note**
For account access use cases, if your users are running the AWS CLI, if you refresh your permission set just before the IAM Identity Center session is set to expire and the session duration is set to 20 hours while the permission set duration is set to 12 hours, the AWS CLI session runs for the maximum of 20 hours plus 12 hours for a total of 32 hours. For more information about the IAM Identity Center CLI, see [AWS CLI Command Reference.](https://docs.aws.amazon.com/cli/latest/reference/identitystore)
### Minimum versions of SDKs that support IAM Identity Center session management
Following are the minimum versions of the SDKs that support IAM Identity Center session management.
****
| SDK | Minimum version |
| --- | --- |
| Python | 1.26.10 |
| PHP | 3.245.0 |
| Ruby | aws-sdk-core 3.167.0 |
| Java V2 | AWS SDK for Java v2 (2.18.13) |
| Go V2 | Whole SDK: release-2022-11-11 and specific Go modules: credentials/v1.13.0, config/v1.18.0 |
| JS V2 | 2.1253.0 |
| JS V3 | v3.210.0 |
| C\$1\$1 | 1.9.372 |
| .NET | v3.7.400.0 |
# Disable user access to AWS accounts and applications in IAM Identity Center
When you disable user access in your IAM Identity Center directory, you cannot edit their user details, reset their password, add the user to a group, or view their group membership. Disabling user access prevents them from signing in to the AWS access portal and they will no longer have access to their assigned AWS accounts and applications. Use disable user access for temporary access removal when you might need to restore access later.
Use the following procedure to disable user access in your Identity Center directory using the IAM Identity Center console.
**Note**
When you disable user access or delete a user in IAM Identity Center, that user will immediately be prevented from signing in to the AWS access portal and will not be able to create new sign in sessions. For more information, see [Understanding authentication sessions in IAM Identity Center](authconcept.md).
**To disable user access in IAM Identity Center**
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
**Important**
The instructions on this page apply to [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/). They do not apply to [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM). IAM Identity Center users, groups, and user credentials are different from IAM users, groups, and IAM user credentials. If you are looking for instructions on deactivating users in IAM, see [Managing IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html) in the *AWS Identity and Access Management User Guide*.
1. Choose **Users**.
1. Select the username of the user whose access you want to disable.
1. Below the username of the user whose access you want to disable, in the **General information** section, choose **Disable user access**.
1. In the **Disable user access** dialog box, choose **Disable user access**.
# Deny user access with Service Control Policies
To immediately deny access to make authorized API calls when an IAM Identity Center user's access is disabled or the user is deleted, you can:
1. [Add or update](howtoviewandchangepermissionset.md) the [inline policy](permissionsetcustom.md#permissionsetsinlineconcept) of the permission set(s) assigned to the user by adding an explicit `Deny` effect for all actions on all resources.
1. Specify the `aws:userid` or `identitystore:userid` condition key.
Alternatively, you can use a [Service Control Policy](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) to deny the user's access across all member accounts in your organization.
**Example SCP to deny access**
This denial policy blocks all AWS actions for a specific user, regardless of other permissions they might have been granted elsewhere. This policy overrides any `Allow` policies.
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:UserId": "*:deleteduser@domain.com"
}
}
}
]
}
```
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringEquals": {
"identitystore:UserId": "DELETEDUSER_ID"
}
}
}
]
}
```
# Managing access for users in the Identity Center directory
Learn how to manage passwords and multi-factor authentication (MFA) for users in the IAM Identity Center directory. These security features help protect user accounts.
**Note**
These features do not apply to Active Directory users or external identity provider users.
Administrators can manage both passwords and MFA through the IAM Identity Center console. These security features work only with the built-in Identity Center directory.
## Password management
Password management includes these capabilities:
+ Reset passwords with email instructions
+ Generate one-time passwords
+ Configure automatic email verification for API-created users
AWS enforces fixed security requirements, including complexity rules and password reuse restrictions.
## MFA
MFA is enabled by default and supports up to eight devices per user.
Supported device types include:
+ Authenticator apps
+ Security keys
+ Built-in biometric authenticators
Administrators can register and manage MFA devices for users.
**Topics**
+ [Password management](#password-management-overview)
+ [MFA](#mfa-overview)
+ [Setting up user passwords](set-up-user-passwords.md)
+ [MFA for Identity Center directory users](enable-mfa.md)
# Setting up user passwords
For users created in the Identity Center directory, administrators can manage password policies, handle users without initial passwords, and reset passwords when needed. These password management features apply only to users in the built-in Identity Center directory. If you're using Active Directory or an external identity provider, you must manage passwords in those systems.
**Password management options**
+ **Password requirements** – Security requirements that users must meet when setting or changing passwords. This includes complexity rules and reuse restrictions.
+ **One-time password setup** – Configure email verification for users created through API or CLI who don't have initial passwords. You can also generate temporary passwords for immediate access.
+ **Password resets** – Reset passwords for users who are locked out or need new credentials. You can send reset instructions using email or generate one-time passwords.
**Topics**
+ [Password requirements when managing identities in IAM Identity Center](password-requirements.md)
+ [Email one-time password to users created with API or CLI](userswithoutpwd.md)
+ [Reset the IAM Identity Center user password for an end user](reset-password-for-user.md)
# Password requirements when managing identities in IAM Identity Center
**Note**
These requirements apply only to users created in the Identity Center directory. If you have configured an identity source other than IAM Identity Center for authentication, such as [https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/introduction-to-active-directory-administrative-center-enhancements--level-100-#fine_grained_pswd_policy_mgmt](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/introduction-to-active-directory-administrative-center-enhancements--level-100-#fine_grained_pswd_policy_mgmt) or an [external identity provider](confirm-identity-source.md), the password policies for your users are defined and enforced in those systems, not in IAM Identity Center. If your identity source is AWS Managed Microsoft AD, see [Manage password policies for AWS Managed Microsoft AD](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/ms_ad_password_policies.html) for more information.
When you use IAM Identity Center as your identity source, users must adhere to the following password requirements to set or change their password:
+ Passwords are case-sensitive.
+ Passwords must be between 8 and 64 characters in length.
+ Passwords must contain at least one character from each of the following four categories:
+ Lowercase letters (a-z)
+ Uppercase letters (A-Z)
+ Numbers (0-9)
+ Non-alphanumeric characters (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/)
+ The last three passwords cannot be reused.
+ Passwords that are publicly known through a data set leaked from a third party cannot be used.
# Email one-time password to users created with API or CLI
When you create users with the [https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_CreateUser.html](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_CreateUser.html) API operation or the `create-user` CLI command, the users do not have passwords. You can update the settings in IAM Identity Center to send these users a verification email after their first attempt to sign in, if you’ve specified an email for the user when they were created. After receiving the verification email, the user must set a password to sign in.
If you don’t enable this setting, you must [generate a one-time password](reset-password-for-user.md) and share it with users that you create using the CreateUser API or `create-user` CLI command.
**To send an email address verification email to users created with the CreateUser API or `create-user` CLI command**
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. Choose **Settings**.
1. On the **Settings** page, choose the **Authentication** tab.
1. In the **Standard authentication** section, choose ** Configure**.
1. In the **Configure standard authentication** dialog box, select the **Send email OTP** check box. Then, choose **Save**. The status updates from **Disabled** to **Enabled**.
# Reset the IAM Identity Center user password for an end user
This procedure is for administrators who need to reset the password for a user in the IAM Identity Center directory. You'll use the IAM Identity Center console to reset passwords.
**Considerations for identity providers and user types**
+ **Microsoft Active Directory or external provider** – If you are connecting IAM Identity Center to Microsoft Active Directory or an external provider, user password resets must be done from within Active Directory or the external provider. This means that passwords for those users cannot be reset from the IAM Identity Center console.
+ **Users in the IAM Identity Center directory** – If you are an IAM Identity Center user, you can reset your own IAM Identity Center password, see [Resetting your AWS access portal user password](resetpassword-accessportal.md).
**To reset a password for an IAM Identity Center end user**
**Important**
The instructions on this page apply to [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/). They do not apply to [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM). IAM Identity Center users, groups, and user credentials are different from IAM users, groups, and IAM user credentials. If you are looking for instructions on changing passwords for IAM users, see [ Managing passwords for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_admin-change-user.html) in the *AWS Identity and Access Management User Guide*.
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. Choose **Users**.
1. Select the username of the user whose password you want to reset.
1. On the user details page, choose **Reset password**.
1. In the **Reset password** dialog box, select one of the following choices, and then choose **Reset password**:
1. **Send an email to the user with instructions to reset the password** – This option automatically sends the user an email addressed from Amazon Web Services that walks them through how to reset their password.
**Warning**
As a security best practice, verify that the email address for this user is correct prior to selecting this option. If this password reset email were to be sent to an incorrect or misconfigured email address, a malicious recipient could use it to gain unauthorized access to your AWS environment.
1. **Generate a one-time password and share the password with the user** – This option provides you with the password details that you can manually send to the user from your email address.
# MFA for Identity Center directory users
**Important**
MFA in IAM Identity Center is currently not supported for [external identity providers](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html).
IAM Identity Center comes preconfigured with multi-factor authentication (MFA) turned on by default so that all users must sign in with MFA in addition to their user name and password. This ensures that users must sign in to the AWS access portal using the following two factors:
+ Their user name and password. This is the first factor and is something users know.
+ Either a code, security key, or biometrics. This is the second factor and is something users have (possession) or are (biometric). The second factor might be either an authentication code generated from their mobile device, a security key connected to their computer, or user’s biometric scan.
Together, these multiple factors provide increased security by preventing unauthorized access to your AWS resources unless a valid MFA challenge has been successfully completed.
Each user can register up to two virtual authenticator apps, which are one-time password authenticator applications installed on your mobile device or tablet, and six FIDO authenticators, which include built-in authenticators and security keys, for a total of **eight** MFA devices. Learn more about [Available MFA types for IAM Identity Center](mfa-types.md).
**Topics**
+ [Available MFA types for IAM Identity Center](mfa-types.md)
+ [Configure MFA in IAM Identity Center](mfa-configure.md)
+ [Register an MFA device for users](how-to-register-device.md)
+ [Renaming and deleting MFA devices in IAM Identity Center](how-to-manage-device.md)
# Available MFA types for IAM Identity Center
Multi-factor authentication (MFA) is a simple and effective mechanism to enhance the security of your users. A user’s first factor — their password — is a secret that they memorize, also known as a knowledge factor. Other factors can be possession factors (something you have, such as a security key) or inherence factors (something you are, such as a biometric scan). We strongly recommend that you configure MFA to add an additional layer of security to your account.
IAM Identity Center MFA supports the following device types. All MFA types are supported for both browser-based console access as well as using the AWS CLI v2 with IAM Identity Center.
+ [FIDO2 authenticators](#mfa-types-fido2), including built-in authenticators and security keys
+ [Virtual authenticator apps](#mfa-types-apps)
+ Your own [RADIUS MFA](#about-radius) implementation connected through AWS Managed Microsoft AD
A user can have up to **eight** MFA devices, which include up to two virtual authenticator apps and six FIDO authenticators, registered to one AWS account. You can also configure MFA settings to require MFA whenever they attempt to sign-in from a new device or browser, or when signing in from an unknown IP address. For more information about how to configure MFA settings for your users, see [Choose MFA types for user authentication](how-to-configure-mfa-types.md) and [Configure MFA device enforcement](how-to-configure-mfa-device-enforcement.md).
## FIDO2 authenticators
[FIDO2](https://fidoalliance.org/fido2/) is a standard that includes CTAP2 and [WebAuthn](https://www.w3.org/TR/webauthn-2/) and is based on public key cryptography. FIDO credentials are phishing-resistant because they are unique to the website that the credentials were created such as AWS.
AWS supports the two most common form factors for FIDO authenticators: built-in authenticators and security keys. See below for more information about the most common types of FIDO authenticators.
**Topics**
+ [Built-in authenticators](#mfa-types-built-in-auth)
+ [Security keys](#mfa-types-keys)
+ [Password managers, passkey providers, and other FIDO authenticators](#mfa-types-other)
### Built-in authenticators
Many modern computers and mobile phones have built-in authenticators, such as TouchID on Macbook or a Windows Hello-compatible camera. If your device has a FIDO-compatible built-in authenticator, you can use your fingerprint, face, or device pin as a second factor.
### Security keys
Security keys are FIDO-compatible external hardware authenticators that you can purchase and connect to your device through USB, BLE, or NFC. When you’re prompted for MFA, you simply complete a gesture with the key’s sensor. Some examples of security keys include YubiKeys and Feitian keys, and the most common security keys create device-bound FIDO credentials. For a list of all FIDO-certified security keys, see [FIDO Certified Products](https://fidoalliance.org/certification/fido-certified-products/).
### Password managers, passkey providers, and other FIDO authenticators
Multiple third party providers support FIDO authentication in mobile applications, as features in password managers, smart cards with a FIDO mode, and other form factors. These FIDO-compatible devices can work with IAM Identity Center, but we recommend that you test a FIDO authenticator yourself before enabling this option for MFA.
**Note**
Some FIDO authenticators can create discoverable FIDO credentials known as passkeys. Passkeys may be bound to the device that creates them, or they may be syncable and backed up to a cloud. For example, you can register a passkey using Apple Touch ID on a supported Macbook, and then log in to a site from a Windows laptop using Google Chrome with your passkey in iCloud by following the on-screen prompts at sign-in. For more information about which devices support syncable passkeys and current passkey interoperability between operating systems and browsers, see [Device Support](https://passkeys.dev/device-support/) at [passkeys.dev](https://passkeys.dev/), a resource maintained by the FIDO Alliance And World Wide Web Consortium (W3C).
## Virtual authenticator apps
Authenticator apps are essentially one-time password (OTP)–based third party-authenticators. You can use an authenticator application installed on your mobile device or tablet as an authorized MFA device. The third-party authenticator application must be compliant with RFC 6238, which is a standards-based time-based one-time password (TOTP) algorithm capable of generating six-digit authentication codes.
When prompted for MFA, users must enter a valid code from their authenticator app within the input box presented. Each MFA device assigned to a user must be unique. Two authenticator apps can be registered for any given user.
### Tested authenticator apps
Any TOTP-compliant application will work with IAM Identity Center MFA. The following table lists well-known third-party authenticator apps to choose from.
| Operating system | Tested authenticator app |
| --- | --- |
| Android | [https://play.google.com/store/apps/details?id=com.authy.authy](https://play.google.com/store/apps/details?id=com.authy.authy), [https://play.google.com/store/apps/details?id=com.duosecurity.duomobile](https://play.google.com/store/apps/details?id=com.duosecurity.duomobile), [https://play.google.com/store/apps/details?id=com.azure.authenticator](https://play.google.com/store/apps/details?id=com.azure.authenticator), [https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2](https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2) |
| iOS | [https://apps.apple.com/us/app/authy/id494168017](https://apps.apple.com/us/app/authy/id494168017), [https://apps.apple.com/us/app/duo-mobile/id422663827](https://apps.apple.com/us/app/duo-mobile/id422663827), [https://apps.apple.com/us/app/microsoft-authenticator/id983156458](https://apps.apple.com/us/app/microsoft-authenticator/id983156458), [https://apps.apple.com/us/app/google-authenticator/id388497605](https://apps.apple.com/us/app/google-authenticator/id388497605) |
## RADIUS MFA
[Remote Authentication Dial-In User Service (RADIUS)](https://en.wikipedia.org/wiki/RADIUS) is an industry-standard client-server protocol that provides authentication, authorization, and accounting management so users can connect to network services. Directory Service includes a RADIUS client that connects to the RADIUS server upon which you have implemented your MFA solution. For more information, see [Enable Multi-Factor Authentication for AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_mfa.html).
You can use either RADIUS MFA or MFA in IAM Identity Center for user sign-ins to the user portal, but not both. MFA in IAM Identity Center is an alternative to RADIUS MFA in cases where you want AWS native two-factor authentication for access to the portal.
When you enable MFA in IAM Identity Center, your users need an MFA device to sign in to the AWS access portal. If you had previously used RADIUS MFA, enabling MFA in IAM Identity Center effectively overrides RADIUS MFA for users who sign in to the AWS access portal. However, RADIUS MFA continues to challenge users when they sign in to all other applications that work with Directory Service, such as Amazon RDS for SQL Server.
If your MFA is **Disabled** on the IAM Identity Center console and you have configured RADIUS MFA with Directory Service, RADIUS MFA governs AWS access portal sign-in. This means that IAM Identity Center falls back to RADIUS MFA configuration if MFA is disabled.
# Configure MFA in IAM Identity Center
You can configure Multi-factor authentication (MFA) capabilities in IAM Identity Center when your identity source is configured with IAM Identity Center’s identity store, AWS Managed Microsoft AD, or AD Connector. MFA in IAM Identity Center is currently not supported for [external identity providers](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html).
The following are general MFA recommendations, depending on your IAM Identity Center settings and organizational preferences.
+ Users are encouraged to register multiple backup authenticators for all enabled MFA types. This practice can prevent loss of access in case of a broken or misplaced MFA device.
+ Don't choose the **Require Them to Provide a One-Time Password Sent by Email** option if your users must sign in to the AWS access portal to access their email. For example, your users might use Microsoft 365 in the AWS access portal to read their email. In this case, users will not be able to retrieve the verification code and would be unable to sign in to the AWS access portal. For more information, see [Configure MFA device enforcement](how-to-configure-mfa-device-enforcement.md).
+ If you are already using RADIUS MFA that you configured with Directory Service, you do not need to enable MFA within IAM Identity Center. MFA in IAM Identity Center is an alternative to RADIUS MFA for Microsoft Active Directory users of IAM Identity Center. For more information, see [RADIUS MFA](mfa-types.md#about-radius).
+ The following YouTube video provides an overview of MFA and IAM Identity Center:
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/1iFvT8shnng?si=hpMeBAd85ypC3BTR)
**Topics**
+ [Prompt users for MFA](mfa-getting-started.md)
+ [Choose MFA types for user authentication](how-to-configure-mfa-types.md)
+ [Configure MFA device enforcement](how-to-configure-mfa-device-enforcement.md)
+ [Allow users to register their own MFA devices](how-to-allow-user-registration.md)
# Prompt users for MFA
You can use the following steps to determine how often workforce users are prompted for multi-factor authentication (MFA) whenever they attempt to sign-in to the AWS access portal. Before you begin, we recommend that you understand the [Available MFA types for IAM Identity Center](mfa-types.md).
**Important**
The instructions in this section apply to [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/). They do not apply to [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM). IAM Identity Center users, groups, and user credentials are different from IAM users, groups, and IAM user credentials. If you are looking for instructions on deactivating MFA for IAM users, see [Deactivating MFA devices](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_disable.html) in the *AWS Identity and Access Management User Guide*.
**Note**
If you’re using an external IdP, the **Multi-factor authentication** section will not be available. Your external IdP manages MFA settings, rather than IAM Identity Center managing them.
**To configure MFA**
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. In the left navigation pane, choose **Settings**.
1. On the **Settings** page, choose the **Authentication** tab.
1. In the **Multi-factor authentication** section, choose **Configure**.
1. On the **Configure multi-factor authentication** page, under **Prompt users for MFA**, choose one of the following authentication modes based on the level of security that your business needs:
+ **Every time they sign in (always-on)**
In this mode (the default setting), IAM Identity Center requires that users with a registered MFA device will be prompted every time they sign in. This is the most secure setting and ensures that your organizational or compliance policies are enforced by requiring that MFA be used every time they sign in to the AWS access portal. For example, PCI DSS strongly recommends MFA during every sign-in to access applications that support high-risk payment transactions.
+ **Only when their sign-in context changes (context-aware)**
In this mode, IAM Identity Center provides users the option to trust their device during sign-in. After a user indicates that they want to trust a device, IAM Identity Center prompts the user for MFA once and analyzes the sign-in context (such as device, browser, and location) for the user’s subsequent sign-ins. For subsequent sign-ins, IAM Identity Center determines if the user is signing in with a previously trusted context. If the user’s sign-in context changes, IAM Identity Center prompts the user for MFA in addition to their email address and password credentials.
This mode provides ease of use for users who frequently sign in from their workplace but is less secure then the **always-on** option. Users are only prompted for MFA if their sign-in context changes.
+ **Never (disabled)**
While in this mode, all users will sign in with their standard user name and password only. Choosing this option disables IAM Identity Center MFA and is not recommended.
While MFA is disabled for your Identity Center directory for users, you cannot manage MFA devices in their user details, and Identity Center directory users cannot manage MFA devices from the AWS access portal.
**Note**
If you are already using RADIUS MFA with Directory Service, and want to continue using it as your default MFA type, then you can leave the authentication mode as disabled to bypass MFA capabilities in IAM Identity Center. Changing from **Disabled** mode to **Context-aware** or **Always-on** mode will override the existing RADIUS MFA settings. For more information, see [RADIUS MFA](mfa-types.md#about-radius).
1. Choose **Save changes**.
**Related Topics**
+ [Choose MFA types for user authentication](how-to-configure-mfa-types.md)
+ [Configure MFA device enforcement](how-to-configure-mfa-device-enforcement.md)
+ [Allow users to register their own MFA devices](how-to-allow-user-registration.md)
# Choose MFA types for user authentication
Use the following procedure to choose the device types your users can authenticate with when prompted for multi-factor authentication (MFA) in the AWS access portal.
**To configure MFA types for your users**
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. In the left navigation pane, choose **Settings**.
1. On the **Settings** page, choose the **Authentication** tab.
1. In the **Multi-factor authentication** section, choose **Configure**.
1. On the **Configure multi-factor authentication** page, under **Users can authenticate with these MFA types** choose one of the following MFA types based on your business needs. For more information, see [Available MFA types for IAM Identity Center](mfa-types.md).
+ **Security keys and built-in authenticators**
+ **Authenticator apps**
1. Choose **Save changes**.
# Configure MFA device enforcement
Use the following procedure to determine whether your users must have a registered MFA device when signing in to the AWS access portal.
For more information about MFA in IAM, see [AWS Multi-factor authentication in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html).
**To configure MFA device enforcement for your users**
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. In the left navigation pane, choose **Settings**.
1. On the **Settings** page, choose the **Authentication** tab.
1. In the **Multi-factor authentication** section, choose **Configure**.
1. On the **Configure multi-factor authentication** page, under **If a user does not yet have a registered MFA device** choose one of the following choices based on your business needs:
+ **Require them to register an MFA device at sign in**
This is the default setting when you first configure MFA for IAM Identity Center. Use this option when you want to require users who do not yet have a registered MFA device, to self-enroll a device during sign-in following a successful password authentication. This allows you to secure your organization’s AWS environments with MFA without having to individually enroll and distribute authentication devices to your users. During self-enrollment, your users can register any device from the available [Available MFA types for IAM Identity Center](mfa-types.md) you've previously enabled. After completing registration, users have the option to give their newly enrolled MFA device a friendly name, after which IAM Identity Center redirects the user to their original destination. If the user’s device is lost or stolen, you can simply remove that device from their account, and IAM Identity Center will require them to self-enroll a new device during their next sign-in.
+ **Require them to provide a one-time password sent by email to sign in**
Use this option when you want to have verification codes sent to users by email. Because email is not bound to a specific device, this option does not meet the bar for industry-standard multi-factor authentication. But it does improve security over having a password alone. Email verification will only be requested if a user has not registered an MFA device. If the **Context-aware** authentication method has been enabled, the user will have the opportunity to mark the device on which they receive the email as trusted. Afterward they will not be required to verify an email code on future logins from that device, browser, and IP address combination.
**Note**
If you are using Active Directory as your IAM Identity Center enabled identity source, the email address will always be based on the Active Directory `email` attribute. Custom Active Directory attribute mappings will not override this behavior.
+ **Block their sign-in**
Use the **Block Their Sign-In** option when you want to enforce MFA use by every user before they can sign in to AWS.
**Important**
If your authentication method is set to **Context-aware** a user might select the **This is a trusted device** check box on the sign-in page. In that case, that user will not be prompted for MFA even if you have the **Block their sign in** setting enabled. If you want these users to be prompted, change your authentication method to **Always On**.
+ **Allow them to sign in**
Use this option to indicate that MFA devices are not required in order for your users to sign in to the AWS access portal. Users who chose to register MFA devices will still be prompted for MFA.
1. Choose **Save changes**.
# Allow users to register their own MFA devices
IAM Identity Center administrators can allow users to self-register their own MFA devices.
**To allow users to register their own MFA devices**
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. In the left navigation pane, choose **Settings**.
1. On the **Settings** page, choose the **Authentication** tab.
1. In the **Multi-factor authentication** section, choose **Configure**.
1. On the **Configure multi-factor authentication** page, under **Who can manage MFA devices**, choose **Users can add and manage their own MFA devices**.
1. Choose **Save changes**.
**Note**
After you set up self-registration for your users, you might want to send them a link to the procedure [Registering your device for MFABefore you begin](user-device-registration.md). This topic provides instructions on how to set up their own MFA devices.
# Register an MFA device for users
IAM Identity Center administrators can set up a new MFA device for access by a specific user in the IAM Identity Center console. Administrators must have physical access to the user's MFA device to register it. For example, if you configure MFA for a user who will use an MFA device running on a smartphone, you'll need physical access to the smartphone to complete the registration process. Alternatively, you can allow users to configure and manage their own MFA devices. For more information, see [Allow users to register their own MFA devices](how-to-allow-user-registration.md).
**To register an MFA device**
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. In the left navigation pane, choose **Users**. Choose a user in the list. Don't select the checkbox next to the user for this step.
1. On the user details page, choose the **MFA devices** tab, and then choose **Register MFA device**.
1. On the **Register MFA device** page, select one of the following MFA device types, and follow the instructions:
+ **Authenticator app**
1. On the **Set up the authenticator app** page, IAM Identity Center displays configuration information for the new MFA device, including a QR code graphic. The graphic is a representation of the secret key that is available for manual entry on devices that do not support QR codes.
1. Using the physical MFA device, do the following:
1. Open a compatible MFA authenticator app. For a list of tested apps that you can use with MFA devices, see [Virtual authenticator apps](mfa-types.md#mfa-types-apps). If the MFA app supports multiple accounts (multiple MFA devices), choose the option to create a new account (a new MFA device).
1. Determine whether the MFA app supports QR codes, and then do one of the following on the **Set up the authenticator app** page:
1. Choose **Show QR code**, and then use the app to scan the QR code. For example, you might choose the camera icon or choose an option similar to **Scan code**. Then use the device's camera to scan the code.
1. Choose **show secret key**, and then type that secret key into your MFA app.
**Important**
When you configure an MFA device for IAM Identity Center, we recommend that you save a copy of the QR code or secret key *in a secure place*. This can help if the assigned user loses the phone or has to reinstall the MFA authenticator app. If either of those things happen, you can quickly reconfigure the app to use the same MFA configuration. This avoids the need to create a new MFA device in IAM Identity Center for the user.
1. On the **Set up the authenticator app** page, under **Authenticator code**, type the one-time password that currently appears on the physical MFA device.
**Important**
Submit your request immediately after generating the code. If you generate the code 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. If this happens, you can resync the device.
1. Choose **Assign MFA**. The MFA device can now start generating one-time passwords and is now ready for use with AWS.
+ **Security key**
1. On the **Register your user's security key** page, follow the instructions given to you by your browser or platform.
**Note**
The experience here varies based on the different operating systems and browsers, so please follow the instructions displayed by your browser or platform. After your user's device has been successfully registered, you will be given the option to associate a friendly display name to your user's newly enrolled device. If you want to change this, choose **Rename**, enter the new name, and then choose **Save**. If you have enabled the option to allow users to manage their own devices, the user will see this friendly name in the AWS access portal.
# Renaming and deleting MFA devices in IAM Identity Center
IAM Identity Center administrators can use the following procedures to rename or delete a user's MFA device.
**To rename an MFA device**
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. In the left navigation pane, choose **Users**. Choose the user in the list. Don't select the checkbox next to the user for this step.
1. On the user details page, choose the **MFA devices** tab, select the device, and then choose **Rename**.
1. When prompted, enter the new name and then choose **Rename**.
**To delete an MFA device**
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. In the left navigation pane, choose **Users**. Choose the user in the list.
1. On the user details page, choose the **MFA devices** tab, select the device, and then choose **Delete**.
1. To confirm, type **DELETE**, and then choose **Delete**.