Event ID 4740 is logged in the Security log each time a user account is locked out. It appears on domain controllers, member servers, and workstations, and includes the account that was locked and the caller computer name. Use it to trace repeated failures, password spraying, or misconfigured systems. Enable Audit User Account Management.
How Event ID 4740 fits into Windows account lockout telemetry
Event ID 4740 is a detection point, not a root cause. It tells you a lockout occurred, but it does not explain whether the trigger was a genuine user mistake, a stale saved password, an application retry loop, or hostile password guessing. That distinction matters because the same event can represent a one-off support issue or the visible result of a broader authentication problem.
It is most useful when you correlate it with nearby logon failures, the affected account’s normal usage pattern, and the caller computer name. On a domain controller, that correlation can show which host is generating repeated bad attempts and whether the pattern is concentrated around one user or spread across many accounts.
For a broader Windows logging view, the Windows Event Log Guide is the right companion because it places 4740 alongside the other account, logon, and audit events that teams use to reconstruct the sequence around a lockout.
What usually causes 4740 to appear
The event is commonly generated by repeated failed sign-in attempts until the account policy threshold is reached. In practice, that can come from a human mistyping a password, a device or app still using an old password, a scheduled task, a mapped drive, a service, or a remote session that keeps retrying with stale credentials. Password spraying and other credential-guessing activity can produce the same symptom.
The caller computer name is the key operational clue. If the same workstation or server appears repeatedly, the lockout is often tied to a local process or cached credential on that system. If the source varies, you should think more about broad authentication abuse, shared credentials, or a service account that is used in multiple places.
When the surrounding question is whether a password pattern is malicious, the MITRE ATT&CK Enterprise Matrix helps frame repeated failures as potential credential access activity rather than treating every lockout as an isolated helpdesk issue.
How to use 4740 for investigation and reduction of noise
Start by identifying whether the lockout is isolated or recurring. A single event is often operational noise, but repeated events for the same account or from the same caller host deserve escalation because they can indicate a broken application, a persistent bad password stored on an endpoint, or active spraying against a privileged account.
Then check whether the impacted account is human, service, or administrative. Service and automation accounts often fail in bursts because some dependent system kept retrying after a password change. User accounts usually point to a device, browser, mobile mail client, VPN session, or remote-access tool that is still presenting old credentials. That is where the fastest remediation usually lies.
If you need stronger endpoint and log collection around the source host, the Sysmon Guide is useful because it strengthens host-level visibility beyond native account lockout events and helps you separate authentication noise from suspicious process or network activity.
Risk and Threat Considerations
Repeated lockouts are a visibility signal that something is repeatedly attempting authentication, but they do not tell you whether the cause is benign or adversarial. The risk is that teams dismiss the event as routine while a password spray, stale service credential, or compromised endpoint keeps generating lockouts across multiple accounts.
Failure mechanism: A single source, or a distributed set of sources, keeps submitting invalid credentials until the account policy threshold is reached. That mechanism can arise from misconfigured software, cached passwords, or deliberate guessing against users and privileged accounts.
Impact: Legitimate users can be locked out, helpdesk load can spike, and repeated failures can mask early signs of credential abuse, especially when the same source host or the same target account appears across multiple 4740 records.
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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1110 — Brute Force | Repeated lockouts often reflect repeated credential attempts against accounts. |
| Recommendation — Map repeated 4740 patterns to brute-force activity and hunt for companion failures. | ||
| CIS Controls v8 | CIS-5 — Account Management | 4740 is an account lifecycle and lockout event that depends on account governance. |
| Recommendation — Review lockout thresholds and account handling to reduce repeated lockout noise. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | 4740 depends on Windows audit generation for account management events. |
| IA-5 — Authenticator Management | Lockouts usually follow repeated failed authentications and stale credentials. | |
| Recommendation — Ensure account lockout events are generated and retained in audit logs. Rotate or reset stale authenticators that are driving repeated failed logons. | ||
Practitioner Guidance
What to verify: Confirm the caller computer name, the account type, and whether the lockout pattern matches a known device, app, or scheduled process. If one host or one account dominates the events, treat that as the most actionable lead before expanding the investigation.
Decision rule: If the account is privileged, shared, or tied to production automation, prioritize source-host review and credential hygiene over resetting the password first. If the pattern spans many accounts, treat it as potential spraying and look for correlated failed logons rather than isolated lockout tickets.
Practitioner takeaway: Event ID 4740 is most valuable when you use it to pivot from “an account locked out” to “which source, which account type, and which repeated authentication path caused it.”