The Windows Event Log Primer

The Windows event log in 2026 amounts to the single most underused source of security data in the typical enterprise. The enterprise buys the SIEM, the enterprise points the SIEM at the network, the enterprise misses the threats that the…

A single worn cloth-bound ledger open on a wooden desk, showing a page of hand-written log entries arranged in three columns of monospace-style pencil, a small mechanical pencil on the page, cool blue and warm tungsten light.

The Windows event log in 2026 amounts to the single most underused source of security data in the typical enterprise. The enterprise buys the SIEM, the enterprise points the SIEM at the network, the enterprise misses the threats that the Windows event log would have caught. The Windows event log primer for 2026: what the events are, what they mean, what the enterprise should be collecting, what the enterprise should be alerting on.

The typical enterprise in 2026 has 100,000+ Windows endpoints generating 50-200 events per second per endpoint, with the events streaming to a SIEM, with the SIEM collecting maybe 10-20% of the events, with the enterprise alerting on maybe 1-5% of the collected events. The ratio of generated to alerted runs at 1000:1, with the difference sitting in the gap between what the Windows event log can tell you and what the typical enterprise has wired up to listen. The 2026 state of Windows event log collection amounts to a state where the data exists and the listening does not.

The event categories that matter

Three categories, in roughly that order of how much security value they deliver. The first runs as authentication events, with the Security log containing the 4624 (logon success), 4625 (logon failure), 4648 (logon with explicit credentials), 4672 (admin logon), 4720 (user account created), 4726 (user account deleted), 4732 (member added to group), 4756 (member added to universal group). The authentication events tell you who logged in, from where, with what credentials, and what they did after. The second runs as process creation events, with the Sysmon log containing Event ID 1 (process create), which records every executable that ran, with the parent process, with the command line, with the hash. The process creation events tell you what ran on the endpoint, who launched it, and what command was used. The third runs as network connection events, with the Sysmon log containing Event ID 3 (network connect), which records every TCP connection the endpoint made, with the destination IP, with the destination port, with the process that made the connection. The network connection events tell you which endpoint talked to which external host, with what process, on what port. The three categories together cover 80% of the security value in the Windows event log.

What the typical enterprise gets wrong

Three things, in roughly that order of how often they come up. The first runs as the volume problem, where the enterprise cannot afford to collect all the events at the volume they get generated, the enterprise samples 10% of the events, the 90% that gets dropped contains the events the enterprise needed. The second runs as the retention problem, where the enterprise collects the events for 30 days, the enterprise gets breached, the breach happened 90 days ago, the 60 days of events that would have told the story are gone. The third runs as the parsing problem, where the enterprise collects the events, the enterprise does not parse the events, the events sit in the SIEM as raw data, the enterprise cannot query the data, the enterprise cannot alert on the data. The three things together make the Windows event log effectively useless to the typical enterprise, even when the enterprise has the data.

How to actually do it

Three moves if you are setting up Windows event log collection. Collect everything, because the cost of collecting the events has dropped enough that the cost argument no longer holds, and the value of having the events when you need them counts as the the value of having the data when the breach happens. Retain for at least 180 days, because the dwell time for the modern attacker runs at 60-100 days, and the 30 day retention guarantees that you will not have the events when you need them. Parse and enrich at ingest, because the raw event runs as not useful to the alert, the parsed and enriched event. the the unit the analyst queries. The parsed event with the username, the hostname, the parent process, the destination IP is what the event the analyst can build a query on. The raw event without the parsing , the the event the analyst cannot use. The enterprise that collects everything, retains 180 days, and parses at ingest stands as the enterprise that gets the value from the Windows event log.

Abstract event log streams as glowing cyan lines flowing on a dark navy surface, dramatic chiaroscuro lighting from above.
Windows event log in 2026: 3 event categories, 3 mistakes the typical enterprise makes, 3 moves to actually do it. The data exists, the listening does not.

The bottom line

The Windows event log in 2026 amounts to the single most underused source of security data in the typical enterprise. The three categories (authentication, process creation, network connection) cover 80% of the security value. The three mistakes (volume sampling, short retention, no parsing) make the data useless. The enterprise that collects everything, retains 180 days, and parses at ingest stands as the enterprise that gets the value from the Windows event log.

Sources & Further Reading

All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.

Spotted an error? Email the editor. Corrections are issued with a visible correction note.

Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.

Continue reading