What are common mistakes with Account Lockout Policy?

What usually goes wrong with account lockout thresholds?

The most common failure is tuning the threshold without modelling real user behaviour. If the limit is too low, normal mistakes, password resets, mobile retries or VPN reconnection can trigger avoidable lockouts; if it is too high, password spraying and slow guessing campaigns can continue long enough to be useful to an attacker.

Another frequent mistake is treating lockout as a simple on or off control rather than part of a broader authentication design. account lockout has to work alongside MFA, help desk reset procedures, monitoring and recovery paths, especially for privileged users and shared operational accounts that cannot safely be handled like ordinary user accounts.

Why service accounts, shared accounts and reset paths create blind spots

Account lockout policies often assume a single human user, but operational environments include service accounts, shared admin IDs and break-glass access. Those accounts may not fit the same threshold, unlock, audit and recovery rules, which means a standard policy can either break automation or leave a high-value account easier to abuse than intended.

Reset and unlock workflows are also a common weak point because they can become the easiest way around the policy. If help desk staff can unlock accounts with weak verification, or if exception handling is inconsistent, the policy shifts the risk from password guessing to account recovery abuse.

For privileged and emergency access patterns, the better model is to define the account class first and then set the lockout behaviour around the actual operational need. Break-Glass and Emergency Access Account Guide is useful background when the question is really about how lockout interacts with critical access paths rather than ordinary user login.

How lockout policy should be balanced in practice

A usable policy does not try to stop every failed login. It aims to make repeated guessing expensive enough to deter abuse while keeping legitimate users productive. That usually means considering lockout duration, reset timing, monitoring, step-up challenges and whether the environment has MFA or strong passwordless controls that already reduce the value of raw password guessing.

Policy design also needs to account for the fact that different failure patterns mean different things. A burst of failures from one user may be a typo problem, while repeated low-rate failures across many accounts can indicate password spraying. Top 10 MFA Mistakes is relevant here because lockout is much less effective if the organisation relies on weak fallback or messy recovery flows.

At the implementation level, the control should be measured by both user friction and security signal quality. If lockouts are rare but repeated guessing still succeeds, the threshold is too permissive; if support tickets and unlocks spike after normal business activity, the threshold is too aggressive or poorly aligned with real usage patterns.

Risk and Threat Considerations

Lockout policies carry a built-in trade-off between availability and attack resistance. Too much sensitivity can let an attacker trigger denial-of-service against users, while too little sensitivity leaves accounts exposed to password spraying, credential stuffing and low-and-slow guessing that is difficult to notice early.

Failure mechanism: The control fails when the threshold, reset window or exception handling does not match actual login behaviour, or when recovery paths are easier to abuse than the login itself.

Impact: Legitimate users can be locked out at the wrong time, privileged access can be disrupted, and attackers may be able to probe accounts long enough to find weak credentials or exploit weak unlock processes.

Practitioner Guidance

What to verify: Check whether the policy treats ordinary users, admins, service accounts and shared accounts differently where necessary. Verify that help desk unlock authority is tightly bounded, logged and resistant to social engineering, because recovery abuse is a common bypass path.

Decision rule: If the organisation already has phishing-resistant MFA or equivalent strong authentication for a user population, use lockout as a backstop against repeated guessing, not as the primary protective control. If the account is privileged or operationally critical, prioritise safer recovery design and blast-radius reduction before making the threshold more aggressive.

Practitioner takeaway: The best lockout policy is not the strictest one, it is the one that distinguishes human error from hostile guessing without creating a new outage path through recovery and exception handling.

Related resources from NHI Mgmt Group

• What common vulnerabilities do cloud applications face with OAuth tokens?
• What are the common implementation mistakes teams make when applying policy driven filters to nested relations in Prisma?
• What are the most common mistakes in access review policy design?
• What are common mistakes with ACL policy?