IAM-013 Logon Failure and Account Lockout
Description
Systems enforce limits on consecutive failed authentication attempts and respond with account lockout, CAPTCHA, or progressive delays to prevent brute force and credential stuffing. Failed logon attempts are logged. Account lockout mechanisms do not permanently deny access to legitimate users without a recovery process.
Rationale
Rate-limiting authentication attempts is a basic but effective defence against automated credential attacks. Without it, online brute force and credential stuffing are trivially executable.
Applicability (9 profiles)
Framework Mappings (6)
| IAM-13 | Strong Authentication | informative |
| IAM-13 | Strong Authentication | informative |
| HIPAA-164.308.a.5.ii.C | Log-in Monitoring | full |
| 8.5 | Secure authentication | partial |
| NIS2-CIR-11.6 | Authentication | informative |
| AC-7 | Unsuccessful Logon Attempts | full |
Evidence (2)
System configuration showing authentication lockout or rate-limiting settings: maximum failed attempt threshold, lockout duration or progressive delay, and CAPTCHA or equivalent mechanism.
Example: Okta sign-on policy export (GET /api/v1/policies?type=OKTA_SIGN_ON), Azure AD Smart Lockout configuration, or application-level rate-limiter configuration (e.g. fail2ban config, AWS WAF rate rule) showing: max_attempts, lockout_duration, and unlock_method.
Test: Query the IdP lockout policy settings and any application-layer rate-limiting rules. Verify: (1) maximum consecutive failed attempts before lockout is ≤ 10 (or as defined in policy), (2) lockout duration or progressive delay is specified and non-trivial (e.g. ≥5 minutes), (3) a recovery process (e.g. admin unlock or self-service with MFA) is defined so legitimate users can regain access, (4) the policy is in Enforced mode, not audit-only.
Authentication failure and lockout event logs confirming that lockout events are being generated and that the lockout threshold is triggering as configured.
Example: Okta System Log or Azure AD Sign-in Log export filtered for AUTHENTICATION_FAILURE and ACCOUNT_LOCKOUT events over the past 30 days, showing event type, target account, source IP, and timestamp.
Test: Query the authentication failure log for the past 30 days. Verify: (1) lockout events are present in the log (absence may indicate the feature is misconfigured), (2) for any IP generating ≥ the lockout threshold in failed attempts, a corresponding lockout event exists, (3) lockout events are triggering SIEM alerts or notifications to the security team. Request the alert configuration to confirm.
Questions (2)
Are authentication systems configured to lock out or rate-limit accounts after a defined number of consecutive failed login attempts?
The mechanism must be enforced at the system level. The lockout threshold, duration, and recovery process should be defined in policy and verifiable in system configuration.
What mechanism is used to respond to repeated failed authentication attempts?
At least one technical mechanism should be in place at the system or gateway level. Layering multiple mechanisms (e.g. lockout plus IP rate-limiting plus alerting) provides stronger defence against credential stuffing.