Event ID 4740 records a user account lockout in the Security log on domain controllers, member servers and workstations. It usually indicates repeated failed logons, but it can also reveal password spray activity or a misconfigured service. Review Subject Security ID, Account That Was Locked Out Security ID and Caller Computer Name to find the source.
Why Event ID 4740 is a useful security signal
Event ID 4740 matters because lockouts are often the visible end of an authentication problem, not the problem itself. A single lockout can be benign, but repeated lockouts across multiple hosts or accounts can point to a password spray campaign, a stale application credential, or a service that is authenticating with outdated secrets. Security teams use it as an early indicator that an identity path needs investigation, not just a help desk reset.
The event is especially useful because it narrows the search to the account that locked, the source system that triggered the lockout, and the time window in which the failure pattern formed. That makes it more actionable than a generic failed-logon spike. Used well, it helps you separate user error, service disruption and active abuse before the noise spreads across the environment.
For teams that already monitor Windows authentication logs, Event ID 4740 is a bridge between detection and triage. It tells you where to pivot next, and it often confirms that the real issue is elsewhere in the authentication chain, such as a mapped drive, scheduled task, legacy service, mobile device sync job or scripted logon using stored credentials. The practical value is less about the lockout itself and more about the clue it provides to the failing or abused actor behind it.
What security teams should look at first
The first step is to treat the lockout as a correlation problem. Review the Subject Security ID to confirm which security principal was affected, then use the Account That Was Locked Out Security ID and Caller Computer Name to identify the likely source system. If the caller is unexpected, repeated, or tied to infrastructure that should not be authenticating as that account, you may be looking at misuse rather than a simple password mistake.
Pattern matters more than the isolated event. A single lockout during a password change may be low concern, but a burst of lockouts against many accounts, or repeated lockouts for one privileged account, should be treated as a stronger indicator of malicious or operationally risky activity. Check whether the same source host appears across multiple users, whether the failures align with a known service window, and whether the account should ever be used interactively.
When 4740 appears with repeated failures from one source, confirm whether the source is a workstation, a server, or a service host. That distinction changes the response. A workstation may point to a user issue or endpoint compromise, while a server may indicate a scheduled task, batch job, app pool identity or service account problem. The Windows Event Log Guide is a useful companion when you need to pair 4740 with the surrounding logon and account events that explain the sequence.
How to separate abuse from misconfiguration
Event ID 4740 is not proof of an attack by itself. Many lockouts come from ordinary operational failures, especially when a password changes and a service, scheduled task or cached credential is not updated everywhere it is stored. The challenge is deciding whether the environment is suffering a hygiene problem or absorbing active credential abuse. That judgment depends on repetition, source consistency, account sensitivity and whether the failures map to known assets or unknown hosts.
Password spray activity becomes more plausible when the lockouts are distributed across multiple accounts, especially with similar timing and from the same source or network segment. A misconfigured service is more likely when one account is locked repeatedly from a single host and the failures continue on a schedule. If the account is privileged or exempt from normal interactive use, treat the event as higher risk because a noisy service loop can mask an actual compromise or create an easy denial of service condition.
Security teams should also check whether adjacent telemetry shows the same source host generating other suspicious authentication events, process activity, or remote access attempts. Event ID 4740 can be the first stable signal in a wider authentication incident, but it can also be the first clue that a benign-looking service account is brittle enough to cause repeated outages. The SIEM Guide is relevant here because the value comes from correlating lockouts with other authentication and host signals, not from alerting on 4740 in isolation.
Risk and Threat Considerations
Lockouts can create both security exposure and operational disruption. A high rate of 4740 events may indicate that an attacker is testing passwords at scale, but it can also reveal accounts whose credentials are widely reused, cached or embedded in services. Either way, the lockout is often a symptom of weak credential hygiene or repeated authentication abuse, and the same pattern can hide a more serious compromise if teams treat it as a routine help desk issue.
Failure mechanism: Repeated authentication attempts against a valid account trigger lockout thresholds, either because an attacker is spraying passwords or because a service or user is repeatedly presenting stale credentials. If the source host and account relationship is not investigated quickly, the same pattern can continue long enough to disrupt access or obscure the original source of the failures.
Impact: Users lose access, services may fail, and security teams can miss early indicators of credential abuse. In the worst case, the lockout is a byproduct of broader identity compromise, where the offending source host or service account is already part of an active attack path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | 4740 needs log review and correlation across auth events. |
| IA-5 — Authenticator Management | Lockouts often expose stale or misused credentials that need lifecycle control. | |
| Recommendation — Correlate 4740 with adjacent authentication logs to identify the source and pattern. Review and rotate credentials that are causing repeated lockouts. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lockouts are an account lifecycle and authentication control concern. |
| Recommendation — Monitor account lockouts and investigate repeated authentication failures quickly. | ||
| MITRE ATT&CK | T1110 — Brute Force | Repeated lockouts can indicate password spraying or brute-force attempts. |
| Recommendation — Hunt for password-spraying patterns when lockouts cluster across accounts. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Event ID 4740 is a monitoring signal that supports anomaly detection. |
| Recommendation — Baseline lockout activity and alert on unusual spikes or sources. | ||
Practitioner Guidance
What to verify: Confirm whether the lockout is isolated or part of a burst, then verify the source host, the affected account type and whether any service, task or application is still using the old credential. If the account is privileged or shared, treat the event as more than a usability issue.
Decision rule: If one source host repeatedly locks the same account, prioritise credential hygiene and source investigation before assuming user error. If many accounts are affected, shift to spray or brute-force analysis and check for other failed-authentication indicators in the same time window.
Practitioner takeaway: Event ID 4740 is valuable because it turns an authentication symptom into a pivot point, and the fastest teams use it to decide whether they are dealing with stale secrets, a misbehaving service, or the first visible sign of credential abuse.