Account Lockout and Brute-Force Protection Guide: Stopping Password Attacks

Account lockout stops online password guessing, but set badly it either lets attackers keep trying or hands them a way to lock every user out. Getting it right means choosing between hard lockout, throttling and adaptive rate limiting, aligning thresholds across layers such as Active Directory, Entra ID and AD FS, and protecting the less obvious targets: OTP codes, PINs, local administrator accounts and exposed RDP. This guide gives concrete settings, event IDs, a rollout plan and metrics for identity, infrastructure and application security teams. Distributed attacks that try one password across many accounts, and replay of breached credentials, are covered in the Password Spraying and Credential Stuffing Defence Guide; automated traffic filtering in the Bot Management Guide. This page focuses on per-account and per-authenticator limits.

Key takeaways

• Count failures per account, not per IP address. OWASP notes that tying the counter to the source address lets attackers avoid lockout by rotating addresses.
• NIST sets a ceiling, not a target. SP 800-63B-4 (final, July 2025) requires disabling an authenticator after no more than 100 consecutive failed attempts and lets organisations set lower limits; NCSC suggests 5 to 10 attempts where lockout is used.
• Throttling beats hard lockout for availability. Progressive delays and smart lockout that separates familiar and unfamiliar locations limit guessing without letting an attacker lock out real users.
• Align the layers. In hybrid estates the cloud or federation lockout must trip before on-premises AD lockout, or internet-facing attacks will lock domain accounts.
• Lockout is not the main defence. MFA, password deny lists and monitoring do more; lockout slows guessing and generates the signal that something is wrong.

What brute-force protection has to cover

MITRE ATT&CK groups these attacks under Brute Force (T1110). Only some of them are stopped by per-account limits, which is why lockout has to sit alongside other controls.

Microsoft's own guidance makes the same point about offline attacks: the Windows lockout threshold does not counter them. See the Password Policy Guide for hashing and deny lists.

Lockout, throttling or adaptive rate limiting

OWASP describes three settings that must be balanced: the lockout threshold (failures that trigger it), the observation window (period in which they count) and the lockout duration. The design question is what happens when the threshold is reached.

What the standards say

• NIST SP 800-63B-4, Section 3.2.2: the verifier limits consecutive failed attempts on a single account to no more than 100, then disables the authenticator, which must be rebound before reuse. Organisations may impose lower limits. Permitted techniques include a bot detection and mitigation challenge, increasing waits (30 seconds up to an hour) and risk-based or adaptive techniques. After a successful login, prior failures should be disregarded. If the subscriber cannot authenticate, the account recovery procedures in Section 4.2 apply.
• NCSC password guidance: throttling with progressively increasing delays is preferred; if lockout is used, allow 5 to 10 attempts to avoid accidental lockout, and pair it with monitoring.
• OWASP Authentication Cheat Sheet: count per account, consider exponential lockout, let the forgotten-password flow unlock the account, return the same generic message for wrong password, unknown user and locked account, and avoid timing or HTTP status differences that reveal whether an account exists.
• OWASP ASVS 5.0: V6.1.1 requires documenting how rate limiting, anti-automation and adaptive response defend against credential stuffing and brute force; V6.3.1 requires implementing them; V6.3.5 requires notifying users of suspicious authentication attempts.

Decision guidance

• Customer-facing applications: prefer throttling and risk-based challenges over hard lockout. Large public user bases make lockout-based denial of service easy and expensive to recover from.
• Workforce directories: timed lockout of around 10 attempts is the common baseline (Microsoft's Windows security baselines and KB5020282 both use 10), combined with smart lockout at the internet edge.
• High-assurance government tenants: stricter defaults exist; Entra ID in Azure US Government locks after 3 failures.
• Small organisations: use the platform defaults (Entra smart lockout is always on) and spend effort on MFA rather than custom tuning.
• Large hybrid estates: tune each layer deliberately and test the order in which they trip.

Platform settings reference

Aligning hybrid layers

• Entra pass-through authentication: Microsoft advises an Entra threshold lower than the AD DS threshold (AD at least two to three times higher) and an Entra duration longer than the AD duration. Microsoft's example is Entra 10 attempts and 120 seconds against AD 20 attempts and 60 seconds.
• AD FS: set ExtranetLockoutThreshold to roughly half of the AD threshold, for example 10 against 20. AD lockout still applies independently, even in AD FS log-only mode.
• Same-password retries: Entra smart lockout tracks the last three bad password hashes, so repeating the same wrong password does not count again. This does not apply with pass-through authentication, because the check happens on premises.
• Kerberos retries: Microsoft warns that Kerberos encryption-type negotiation and applications that retry silently can count towards the threshold. Test before lowering it.

See the Entra ID Security Guide for the wider tenant baseline.

OTP, PIN and MFA code brute force

Short numeric codes are only as strong as the limit on guessing them. RFC 4226 (HOTP) shows the adversary's chance of success grows with the number of verification attempts allowed and the size of the look-ahead window, and shrinks with the number of digits. That is why every code verifier needs its own limit.

• Set a throttling parameter: RFC 4226 Section 7.3 recommends a maximum number of attempts, or a delay scheme, applied across login sessions so attackers cannot reset it by reconnecting. Section 7.2 says the server should lock the account and inform the user when the limit is reached.
• Do not reset the counter by issuing a new code: NIST SP 800-63B-4 states that generating a new out-of-band secret shall not reset the failed attempt count.
• Rate-limit out-of-band codes and push: ASVS 5.0 V6.6.3 requires rate limiting for code-based out-of-band authentication, and V6.6.4 requires rate limiting of push notifications to prevent push bombing, with number matching as a further mitigation. See the MFA Fatigue and Bypass Guide.
• Biometric and device PINs: NIST allows five consecutive biometric failures (ten with presentation attack detection) before a delay of at least 30 seconds, with an overall limit of 50 (100 with PAD).
• Recovery and reset codes: password reset tokens and email verification codes are authenticators too; apply the same per-account limits and short expiry.

Exposed services: RDP and remote access

Internet-facing RDP (ATT&CK Remote Desktop Protocol, T1021.001) is a common brute-force target, and the built-in local Administrator historically sat outside lockout so administrators could always recover. KB5020282 changed that from the October 2022 cumulative updates.

• Enable "Allow Administrator account lockout" on existing devices through GPO or Intune; only new builds receive it by default.
• Do not expose RDP directly: put it behind a gateway with MFA or a VPN. See the Remote Desktop (RDP) Security Guide.
• Use unique local admin passwords (Windows LAPS) so a guessed password does not unlock every machine.
• Watch logon type 10 (RemoteInteractive) and type 3 (Network) failures in event 4625 for these hosts.

Lockout as denial of service, recovery and emergency access

Microsoft's Windows guidance is blunt: because lockouts can be triggered remotely, an attacker who knows account names could lock every account in the domain without any credentials. Plan for that before it happens.

• Self-service unlock: in Entra ID, self-service password reset with "I forgot my password" resets the lockout duration to zero; OWASP also recommends letting the forgotten-password flow regain access.
• Mass lockout runbook: a non-zero threshold requires a process to unlock accounts quickly at scale; script it in advance and test it.
• Emergency access accounts: exclude break-glass accounts from routine policies only with compensating controls (strong credentials, monitoring of every use), and make sure an attacker cannot lock them out of the only recovery path. See the Break-Glass Account Guide.
• Service accounts: a lockout of a service account takes down the application that uses it, so an attacker may target them deliberately. Microsoft recommends monitoring all 4625 events for service accounts. Prefer gMSA or managed identities that do not accept interactive password logons. See the Service Account Security Guide.
• Non-human API credentials: rate-limit API key and client secret authentication per credential as well; an API that accepts unlimited key guesses is a brute-force target with no user to notice.

Implementing lockout and rate limiting

1. Inventory every authentication path: web login, API, legacy protocols, VPN, RDP, OTP and reset flows. Lockout that applies to the web form but not to an API or legacy endpoint is bypassed.
2. Collect a baseline: measure current failure rates, lockouts per day and help desk unlock tickets for at least two weeks.
3. Choose values per layer: edge smart lockout first, directory lockout higher, per-authenticator limits on codes. Document them as ASVS V6.1.1 requires.
4. Run in audit mode: AD FS log-only mode for 3 to 7 days (at least 24 hours if under active attack), or log-only rules in the application, and compare would-be lockouts with real failures.
5. Pilot: apply to IT staff and a pilot ring before all users; confirm self-service unlock works and help desk volume stays acceptable.
6. Enforce and monitor the metrics below daily for the first month.
7. Roll back by restoring the previous GPO or tenant values, or switching AD FS back to log-only. Windows lockout changes take effect without a restart.

Detection and measurement

• Alert on lockouts of privileged and service accounts, every time, as Microsoft's 4740 and 4625 guidance recommends.
• Alert on a locked account used from an unexpected Caller Computer Name or from outside the domain.
• Correlate across accounts: many accounts each with a few failures from one source is spraying, which per-account lockout will not catch. See the ITDR Guide.

Metrics

• Lockouts per 1,000 users per day, split by familiar and unfamiliar source.
• Share of lockouts resolved through self-service rather than the help desk.
• Median time to unlock a legitimate user.
• Number of authentication paths without enforced rate limits (target: zero).
• Successful logins following a run of failures on the same account (possible guessed password).
• Lockouts of service and break-glass accounts (target: zero, each investigated).

Framework mapping

Common failure patterns

• Threshold 0 left in place: the Windows default domain policy never locks accounts; Microsoft only accepts this with strong passwords and robust alerting.
• Counting per IP: attackers rotate addresses and never trip the limit; a related mistake is trusting a client-supplied X-Forwarded-For value, which ASVS V15.3.4 warns about.
• Layers in the wrong order: AD locks before the cloud or AD FS layer, so internet attackers can lock domain users.
• Unprotected side doors: legacy protocols, APIs, OTP and reset endpoints without limits.
• Revealing account state: a "this account is locked" message or a faster response for unknown users gives attackers a free enumeration oracle.
• No mass-unlock plan: a lockout storm turns into a multi-hour outage while the help desk unlocks accounts one by one.

Lessons from incidents

In the 23andMe credential stuffing breach 2023, attackers used breached credentials against the login page for about five months, including over one million attempts in a single day that caused an outage, and reached more than 18,000 accounts. Per-account lockout would not have stopped one-attempt-per-account stuffing, but cross-account rate limiting and detection of the burst would have raised the alarm, and mandatory MFA would have made the correct passwords insufficient. The UK ICO fined the company £2.31 million in June 2025.

Practitioner checklist

• List every authentication path and confirm each has a per-account or per-credential limit.
• Set Windows lockout threshold, duration and reset values (10 / 10 / 10 is a documented starting point) and enable Allow Administrator account lockout.
• Confirm Entra smart lockout trips before AD lockout, and AD FS ESL is enforced after a log-only period.
• Limit OTP, PIN, push and reset-code attempts, and never reset the counter when a new code is issued.
• Return generic errors with consistent timing for all login failures.
• Provide self-service unlock and a tested mass-unlock runbook.
• Protect service and break-glass accounts from deliberate lockout.
• Alert on lockouts of privileged and service accounts and on cross-account failure patterns.
• Enforce MFA and password deny lists; treat lockout as a backstop.

Standards and references

• NIST: SP 800-63B-4 Authentication and Authenticator Management
• NIST: SP 800-53 Rev. 5 (AC-7 Unsuccessful Logon Attempts)
• OWASP: Authentication Cheat Sheet
• OWASP: Application Security Verification Standard 5.0
• NCSC: Password policy, updating your approach
• Microsoft Learn: Protect user accounts from attacks with Microsoft Entra smart lockout
• Microsoft Learn: AD FS Extranet Lockout and Extranet Smart Lockout
• MITRE ATT&CK: Brute Force

Related NHI Mgmt Group resources: Password Spraying and Credential Stuffing Defence Guide · Bot Management Guide · Hardware Security Keys Guide · NIST SP 800-63 Digital Identity Guidelines Guide