Skip to main content
Commerce Security Authority
Category: Access Control

Account Lockout

Also known as: Account Lock, Login Lockout
Simply put

Account lockout is a security feature that blocks access to a user account after too many failed login attempts or other trigger conditions. It is intended to make it harder for an attacker to keep guessing passwords, though it may also temporarily lock out legitimate users. The lock may be temporary, lifting after a set time, or may require an administrator to restore access.

Formal definition

Account lockout is a control state that suspends further authentication attempts against an account after repeated failures or other defined trigger conditions, disabling the account either temporarily or until manual intervention. Implementations typically define a failed-attempt threshold, a lockout duration, and an observation or reset window; in directory environments such as Active Directory, lockout events are recorded (for example, Event ID 4740) and can be diagnosed with tools such as Microsoft's LockoutStatus.exe or third-party utilities to identify the source host generating the failed attempts. The control is intended to mitigate password-guessing and brute-force attacks, but carries trade-offs: aggressive thresholds can produce lockouts of legitimate users (a false-positive effect) and can be abused for denial-of-service against accounts. Configuration and enforcement details are governed by the relevant platform or applicable authentication policy; where lockout is applied to meet a compliance obligation, confirm specific parameters against the current published standard rather than assuming fixed values.

Why it matters

Account lockout is one of the oldest and most widely deployed defenses against password-guessing and brute-force attacks. By suspending authentication after a defined number of failed attempts, it raises the cost and slows the pace of an attacker attempting to try many passwords against a single account. Where lockout is applied to satisfy a compliance obligation, the specific threshold, duration, and reset window should be confirmed against the current published standard rather than assumed, since parameters and wording differ between versions.

The control involves genuine trade-offs that security and operations teams must balance. Aggressive thresholds can lock out legitimate users who mistype passwords or use stale cached credentials, producing a false-positive effect that generates help-desk load and user friction. The same mechanism can also be abused: an attacker who knows a valid username can deliberately trigger repeated failures to force a denial-of-service against that account. Because of this, lockout policy should be tuned to the environment and paired with other controls rather than relied on in isolation.

Account lockout does not by itself eliminate the risk of credential compromise. It helps reduce online guessing but does not address offline attacks against stolen password hashes, credentials already exposed in breaches, or authentication bypass through other vectors. It is best understood as one layer that may mitigate specific attack patterns, most effective when combined with strong password practices, monitoring, and additional authentication factors.

Who it's relevant to

Identity and Directory Administrators
Teams managing Active Directory and other directory services configure lockout thresholds, durations, and reset windows, and respond when accounts lock. They rely on event logging (such as Event ID 4740) and diagnostic tools like LockoutStatus.exe or third-party examiners to trace repeated failures back to a source host, which is often a stale credential or misconfigured service rather than an attacker.
Security Engineers and Analysts
Security teams treat lockout as one layer of defense against password-guessing and brute-force attacks. They tune thresholds to balance protection against the false-positive risk of locking out legitimate users and the potential for deliberate account denial-of-service, and they combine lockout with monitoring and additional authentication controls rather than relying on it alone.
Compliance and Audit Teams
Where account lockout is enforced to meet a compliance obligation, these teams verify that configured parameters align with the applicable authentication policy. Because requirement numbering and wording differ between standard versions, specific values should be confirmed against the current published standard rather than assumed.
Help Desk and IT Operations
Support staff handle the operational impact of lockouts, including user unlock requests and troubleshooting recurring locks caused by cached or expired credentials. They benefit from source-identification tooling to resolve the underlying cause instead of repeatedly restoring access.

Inside Account Lockout

Lockout Threshold
The number of consecutive failed authentication attempts permitted before an account is locked. PCI DSS addresses account lockout controls, though the specific threshold values and wording differ between standard versions; confirm the current requirement against the published standard rather than assuming a fixed number.
Lockout Duration
The period for which access is suspended once the threshold is reached, or the condition requiring administrator intervention to restore access. Duration values are version-specific within PCI DSS and should be verified against the current published requirement.
Reset and Unlock Mechanism
The process by which a locked account is restored, whether automatically after a defined interval or manually via a verified administrative or self-service workflow that itself must resist abuse.
Counter and State Tracking
The backend logic that records failed attempts, associates them with an account or identifier, and evaluates them against the threshold. Its placement (per-account, per-source, or both) affects susceptibility to distributed guessing versus targeted denial of service.
Scope of Application
The systems and access points where lockout applies, such as administrative and remote access to in-scope system components. Account lockout is one authentication control among several and is distinct from the transaction-level authentication addressed by EMV, 3-D Secure, or strong customer authentication.
Logging and Monitoring Integration
Records of lockout events feed detection and alerting processes, helping identify possible credential-guessing or account takeover attempts. The signal has known limitations and can produce both false positives and false negatives depending on tuning.

Common questions

Answers to the questions practitioners most commonly ask about Account Lockout.

Does account lockout prevent account takeover?
No. Account lockout is intended to slow or disrupt automated credential-guessing attacks such as brute-force and password-spraying attempts, but it does not prevent account takeover on its own. Attackers who obtain valid credentials through phishing, malware, credential stuffing with correct passwords, or data leaks may authenticate successfully without ever triggering a lockout threshold. Account lockout is one layer that may reduce certain attack paths and should be combined with other controls such as multi-factor authentication, monitoring for anomalous logins, and detection of credential-stuffing patterns. Treat it as a mitigating control rather than a guarantee against takeover.
Is account lockout the same as a PCI DSS requirement I can point to by number?
Account lockout is a concept associated with authentication controls, and PCI DSS has historically addressed limiting repeated access attempts and locking accounts. However, requirement numbering, thresholds, and wording differ between PCI DSS versions, so you should confirm the specific control text and parameters against the current published standard rather than assuming a fixed requirement number or value. The term itself is a general access-control mechanism, not a standard; how it must be configured to satisfy a given assessment depends on the version in effect and the validated implementation.
How should we choose a lockout threshold and duration?
Threshold and duration should balance security against usability and availability. A low threshold with a long lockout can frustrate legitimate users and increase help-desk load, while a high threshold may give attackers more guessing attempts. Consult the parameters defined in the version of the standard you are validating against and confirm them there, then tune within any allowed range based on your user population, support model, and observed false-positive rates. Consider whether the account unlocks automatically after a set period or requires administrative or identity-verified reset, as each option has different operational and security trade-offs.
Should lockout be applied per account, per source IP, or both?
Per-account lockout helps slow guessing against a single identity but can be abused to cause denial of service by intentionally locking out legitimate users. Source-based rate limiting can slow distributed guessing but is less reliable when attackers rotate IP addresses or use large proxy pools. Many implementations combine account-level lockout with additional throttling, progressive delays, and anomaly detection to address the limitations of any single approach. Each method carries false-positive and false-negative trade-offs, so document what your chosen combination is intended to mitigate and what remains out of scope.
How can we reduce the denial-of-service risk that lockout can introduce?
Because an attacker can deliberately trigger lockouts to deny service to legitimate users, consider controls that raise the cost of guessing without hard-locking accounts, such as progressive delays, CAPTCHA or similar challenges, and risk-based step-up authentication. Where hard lockout is used, provide a secure, identity-verified unlock or reset path so legitimate users can recover access, and monitor for spikes in lockout events that may indicate abuse. These measures aim to preserve availability while still slowing automated attacks, but each adds its own usability and false-positive considerations.
What should be logged when lockouts occur, and how should they be monitored?
Failed authentication attempts and lockout events should be logged in a way that supports detection and investigation, including relevant details available to your system such as the affected account, timestamp, and source information, while avoiding logging of credentials or sensitive authentication data. Monitoring these logs helps identify brute-force, password-spraying, and possible abuse of the lockout mechanism itself. Alert thresholds should be tuned to reduce noise, recognizing that some legitimate lockouts will occur, and log retention and review should align with the requirements of the standard you are validating against, confirmed in its current published text.

Common misconceptions

Account lockout prevents account takeover.
Account lockout is intended to help reduce the success of automated or repeated credential-guessing attempts against a login. It does not prevent account takeover that relies on stolen valid credentials, phishing, session hijacking, or social engineering, and it should be combined with controls such as multi-factor authentication as part of a layered approach.
Account lockout is a fraud control that stops fraudulent transactions.
Account lockout governs authentication to system components and is separate from transaction-level fraud controls. Card-not-present fraud, chargeback fraud, and synthetic identity fraud are addressed by different mechanisms, and liability and dispute outcomes are governed by card brand and network rules that vary by region and change over time.
The PCI DSS lockout threshold and duration are fixed values that never change.
The specific threshold, duration, and requirement wording differ between PCI DSS versions, and requirement numbering also changes across versions. Practitioners should confirm the exact values against the current published standard rather than relying on a remembered figure.

Best practices

Confirm the applicable lockout threshold, duration, and reset requirements against the current published version of PCI DSS rather than assuming a fixed value or requirement number.
Apply account lockout as part of a layered authentication strategy alongside multi-factor authentication, so that a single control is not relied upon to stop credential-based attacks.
Design the failed-attempt counter to balance protection against credential guessing with resistance to abuse that could lock out legitimate users as a denial-of-service tactic.
Integrate lockout events into logging, monitoring, and alerting so that repeated lockouts can be reviewed as potential indicators of credential-guessing or account takeover attempts, while tuning to manage false positives and false negatives.
Ensure that reset and unlock workflows are themselves verified and resistant to social engineering, since a weak recovery path can undermine the lockout control.
Scope lockout controls to the intended access points, such as administrative and remote access to in-scope system components, and document where the control does and does not apply.