A password policy is in place that locks a user after 5 incorrect credentials and unlocks after 60 minutes.
After the user gets locked, the admin unlocks the user manually or uses an API call to do it. After a few minutes, the user gets locked again. After exactly one hour from the first time the user got locked, the user gets unlocked.

 

• Okta login
• Password policy with a lock of user condition, and an auto-unlock condition after a number of minutes

The 60-minute event is not restarted when the user is unlocked by the admin or by API call, and after that, the user gets locked again.

A user gets locked after 5 failed login attempts. 

• At this moment, the user is automatically locked, and the 60-minute count begins until the user is auto-unlocked.
• After 5 minutes, the user is manually unlocked by the admin or via an API call. The user attempts to log in again and fails five times, then gets locked again after five minutes. The user got unlocked. The user is now auto-unlocked within 50 minutes of the last lock. Why not in 60 minutes?

Here is how the flow works on the backend when auto-unlock is enabled in the policy:

• At the same time, the user locks themselves out, and a job is scheduled to run in an hour to unlock them. The admin action does not reset this timer(being a manual unlock or using an API call). If the user is in an unlocked state at the time of the job running, it is a no-op.