Event ID 4624 is logged when an account successfully logs on and a logon session is created on the destination computer. It requires Audit Logon subcategory and is useful for confirming interactive, network, or service access. Review LogonType, TargetUserName, IpAddress, and AuthenticationPackageName to understand who accessed what and from where.
What Event ID 4624 tells you about a successful logon
Event ID 4624 is the Windows audit record for a successful sign-in that created a logon session on the target machine. That makes it one of the core events for proving that access actually occurred, not just that a credential was presented. The useful context comes from the surrounding fields, especially the logon type, account name, source address, and authentication package.
Because 4624 records the destination computer’s view of the event, it is most helpful when you are reconstructing who accessed a host, whether the access was interactive or remote, and whether the account used matches the expected pattern for that system. A single 4624 does not by itself prove legitimate use, but it does establish that Windows accepted the authentication and opened a session.
The value of the event depends on what you see in the details. LogonType distinguishes console access, network access, remote interactive access, service use, and other logon categories, while TargetUserName, IpAddress, and AuthenticationPackageName help separate a normal user session from a service action, a remote admin connection, or an authentication method that deserves closer review.
Where 4624 fits in Windows auditing and logon analysis
To log 4624 reliably, Windows needs the Audit Logon subcategory enabled. Without that audit policy, successful logons may still happen, but you lose the structured evidence that security teams rely on for timeline reconstruction, alert triage, and host-level access review. In practice, 4624 is most valuable when paired with the failed-logon events, logoff events, and account-change events that show the full session lifecycle.
For defenders, the main question is not simply whether a logon happened, but whether the pattern makes sense for the asset and account. A service account logging on interactively, a local administrator logging in from an unusual workstation, or a network logon arriving from an unexpected source all become more meaningful when you compare 4624 with the system’s normal operating profile and with adjacent events in the same time window.
That is why 4624 is often a starting point rather than a conclusion. It can confirm access, but it usually needs correlation with process creation, privilege use, and subsequent authentication activity to show what the session did after it began. For broader Windows event context, the Windows Event Log Guide gives the surrounding event IDs and audit settings that make 4624 easier to interpret.
How to use 4624 for detection, investigation, and baselining
In daily monitoring, 4624 is most useful when you treat it as an access signal with context, not as a verdict. A successful logon can be routine, but it can also mark the first observable step in lateral movement, service abuse, or unauthorized access. That makes source, logon type, and account context more important than the raw event count.
When you are investigating suspicious activity, the most practical use of 4624 is to answer three questions quickly: did the account authenticate successfully, where did the session come from, and what kind of session was it? If the answer is inconsistent with the asset’s role or the account’s expected use, the event becomes a lead worth following, not just a line in a log. If you are building endpoint telemetry around that lead, the Sysmon Guide helps connect logon activity to process, network, and tamper signals on the same host.
For teams that rely on PowerShell for administration, 4624 can also help distinguish ordinary access from remote management paths that often accompany script-based activity. When a logon appears alongside administrative automation, the session context matters as much as the authentication itself, so the PowerShell Security Guide is a useful companion for understanding what a legitimate administrative logon should look like.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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-2 — Audit Events | 4624 depends on configured logon auditing to create usable access records. |
| AU-12 — Audit Generation | Event 4624 is generated by the system as part of audit logging for successful logons. | |
| IA-2 — Identification and Authentication (Organizational Users) | 4624 confirms successful user authentication on the destination system. | |
| Recommendation — Define logon events to be audited so successful access is recorded consistently. Ensure systems generate audit records for successful authentication events. Require authenticated user access before a session is established. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The event is only useful when audit logging is enabled and retained for review. |
| Recommendation — Collect and review successful logon events as part of audit log management. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | 4624 is a monitoring signal for who connected and from where on a host. |
| Recommendation — Monitor successful logons to spot unexpected access paths and source hosts. | ||
Practitioner Guidance
What to verify: Confirm that Audit Logon is enabled on the systems you care about and that 4624 events are arriving with the fields you need, especially LogonType, TargetUserName, IpAddress, and AuthenticationPackageName. If those fields are missing or inconsistent, the event still exists, but its investigative value drops sharply.
Decision rule: If the logon type and source match the account’s normal use, treat 4624 as routine evidence of access. If the session type, origin, or identity is unexpected, escalate to correlation with nearby logon failures, logoff events, privilege use, and process activity before deciding whether the activity is benign.
What practitioners underestimate: A successful logon is not the same as trusted activity. 4624 proves that authentication succeeded and a session started, but it does not show intent, command execution, or business legitimacy, so it should be used to anchor investigation, not to close it.
Practitioner takeaway: The best use of Event ID 4624 is to confirm access in context, then immediately compare that access against expected user behavior, host role, and surrounding telemetry.