Lockout blocks an account after a set number of failures, which stops guessing but lets attackers lock real users out. Throttling slows repeated attempts instead, which avoids that denial of service. Most teams combine a soft delay with a time-limited lockout, then watch for attacks spread across many accounts.
Definitions
- Account lockout: after a threshold of failed logins, the account refuses further attempts until it unlocks by time, email link or an administrator.
- Login throttling: each failure adds a delay, or limits attempts per account or source, without fully blocking the account.
- Credential stuffing and password spraying: attacks that try known leaked pairs, or one common password across many accounts, so that no single account racks up many failures.
What OWASP says about lockout
The Web Security Testing Guide describes lockout as a balance between protecting accounts and protecting users from being denied access. Accounts are typically locked after 3 to 5 failed attempts. It lists a range of 5 to 10 attempts as a typical threshold, and notes that too low a threshold locks valid users out too often, while too high lets attackers make more guesses first.
Unlock options, from lowest to highest assurance, are: time-based unlock, self-service unlock by email, manual administrator unlock, and manual unlock with positive identification. The guide warns that administrator-only unlock can become a denial of service if an attacker wants to lock every user.
It also describes a scaling approach used by one managed identity service, where the lockout time grows with the number of failures, so brute force is slowed without enabling long-term lockout of the real user.
Comparison
| Lockout | Throttling | |
|---|---|---|
| Stops simple guessing | Yes | Mostly, by making it slow |
| Risk to real users | Can be locked out on purpose | Low, delays only |
| Defeats spraying across accounts | No, each account sees few failures | No, unless keyed beyond the account |
| Needs an unlock process | Yes | No |
| Helps against stolen password lists | Little | Little |
Neither control handles credential stuffing well on its own, because each stolen pair is tried once. The WSTG says lockouts that count failures only per IP can be avoided by spreading requests across many addresses, and recommends account-based protections too.
A reasonable setup
- Add a short, growing delay after each failure for the account.
- Apply a time-limited lockout at a threshold in the 5 to 10 range.
- Add limits keyed by source and by account, not source alone.
- Offer multi-factor authentication, since stolen passwords alone then fall short.
- Check passwords against known-leaked lists and notify users of unusual sign-in events.
- Log failures and alert on patterns across accounts.
The Credential Stuffing Prevention Cheat Sheet lists these kinds of defense, including multi-factor authentication, CAPTCHA, IP mitigation, device fingerprinting and identifying leaked passwords. The testing guide warns that a CAPTCHA should not replace a lockout mechanism, since a poorly built one can be bypassed.
How to test it
Use an account you can afford to lock. Fail logins four times, succeed, fail five times, then try the right password and note whether it is refused and when it unlocks. Check that the unlock link is single use. Test every route that accepts passwords, including mobile and API endpoints, since a missed endpoint defeats the whole control. For more on telling the attack types apart, see credential stuffing vs brute force vs password spraying.
Quick check
Can lockout be used against my users?
Yes. An attacker who knows usernames can trigger lockouts on purpose. Time-limited unlocks and scaling delays reduce that harm.
Does a CAPTCHA replace lockout?
No. The OWASP testing guide says a CAPTCHA may hinder brute force but should not replace a lockout mechanism, since implementation flaws can let attackers bypass it.
Safeguard's free scan at gold.safeguard.sh/scan covers the dependencies behind your authentication code.
Sources
- OWASP WSTG: Weak Lock Out Mechanism
- OWASP Credential Stuffing Prevention Cheat Sheet
- CWE-307: Improper Restriction of Excessive Authentication Attempts
Last reviewed: 19 October 2026.
