Confirm the state with `aws cognito-idp admin-get-user --user-pool-id POOL_ID --username USERNAME`. Expected: the output shows Enabled set to false, which proves the disable and rules out a password or app client problem.

Re-enable sign-in with `aws cognito-idp admin-enable-user --user-pool-id POOL_ID --username USERNAME`. Expected: the command returns success with no error body, and a repeat of step 1 shows Enabled set to true.

Retry the sign-in exactly as the user did. Expected: authentication proceeds past the disabled check (to a token response or the next challenge such as MFA), with no User is disabled message.

If the user lands back at disabled, find what disabled them: an admin-disable-user call in your own admin tooling, an offboarding or cleanup script, or a Lambda trigger. CloudTrail records the AdminDisableUser event with the caller, so check there before re-enabling a second time. Expected: you can name the actor or automation that ran the disable.

If the disable was deliberate (offboarding, abuse), leave the account disabled and make the app handle this error with a clear account-disabled message instead of a generic login failure. Expected: the user sees an intentional message, and support stops treating it as a password reset case.