What Is Account Lockout?

Account lockout disables an account after repeated failed authentication attempts. It exists to stop brute-force guessing, and it introduces a denial-of-service capability: anyone who knows a username can lock that account out deliberately.

That trade-off is the whole design question, and aggressive lockout thresholds have caused more operational disruption than they have prevented compromise.

Password spraying defeats naive lockout

The attack that matters is not many attempts against one account. It is one or two attempts against thousands of accounts, using common passwords, paced slowly enough that no individual account reaches its threshold.

Per-account lockout does nothing against this. The signal is visible only in aggregate — a burst of single failures across many accounts from one source — and detecting that pattern is considerably more valuable than the lockout itself.

Better mechanisms than hard lockout

Progressive delay increases the wait between attempts, which makes guessing impractical without ever locking anyone out. Source-based throttling limits attempts from an address or network rather than against an account, so an attacker is slowed while legitimate users are unaffected.

Risk-based challenges step up verification when the attempt looks anomalous rather than blocking outright. And where lockout is used, short automatic unlock — minutes rather than until an administrator intervenes — preserves most of the benefit while removing the denial-of-service value.

Lockout as an incident signal

Beyond prevention, lockout events are useful telemetry. A single user locked out repeatedly is usually a stale credential on a device somewhere. A sudden rise across many accounts is an attack in progress.

Most organisations generate these events and never analyse them, which discards one of the clearest early indicators of credential attack available.

Customer-facing applications need different handling

For internal systems a locked account is an inconvenience and a support call. For a consumer-facing service it is a lost customer, and the volumes are different — credential stuffing against a public login can involve millions of attempts from thousands of addresses, which no per-account threshold meaningfully addresses.

The useful controls there are rate limiting by source and by behavioural pattern, challenges that escalate with suspicion rather than blocking outright, and checking submitted credentials against known breach corpora. The last is particularly effective because credential stuffing depends entirely on password reuse, and a reused password is the one property the attack cannot do without.

Self-service unlock is worth having regardless of the threshold chosen. It removes most of the support cost that makes administrators reluctant to enable lockout at all, and where it is protected by a second factor it does not weaken the control. The alternative — lockout requiring a help desk call — tends to produce pressure to disable the mechanism entirely.

Where to start

Check whether anyone reviews lockout and failed-authentication events in aggregate. If the answer is no, that data is already being collected and is currently telling you nothing.

See password policy. GuardsArm delivers managed security.