Lock Accounts After Five Failed Logon Attempts
User accounts must lock after no more than five failed login attempts, with the lockout lasting indefinitely or until it clears automatically, except for emergency break glass accounts.
Plain language
When someone types the wrong password too many times, your systems should automatically lock that account so an attacker cannot keep guessing passwords until they get in. This control requires that lock to trigger after no more than five failed login (logon) attempts, and the account should then stay locked either permanently (until someone manually unlocks it) or for a set time before it automatically reopens. The only exception is "break glass" accounts, which are special emergency accounts used to regain access when normal logins fail.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
June 2026
Control Stack last updated
18 June 2026
E8 maturity levels
N/A
Official control statement
User accounts, except for break glass accounts, are protected by fixed or risk-based lockout mechanisms aligned to a maximum of five failed logon attempts, with either indefinite or automated lockout durations.
Why it matters
Without an account lockout limit, an attacker can keep guessing passwords over and over until one works, letting them break into accounts and access sensitive business systems and data.
Operational notes
Review lockout settings whenever new systems or cloud services are added, and recheck the break glass account exclusions periodically so emergency access stays available while ordinary accounts stay protected.
Implementation tips
- Your IT administrator should configure each system's account lockout policy so accounts lock after a maximum of five wrong password attempts, setting the threshold to five or fewer in the security settings of Windows Active Directory, Microsoft 365 (Entra ID), or other login systems.
- The IT administrator should choose, per system, whether locked accounts stay locked until a person manually unlocks them (indefinite) or reopen automatically after a set period (for example 30 minutes), and record which approach each system uses.
- Whoever manages identities should identify and clearly label the small number of break glass emergency accounts, then deliberately exclude only those accounts from the lockout rule so a genuine emergency login is never blocked.
- The IT administrator should consider a risk-based lockout tool that loosens or tightens the limit based on signals like an unfamiliar location or device, provided it still locks at or before five failed attempts for risky logins.
- The IT manager should keep a short written record showing the configured lockout threshold and duration for every system, and test it once by deliberately entering five wrong passwords on a test account to confirm the lock actually triggers.
Audit / evidence tips
- Askthe documented account lockout policy and a screenshot of the live setting from each main login systemGoodshows the failed-attempt threshold set to five or fewer, not left at a higher number or disabled
- Askhow long an account stays locked once triggeredGoodis clearly either indefinite (a person must unlock it) or a defined automatic duration, applied consistently and recorded, rather than left vague or unknown
- Askwhich accounts are break glass emergency accounts and how they are excluded from lockoutGoodnames a small, specific list and shows those are the only exceptions, with all ordinary user accounts still covered
- Look atevidence of a real test, such as a log entry or screenshot showing an account locked after five wrong passwordsGooddemonstrates the control actually works, not just that a setting exists on paper
- Askhow the lockout settings are kept consistent across all systems including cloud services and remote accessGoodshows central management or a regular review, not gaps where some systems have no limit
Cross-framework mappings
How ISM-1403 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(2)expand_less | ||
| Annex A 5.15 | ISM-1403 requires user accounts (except break glass accounts) to be locked after a maximum of five failed logon attempts, addressing spec... | |
| Annex A 8.3 | ISM-1403 mandates a specific response to failed login attempts by locking accounts after five failures, excluding break glass accounts | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System hardening
See all Guidelines for system hardening controls, or browse the full ASD ISM library.