Windows 11 Now Has Built-In Sysmon: What Sysadmins Need to Know

If you have been managing Windows endpoints for any length of time, you already know Sysmon. Microsoft’s System Monitor has been the gold standard for endpoint telemetry since Mark Russinovich first released it as part of the Sysinternals suite. It gives you process creation logs, network connections, file changes, registry modifications, and DNS queries — the kind of visibility that turns a blind spot into a detection surface.

The problem has always been deployment. Sysmon was a standalone binary that you had to download, install, configure with an XML file, and keep updated separately from Windows itself. For a ten-machine lab, that is fine. For a thousand-endpoint estate, it is a packaging and patching headache that many teams simply never got around to solving properly.

That changes now. With the March 2026 cumulative update (KB5079473), Microsoft has made Sysmon a native optional feature in Windows 11. No more downloading binaries. No more separate update cycles. You enable it through Settings, push configuration via Group Policy, and it patches itself through Windows Update like everything else.

Here is everything you need to know to take advantage of it.

What Changed in KB5079473

The March 2026 cumulative update for Windows 11 (versions 24H2 and later) adds Sysmon to the Windows optional features catalogue. This is not a watered-down version or a rebranded tool — it is the same Sysmon engine, the same event schema, and the same XML configuration format that you already know. The difference is purely in how it gets onto the machine and how it stays updated.

Microsoft has integrated Sysmon into the servicing stack. That means:

• Installation: Enable it as a Windows feature rather than running an installer
• Updates: Sysmon binary updates arrive through the normal cumulative update channel
• Configuration: XML configs can be deployed via Group Policy or Intune configuration profiles
• Event channel: Logs write to Microsoft-Windows-Sysmon/Operational, exactly as before

The standalone Sysinternals version still works and will continue to receive updates. If you already have a working deployment pipeline for standalone Sysmon, nothing forces you to switch. But for new deployments or environments that never got around to rolling out Sysmon, this removes every excuse.

How to Enable Native Sysmon

There are three ways to enable the built-in Sysmon, depending on whether you are working on a single machine or deploying across an estate.

Method 1: Windows Settings

On an individual machine, open Settings > System > Optional features > Add an optional feature. Search for “System Monitor (Sysmon)” and click Install. The feature enables after a moment — no reboot required.

Method 2: DISM (Command Line)

For scripted deployments or imaging pipelines, use DISM:

Method 3: Group Policy / Intune

For enterprise-wide deployment, Microsoft has added a new Group Policy setting under Computer Configuration > Administrative Templates > Windows Components > System Monitor. Enable the “Deploy System Monitor” policy and optionally specify a configuration file path (UNC or local). When the policy applies, Sysmon activates on the next policy refresh.

For Intune-managed devices, create a configuration profile using the Settings Catalog. Search for “System Monitor” and enable the deployment setting. You can also push the XML configuration file as a Win32 app or use a remediation script.

Applying a Configuration

Enabling Sysmon without a configuration file gives you default logging — process creation, process termination, and driver loads. That is useful but limited. The real power comes from a tuned configuration that captures the events you care about whilst filtering out the noise.

The native version accepts the same XML configuration format as standalone Sysmon. If you already have a configuration file, you can apply it immediately:

If you do not have a configuration file yet, the community-maintained SwiftOnSecurity sysmon-config remains an excellent starting point. It provides sensible defaults with extensive filtering to reduce noise whilst capturing high-value security events.

For the Group Policy deployment method, specify the configuration path in the policy setting. The Sysmon service reads the configuration on startup and whenever the file is updated, so you can push configuration changes centrally without restarting the service.

Key Event Types You Should Be Capturing

Whether you are new to Sysmon or refreshing your configuration, these are the event types that deliver the most value for security monitoring. Each one maps to real-world attack techniques that your SIEM or log analysis tool can alert on.

Event ID 1 (Process Creation) is the single most valuable Sysmon event. It logs the full command line, parent process, file hashes, and user context for every new process. This is how you spot living-off-the-land attacks, suspicious PowerShell invocations, and malware execution chains.

Event ID 3 (Network Connection) captures outbound TCP and UDP connections with source and destination details. Essential for detecting command-and-control beacons, lateral movement, and data exfiltration. Filter aggressively here — a busy workstation generates thousands of connections per hour.

Event ID 11 (File Creation) logs new files being written to disc, including the creating process. This is your early warning for ransomware (mass file creation in rapid succession), dropper payloads landing on disc, and suspicious files appearing in temp directories.

Event ID 13 (Registry Modification) tracks changes to registry values, which is critical for detecting persistence mechanisms. Attackers love registry run keys, service entries, and COM object hijacking — all of which show up here.

Event ID 22 (DNS Query) logs every DNS lookup with the querying process. This is invaluable for identifying DNS tunnelling, domain generation algorithm (DGA) domains, and matching against threat intelligence feeds.

Event ID 25 (Process Tampering) detects advanced evasion techniques like process hollowing and herpaderping. These are the techniques that bypass traditional antivirus by replacing a legitimate process image with malicious code after the security check has passed.

Native vs Standalone: What Is Different

The honest answer is: not much, functionally. The native version runs the same engine, produces the same events, and accepts the same configuration. The differences are all operational:

Aspect	Standalone	Native (Built-In)
Installation	Download + run installer	Enable as optional feature
Updates	Manual / Sysinternals feed	Windows Update (cumulative)
Configuration	sysmon -c or script	GPO, Intune, or sysmon -c
Removal	sysmon -u	Remove optional feature
Side-by-side	Yes (different service name)	Default service name
Server support	Windows Server 2016+	Windows 11 24H2+ only (for now)

The most important limitation right now is that the native version is only available on Windows 11. Windows Server 2025 and Windows 10 are not included in this initial rollout. Microsoft has indicated that Server support is planned for a future update, but no specific timeline has been given. If you run a mixed estate, you will still need the standalone version for your servers and older clients.

Practical Deployment Tips

Having deployed Sysmon across environments of various sizes, here are the practical considerations that will save you time:

Start with a Proven Configuration

Do not try to write a Sysmon configuration from scratch. Start with SwiftOnSecurity’s config or Olaf Hartong’s modular config, then customise from there. These community configurations represent thousands of hours of tuning and will save you from the most common noise problems.

Plan Your Log Volume

Sysmon generates a substantial amount of telemetry. A typical workstation with a well-tuned configuration produces 5-15 MB of logs per day. Multiply that across your estate and make sure your SIEM or log collector can handle the volume. If you are forwarding to a cloud SIEM, check your ingestion costs before enabling Sysmon on every endpoint.

Test Before You Deploy Widely

Enable native Sysmon on a pilot group first. Monitor the log volume, check for application compatibility issues (rare but possible with aggressive filtering), and validate that your SIEM is correctly parsing the events. Once you are confident, roll it out via GPO to the wider estate.

Combine with Windows Event Forwarding

If you are not already using Windows Event Forwarding (WEF), now is the time. Create a subscription that collects Sysmon events from all endpoints and forwards them to a central collector. This gives you estate-wide visibility without needing an agent-based SIEM on every machine:

What This Means for Enterprise Security

Making Sysmon a native feature is a significant shift in Microsoft’s approach to endpoint visibility. For years, the security community has argued that Windows ships with insufficient built-in logging for threat detection. The default Windows event logs miss command-line arguments, lack network connection tracking, and provide no file integrity monitoring. Sysmon filled those gaps, but only for organisations that invested the effort to deploy it.

By making it a one-click optional feature with GPO support, Microsoft has dramatically lowered the barrier to entry. Smaller organisations that lack dedicated security teams can now enable enterprise-grade endpoint telemetry without buying third-party EDR tools or building custom deployment packages.

This does not replace a proper EDR solution. Sysmon generates telemetry — it does not respond to threats, quarantine files, or block malicious processes. But it gives you the raw data that makes threat hunting and incident response possible. If you are forwarding these events to a SIEM with decent detection rules, you have a genuinely capable monitoring stack at no additional cost.

Quick-Start Checklist

If you want to get native Sysmon running this week, here is the shortest path:

1. Confirm your machines are on Windows 11 24H2 with KB5079473 (or later) installed
2. Enable the Sysmon optional feature via DISM or Group Policy
3. Download SwiftOnSecurity’s sysmon-config and customise the exclusions for your environment
4. Apply the configuration using sysmon -c or via Group Policy
5. Verify events are appearing in Event Viewer under Microsoft-Windows-Sysmon/Operational
6. Set up Windows Event Forwarding or configure your SIEM agent to collect Sysmon events
7. Build detection rules for your highest-priority event types (start with Event IDs 1, 3, and 22)

Native Sysmon is one of those changes that sounds small but has an outsized impact. The technology was already proven — what was missing was a frictionless deployment path. Now that the friction is gone, there is genuinely no reason not to have Sysmon running on every Windows 11 machine in your estate.