Introduction

FORCE_CHANGE_PASSWORD is most commonly seen in Amazon Cognito when an administrator creates a user or sets a temporary password. It is not a status you usually toggle directly with a simple "set status" call. Instead, the user leaves that state by completing the required password change flow or by an administrator assigning a permanent password.

What FORCE_CHANGE_PASSWORD Means

In Cognito, this status indicates the current password is temporary. The user can authenticate only far enough to receive the NEW_PASSWORD_REQUIRED challenge, and then must set a new permanent password before the account becomes fully active.

That means the fix depends on who should complete the transition:

• the user during sign-in
• an administrator on the server side

Let the User Complete the Password Change Challenge

The normal user-driven path is:

1. sign in with username and temporary password
2. receive a NEW_PASSWORD_REQUIRED challenge
3. respond with the new password
4. Cognito promotes the account out of FORCE_CHANGE_PASSWORD

Using boto3, the challenge response looks like this:

1import boto3
2
3client = boto3.client('cognito-idp')
4
5challenge_response = client.respond_to_auth_challenge(
6    ClientId='your-app-client-id',
7    ChallengeName='NEW_PASSWORD_REQUIRED',
8    Session='session-from-initiate-auth',
9    ChallengeResponses={
10        'USERNAME': '[email protected]',
11        'NEW_PASSWORD': 'StrongerPassw0rd!'
12    }
13)
14
15print(challenge_response.keys())

That is the standard transition path when the user is expected to choose their own password.

Set a Permanent Password as an Administrator

If you want to skip the challenge and make the user immediately active, use the admin API to assign a permanent password.

1import boto3
2
3client = boto3.client('cognito-idp')
4
5client.admin_set_user_password(
6    UserPoolId='your-user-pool-id',
7    Username='[email protected]',
8    Password='StrongerPassw0rd!',
9    Permanent=True,
10)

When Permanent=True, Cognito changes the user's effective state so they no longer need to complete the forced password update at next login.

Check the Resulting User Status

If you want to verify the status afterward, inspect the user record.

1user = client.admin_get_user(
2    UserPoolId='your-user-pool-id',
3    Username='[email protected]',
4)
5
6print(user['UserStatus'])

That is better than assuming the transition happened, especially in admin automation or migration scripts.

Do Not Confuse Status with Enable or Disable State

A Cognito user can be enabled or disabled independently from password-change state. FORCE_CHANGE_PASSWORD is about authentication flow, not whether the account is enabled in general.

So if your code toggles account availability, that is a different API concern from resolving a temporary-password challenge.

Think About the User Experience Too

Even when an administrator can clear the forced-password state with a permanent password, that may not be the best product choice. In many systems, it is better for the user to choose their own password through the challenge flow so the final secret never passes through support or admin tooling.

Verify the Application Flow After the Status Change

After changing the password state, test a real sign-in path rather than relying only on the admin API response. The practical question is whether the user now authenticates with the intended experience, not just whether an administrative field changed. That end-to-end check catches client configuration mistakes and challenge-handling bugs quickly.

Common Pitfalls

• Looking for a direct "set status to confirmed" style call when the real mechanism is password handling.
• Forgetting that FORCE_CHANGE_PASSWORD usually comes from a temporary password lifecycle.
• Setting a new password with Permanent=False when the goal was to end the forced-change state.
• Confusing Cognito account enable or disable state with password challenge state.
• Assuming admin automation succeeded without checking the resulting user status.

Summary

• 'FORCE_CHANGE_PASSWORD in Cognito usually means the user has a temporary password.'
• The normal transition path is the NEW_PASSWORD_REQUIRED challenge during sign-in.
• Administrators can bypass that flow by setting a permanent password.
• Verify the outcome with admin_get_user instead of assuming the state changed.
• Treat password-challenge state and account enable or disable state as separate concerns.