Why Sign-In Audit Policy Floods the Security Event Log on Windows 11

You open Event Viewer on Windows 11 and find the Security log filled with thousands of sign-in events every hour. This flood makes it nearly impossible to find a specific login failure or suspicious entry. The cause is an overly broad sign-in audit policy that logs every authentication attempt, including background service logins and network connections. This article explains which audit subcategories trigger the flood, how to identify the noisy events, and how to narrow the audit scope without losing security visibility.

Why the Security Log Fills Up So Quickly

The Security log on Windows 11 records audited security events. When you enable sign-in audit policies through Group Policy or Local Security Policy, Windows writes an event for every authentication attempt that matches the policy. The default policy in many enterprise environments, Audit Logon for both success and failure, captures every single logon attempt regardless of the logon type.

Windows 11 defines several logon types. The most common are interactive logon type 2, network logon type 3, batch logon type 4, service logon type 5, and remote interactive logon type 10. Type 5 events occur every time a Windows service starts under a domain account or a local service account. On a typical business PC with 30 to 50 services, each service restart generates a separate Event ID 4624. A single day can produce thousands of these events.

Network logon type 3 events come from file shares, printer connections, and mapped drives. If a user has multiple mapped drives that reconnect at login, each drive triggers a separate logon event. Combined with service logons, these two types account for 80 to 90 percent of all Security log entries on a busy workstation.

How Audit Policy Settings Work

Windows 11 uses two audit policy categories: basic security settings under Security Settings > Local Policies > Audit Policy, and advanced audit policy under Security Settings > Advanced Audit Policy Configuration. The basic policy is simpler but less precise. The advanced policy offers subcategories such as Audit Logon, Audit Account Logon, and Audit Other Logon/Logoff Events. Each subcategory can be set to log success only, failure only, both, or none.

The default advanced policy for Audit Logon logs both success and failure for all logon types. This setting creates the flood. To reduce the volume, you must either disable logging for specific logon types or switch to logging only failures.

Steps to Reduce the Sign-In Audit Flood

You have two methods to reduce the event volume. The first method changes the audit policy to log only failures. The second method keeps success logging but uses an Event Viewer filter to hide noisy logon types. Each method has trade-offs.

Method 1: Change the Audit Policy to Log Only Failures

1. Open Local Security Policy
   Press Win + R, type secpol.msc, and press Enter. If User Account Control prompts you, select Yes.
2. Navigate to the advanced audit policy
   In the left pane, expand Security Settings, expand Advanced Audit Policy Configuration, and select System Audit Policies – Local Group Policy Object.
3. Open the Logon/Logoff category
   Double-click Audit Logon in the right pane. This opens the Audit Logon properties dialog.
4. Set the policy to log failures only
   Uncheck the Configure the following audit events box if it is checked. Under Audit Logon Events, check the Failure box and uncheck the Success box. Click OK.
5. Apply the change
   Close the Local Security Policy window. The change takes effect immediately. New sign-in events will only appear in the Security log when a logon attempt fails.

This method stops all successful logon events. You will no longer see Event ID 4624 for interactive, network, or service logons. You will still see Event ID 4625 for failed logon attempts. This is the most effective way to stop the flood, but it also removes visibility into successful logins from unknown users or unexpected times.

Method 2: Filter the Security Log Without Changing the Policy

If you need to keep success logging for security reasons, you can create a custom filter in Event Viewer that excludes noisy logon types. The filter does not reduce the number of events written to the log, but it helps you focus on relevant events.

1. Open Event Viewer
   Press Win + R, type eventvwr.msc, and press Enter.
2. Select the Security log
   In the left pane, expand Windows Logs and click Security.
3. Create a custom filter
   In the right pane, click Filter Current Log. In the Filter tab, switch to the XML tab and check Edit query manually. Click Yes to confirm.
4. Paste the XML filter
   Replace the existing XML with the following code, which excludes logon type 5 service logons and logon type 3 network logons:
   <QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">[System[(EventID=4624 or EventID=4625)]] and [EventData[Data[@Name='LogonType'] != '5' and Data[@Name='LogonType'] != '3']]</Select>
</Query>
</QueryList>
5. Apply the filter
   Click OK. Event Viewer now shows only sign-in events with logon types other than 3 and 5. You can adjust the filter to include other logon types by adding or removing conditions.

This method keeps the original audit policy intact. All events are still written to the log, so the log file size may still grow quickly. To prevent the log from filling the disk, increase the maximum log size in Event Viewer. Right-click Security under Windows Logs, select Properties, and set the maximum log size to a larger value, such as 20 MB to 100 MB depending on your disk space.

Common Issues After Changing the Audit Policy

Security Compliance Requirements Still Demand Success Logging

Some organizations require success logging for all sign-in events to meet compliance standards such as PCI DSS or HIPAA. If you cannot disable success logging, use the Event Viewer filter method instead. You can also create a scheduled task that exports filtered events to a separate log file for analysis while keeping the full log for compliance.

Event Log Reaches Maximum Size and Stops Recording

When the Security log reaches its maximum size, Windows stops writing new events. The default maximum size is 20 MB. On a system with heavy sign-in auditing, this fills up in hours. Increase the log size to a value that matches your retention policy, such as 100 MB or 200 MB. Also configure the log to overwrite events as needed rather than archiving, unless your compliance policy requires archiving.

Third-Party Security Tools Rely on Success Events

Security information and event management SIEM tools often ingest Event ID 4624 to build user activity baselines. If you disable success logging, the SIEM may stop detecting anomalous logon patterns. In this case, use the Event Viewer filter method to reduce noise in your local view, but keep sending all events to the SIEM. Configure the SIEM to filter out logon types 3 and 5 on the server side.

Audit Policy Comparison: Basic vs Advanced vs Disabled

Item	Basic Audit Policy	Advanced Audit Policy	No Audit Policy
Configuration location	Security Settings > Local Policies > Audit Policy	Security Settings > Advanced Audit Policy Configuration	Not configured
Granularity	Logon events only	Logon, Account Logon, and Other Logon/Logoff subcategories	None
Default event volume per day	500 to 2,000 events	1,000 to 5,000 events	0 events
Ability to filter by logon type	No	No (policy applies to all logon types)	N/A
Compliance support	Partial	Full	None

The advanced audit policy offers more subcategories but still cannot selectively exclude logon types 3 and 5. To achieve selective logging, you must use a third-party tool or a PowerShell script that listens for events and writes only the desired ones to a custom log. The basic policy is simpler but logs the same volume of events as the advanced policy when set to log all logon events.

You can now identify which audit subcategory causes the flood and choose the right method to reduce it. If you need to keep success logging, apply the Event Viewer XML filter to hide service and network logon events. If you can disable success logging, change the advanced audit policy to log failures only. For environments that require full logging, increase the Security log maximum size to 100 MB or more and schedule regular log exports.

A concrete advanced tip: use PowerShell to create a scheduled task that runs every hour and exports only Event ID 4624 with logon type 2 interactive events to a separate evtx file. This keeps the main Security log small while preserving interactive logon records for forensic analysis. Run wevtutil epl Security C:\Logs\InteractiveLogons.evtx /q:"[System[(EventID=4624)]] and [EventData[Data[@Name='LogonType']='2']]" in the task action to achieve this.