Home / Knowledge hub / Account lockout
Knowledge hub
Account lockout
Blocking an account after repeated failed sign-ins, and the denial it can cause.
What it means
Account lockout is a control that stops sign-in to an account after a set number of wrong passwords. The lock may last a few minutes, until an administrator steps in, or until the owner proves who they are through another route such as email.
It exists to slow guessing. Without any limit, an attacker can try passwords at machine speed against a single account, and a short or common one will fall within minutes. The idea is simple, and the details of how it is applied decide whether it helps or hurts.
Why it matters
A limit on failed attempts is expected by NIST and by most audit frameworks, so it will come up in security questionnaires. It is a basic defence against brute force attempts on a single account. Security questionnaires and audits tend to ask what yours does.
It has a cost. An attacker who knows a username can lock that person out on purpose by failing repeatedly, which is a denial of service on one account. It also fails against password spraying, which spreads a few guesses across many accounts and never trips the limit on any.
How it shows up
You meet it on sign-in forms, API token endpoints and administrator panels. Check what is counted: per account, per address, or both. Check the lock is released safely and that an unlock email or reset link is not itself open to account enumeration or abuse.
Many teams prefer escalating delays, challenges and rate limiting per address and per account, with an alert on unusual patterns. Whatever you pick, apply it to every route that checks a password, including mobile, legacy and API paths, because attackers will find the one without it.
Questions people ask
Account lockout, answered
How many failed attempts should trigger a lockout?
There is no single right number. NIST requires a limit on consecutive failures and leaves the figure to you. Choose one that stops guessing without making accidental lockouts routine.
Can attackers abuse lockout?
Yes. Failing on purpose against a known username locks the real owner out. That is why many teams use delays or challenges rather than hard locks, and keep a quick way for owners to recover.
Is lockout the same as rate limiting?
No. Lockout reacts to failures on one account. Rate limiting caps how many requests a source can send. The two work best together. The first is a response to failures on one account, the second a cap on volume from a source, and good designs combine them.
Does lockout stop credential stuffing?
Only partly. Credential stuffing tries one password per account from a leaked list, so each account sees too few failures to lock. Spreading guesses over many accounts also slips under per-account limits, so watch for patterns across accounts too.
How do we test it?
Attempt repeated failures on a test account through each sign-in route, the web form, the API and the mobile path. Check the lock appears everywhere and that the unlock route cannot be abused.
Related
Terms that sit next to this one
Brute force
Trying passwords or codes over and over until one of them works.
Password spraying
Trying a few common passwords across many accounts to stay under lockout limits.
Rate limiting
Capping how often something can be attempted, per user or per address.
Credential stuffing
Trying passwords leaked elsewhere, because people reuse them.
Denial of service
Making an application unavailable by overwhelming or exhausting it.
Which sign-in route has no limit?
Guessing limits are tested on every sign-in route of the running app, and each finding carries the request and response that proved the gap. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.