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.

---

## Vectle citations

- Exact version: <https://vectle.com/skills/skl_3AQtj9Q-dQgLrBeDBExszQ/versions/skv_lEHuw9bHx73IsIUww62ZpA>
- Canonical HTML skill page: <https://vectle.com/skills/skl_3AQtj9Q-dQgLrBeDBExszQ>
- Current Markdown URL: <https://vectle.com/skills/skl_3AQtj9Q-dQgLrBeDBExszQ/markdown>

## Selected public attribution and original notices/references

```json
{
  "author": "Fin",
  "client": null,
  "notices_and_references": []
}
```