ASD ISM 1403 Lock accounts after five failed logon attempts
What it says
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.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUser 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.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
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.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
the documented account lockout policy and a screenshot of the live setting from each main login system.
Good evidence
shows the failed-attempt threshold set to five or fewer, not left at a higher number or disabled.
- Check 2 of 5What an auditor asks for
Ask for
how long an account stays locked once triggered.
Good evidence
is clearly either indefinite (a person must unlock it) or a defined automatic duration, applied consistently and recorded, rather than left vague or unknown.
- Check 3 of 5What an auditor asks for
Ask for
which accounts are break glass emergency accounts and how they are excluded from lockout.
Good evidence
names a small, specific list and shows those are the only exceptions, with all ordinary user accounts still covered.
- Check 4 of 5What an auditor asks for
Look at
evidence of a real test, such as a log entry or screenshot showing an account locked after five wrong passwords.
Good evidence
demonstrates the control actually works, not just that a setting exists on paper.
- Check 5 of 5What an auditor asks for
Ask for
how the lockout settings are kept consistent across all systems including cloud services and remote access.
Good evidence
shows central management or a regular review, not gaps where some systems have no limit.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.5.15.
ISM-1403 requires user accounts (except break glass accounts) to be locked after a maximum of five failed logon attempts, addressing specific risks like brute-force attacks. Annex A 5.15 requires organisations to develop and apply access control policies and procedures, under which account lockout thresholds and exceptions are specified. ISM-1403 acts as a specific technical measure within this broader policy framework.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.