user locked out of okta after too many attempts

TL;DR

In Okta Admin, go to Directory > People > the user and click Unlock. Then check the sign-in logs for the failure source (wrong password, stale app token, or an actual attack) before telling the user they are clear.

The error

Your account is locked. Please contact your administrator.

Steps

1. In Okta Admin: Directory > People > search the user > click Unlock. Expected: status returns to Active. This is immediate; no sync wait.
2. Check Reports > System Log for the user's recent failures. Expected: you see the failure pattern. Ten password failures from one laptop is a typo loop; failures from many countries is an attack.
3. If the failures come from an old device or mail client, have the user update the saved password there or revoke the stale session. Expected: failures stop. Stale tokens are the top repeat-lockout cause.
4. Review the lockout policy (Security > Authenticators > Password > lockout settings). Expected: lockout threshold and duration match policy. Do not permanently loosen it for one user; use a temporary exception if needed.
5. Tell the user what caused it and the unlock is done. Expected: user signs in. Document the cause in the ticket.

When to use

• Okta shows the account as Locked
• Repeated lockouts with no user action (stale token likely)

When not to use

• The user is AD-mastered and Okta delegates auth: unlock in Active Directory
• The account is deactivated or suspended (different state, different fix)

Compatibility

• Okta Identity Engine; admin rights to Directory > People required

Variants

Locked again within an hour

Almost always a stale credential somewhere (phone mail app, old laptop, script). Find it in the system log by client IP and user agent.

Lockout during a password spray wave

Do not just unlock; check whether the failures are attacker-driven and consider keeping the lock until the wave passes.

Why it happens

Okta counts consecutive failed authentications per the password policy and locks the account to stop guessing. Legitimate users trip it with typos and stale saved passwords; attackers trip it deliberately.

Edge cases

• Service accounts used by scripts: exclude them from the standard lockout policy or the script will keep locking itself.
• Users with password managers that autofill old passwords after a reset: update the vault entry.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Q5qgAT01dccwH6RST4hIDA