Event ID 4740 records a user account lockout. Attackers can trigger repeated failures to cause denial of service, or the event may indicate password guessing, password spraying or credential drift. Check the locked account, caller computer name and subject account to distinguish a malicious attempt from a legitimate user error or misconfigured service.
What Event ID 4740 tells you about attack activity
Event ID 4740 is useful because it sits at the boundary between authentication noise and a real abuse pattern. A single lockout can be ordinary user error, but repeated lockouts across accounts often point to password guessing, spraying, or an automated process that is repeatedly presenting the wrong secret. The event becomes actionable when you correlate it with timing, source host, and whether the account is human or service-related.
To interpret the event, focus on whether the lockout is isolated or systemic. One user locking out once may be a typing mistake, but many accounts locking out from the same host or in a regular burst is a stronger sign of abuse or misconfiguration. The caller computer name, locked account, and subject account are the fastest clues for separating a real attack path from a broken service, stale saved credential, or user behaviour that keeps replaying an expired password.
Event 4740 also matters because it can expose how the environment handles failed authentication. If the account is locked after a small number of attempts, the attacker may be using the lockout itself as a denial-of-service tactic. If the account is a service principal or shared admin account, the event can indicate that a non-human credential is drifting across systems, which is often more disruptive than the lockout itself because the same bad secret may be reused elsewhere.
Which attack patterns most often sit behind repeated lockouts?
Password guessing and password spraying are the two most common attack patterns associated with this event. Guessing usually creates concentrated failures against one account, while spraying spreads low-and-slow attempts across many accounts to avoid detection and lockout thresholds. Both can generate Event ID 4740, but spraying is more likely to look like scattered lockouts across multiple users or systems rather than one obvious brute-force burst.
Credential drift is the less obvious but very common non-malicious explanation. That happens when a password changes but one or more scheduled tasks, services, mapped drives, saved sessions, scripts, or remote tools still use the old value. In that case, the lockout pattern is often tied to a single source host and repeats on a predictable interval, which is why the caller computer name is so important. Windows Event Log Guide is useful here because it places 4740 in the wider context of Windows audit data and the event IDs that commonly help you correlate logon failures, account changes, and related activity.
Repeated lockouts can also be the visible symptom of credential abuse elsewhere. A stolen password may be valid on one system and invalid on another because of a recent reset, or because the attacker is trying the same secret across multiple accounts and services. When that happens, Event 4740 is not the compromise itself, but a strong indicator that authentication data is being probed or reused in ways the environment should investigate.
How to separate hostile activity from ordinary account problems
The first question is whether the source is consistent with the account’s normal use. If the locked account is a user mailbox, workstation login, or VPN account, investigate recent password changes, MFA prompts, and user-reported access problems. If the account is a service account, scheduled task identity, or integration credential, focus on password rotation, application dependencies, and whether a system or job still holds an old secret.
The second question is whether the lockout pattern matches a single host, a set of hosts, or a broad campaign. One source repeatedly causing lockouts suggests a stored credential problem or an abusive process on that system. Many sources causing lockouts across many users raises suspicion of spraying, scripted testing, or credential stuffing behaviour. If you also see authentication failures before the lockout, that supports an active attack path rather than a one-off user mistake.
The third question is whether there is evidence of broader abuse around the same account. If the same identity has successful sign-ins from unusual locations, privilege changes, or access to unusual resources, treat the event as more than a nuisance lockout. If it is tied to a service or automation path, review whether that non-human identity has broader access than it should. The State of NHI & AI Agent Breach Report 2026 is relevant because it highlights how stolen or misused credentials and service accounts often become the practical entry point for real incidents.
Risk and Threat Considerations
Event ID 4740 is often treated as a nuisance alert, but it can mark either an active attack or a failure mode that attackers can exploit. The security risk is not just that an account is unavailable, it is that the lockout threshold itself can be turned into disruption, while the underlying failed logons may still be collecting intelligence about valid accounts and password hygiene.
Failure mechanism: Repeated authentication failures from a user, host, or automated process trigger lockout, which can be caused by password guessing, spraying, or stale credentials left in services and scheduled tasks. In a real attack, the same pattern can also reveal which accounts are worth targeting next.
Impact: Users can lose access, service workflows can fail, and defenders may miss a larger intrusion attempt if they treat every lockout as routine noise. At scale, recurring Event 4740s can become both an operational outage signal and a warning that authentication controls, credential hygiene, or alert triage need improvement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1110 — Brute Force | Covers password guessing and spraying patterns that commonly drive lockouts. |
| Recommendation — Map repeated lockouts to brute-force activity and hunt for distributed authentication failures. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Event 4740 needs correlated log review to distinguish attack from misconfiguration. |
| IA-5 — Authenticator Management | Lockouts often expose weak credential lifecycle or stale secret use. | |
| Recommendation — Review correlated authentication logs to separate malicious patterns from benign lockout causes. Rotate or replace the credential path that is repeatedly causing lockouts. | ||
| CIS Controls v8 | 5 — Account Management | Account lockouts are an account management and authentication governance issue. |
| Recommendation — Inventory accounts and service identities that repeatedly lock out and correct the underlying access path. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Credential drift and repeated lockouts often stem from stale secrets in services or automation. |
| Recommendation — Reduce long-lived credentials that keep reusing an expired or changed secret. | ||
Practitioner Guidance
What to verify: Check the locked account type, the caller computer name, and the timing of the lockout against recent password changes, service restarts, scheduled jobs, and helpdesk tickets. A lockout tied to one host usually points to a stale credential or misbehaving process, while lockouts across many accounts deserve closer threat investigation.
Decision rule: If the same source repeatedly drives lockouts, treat it as a credential hygiene or automation problem first, but if the pattern spans multiple users or looks deliberately distributed, escalate it as possible spraying or guessing activity. For service identities, verify the dependent application before resetting the password blindly, because the same fix can break production if the hidden dependency is not found.
What good looks like: You can explain why the lockout happened, identify whether it was human, service, or attack driven, and show that the account was restored without leaving the same bad credential path in place. A mature response leaves behind a clear trail of source host, affected identity, and remediation, not just a cleared lockout.
Practitioner takeaway: Event 4740 is most useful when you treat it as a correlation point, not a conclusion, because the real question is whether the lockout reflects malicious probing, reused credentials, or a broken authentication dependency that will fire again.