Event ID 4740 is a Windows Security audit event that records when a user account is locked out. It is written on domain controllers, member servers and workstations. Use the caller computer name and account fields to trace password spray, brute force or misconfigured authentication sources.
What Event ID 4740 Tells You
Event ID 4740 is a Windows Security audit event that marks an account lockout. In practice, it is one of the clearest signals that authentication is failing repeatedly enough to trigger policy, either because of attack activity or a legitimate source using stale credentials.
Because the event is written on domain controllers, member servers and workstations, its value comes from correlation. The locked account alone rarely explains the incident; the caller computer name, target account, and surrounding logon failures show where the bad authentication originated and whether the pattern is isolated or widespread.
Why Account Lockouts Matter
Account lockouts are not just nuisance alerts. They can indicate password spray, brute force, credential stuffing, or automation that is repeatedly retrying a saved secret after the password changed. Even when the cause is benign, repeated lockouts can disrupt users and mask a real attack path.
The practical security issue is that lockout events often appear after the attacker has already discovered a valid username. That makes Event ID 4740 useful as an early warning for identity abuse, but only if teams treat it as a lead rather than a conclusion.
How to Read the Event Context
The most useful fields are the caller computer name, the locked-out account, and the timing relationship to other authentication failures. A single caller repeatedly locking multiple accounts can suggest spray activity, while one account locking from many callers can point to a user with stale credentials on multiple devices or services.
Use 4740 alongside nearby Windows events that show failed logons, interactive sign-ins, and service activity. The event by itself says a lockout occurred; the surrounding evidence explains whether the source was a person, a workstation, a scheduled task, a mapped drive, a service, or an external attempt.
What Good Investigation Looks Like
A strong investigation starts by identifying whether the lockout is a one-off or part of a cluster. Security teams should check whether the same caller, subnet, or authentication method appears across multiple lockouts, then compare that pattern with recent password resets, device changes, and privileged account activity.
The Windows Event Log Guide helps place Event ID 4740 in the wider audit trail, including adjacent logon and account-management events that often explain the lockout path. Windows Event Log Guide is useful when you need to move from a single audit record to a broader authentication timeline.
Risk and Threat Considerations
Repeated lockouts can be a sign of active password-guessing, but they can also be a resilience problem when legitimate systems keep retrying outdated credentials. In both cases, the operational risk is the same: authentication noise obscures the real source of failure and can delay response to an ongoing access attempt.
Failure mechanism: Attackers or broken services generate repeated authentication failures until the account policy locks the user out, which can hide spray activity or create avoidable service disruption.
Impact: Users lose access, incident responders lose signal quality, and the organisation may miss the difference between malicious probing and a misconfigured authentication source.
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 |
|---|---|---|
| MITRE ATT&CK | T1110 — Brute Force | Event 4740 often exposes repeated password guessing against Windows accounts. |
| Recommendation — Map repeated lockouts to brute-force activity and hunt for clustered authentication failures. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | The event is valuable because audit review and correlation turn it into actionable detection. |
| IA-5 — Authenticator Management | Account lockouts are tightly tied to password and authenticator lifecycle issues. | |
| Recommendation — Review lockout events with surrounding logs to identify the source and scope of authentication failure. Strengthen authenticator lifecycle controls to reduce lockouts from stale or compromised credentials. | ||
| CIS Controls v8 | CIS-5 — Account Management | Lockouts are a direct account-management signal and useful indicator of account misuse. |
| Recommendation — Use account-management controls to detect and respond to abnormal lockout patterns. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | 4740 supports continuous monitoring of authentication-related security events. |
| Recommendation — Include account lockout events in monitoring to surface suspicious authentication activity early. | ||
Practitioner Guidance
What to watch for: Treat recurring 4740 events as a correlation problem, not a standalone alert. The caller computer name, target account, and timing pattern should determine whether you are dealing with a sprayed credential set, a stale password on a service, or a device that needs remediation.
Practitioner note: If the same source keeps triggering lockouts, the most effective fix is usually on the source system or account usage pattern, not on the lockout event itself. The event tells you where to look next, but not which control failed first.