Security Operations

Inside wesp.sys: Microsoft’s plan to move EDR out of the kernel

Elastic reverse-engineers wesp.sys, Microsoft’s driver for running EDR outside the Windows kernel. What UK SOC teams should plan for now.

Shield graphic with the headline Microsoft moves EDR out of the kernel

Elastic Security Labs has picked apart wesp.sys, the Microsoft driver meant to let endpoint detection and response (EDR) tools run without their own kernel code. The preview is early and still changing, but SOC teams should start planning for what it will change in their endpoint estate.

What happened

On 26 October 2026 Elastic Security Labs published an analysis by Pavel Yosifovich of the Windows Endpoint Security Platform (WESP). This is the framework Microsoft has been building since the July 2024 CrowdStrike outage, when a faulty content update to a third-party kernel driver crashed Windows machines around the world. The aim is simple to state and hard to deliver: one kernel driver, written and maintained by Microsoft, that passes security telemetry to vendors’ user-mode services so that EDR products no longer need drivers of their own.

Microsoft has not yet published documentation or a public SDK. However, two components now ship in Windows Insider Preview builds: the driver wesp.sys and a user-mode library, espclient.dll. Because both come with public debugging symbols, researchers can reverse-engineer how they work. Elastic is not alone. Jonathan Johnson published a first look in September based on build 29661, along with a proof-of-concept consumer that receives process-creation events. Researcher Marcos Oviedo has put a detailed reverse-engineering reference and test harness on GitHub covering Insider builds 10.0.29641 to 10.0.29667. Elastic says its own Elastic Defend product is preparing to support the platform.

This is the first sight of a plan Microsoft set out in June 2025 under its Windows Resiliency Initiative. At the time, Microsoft said a private preview would go to Microsoft Virus Initiative (MVI) partners so they could start building products that run in user mode like ordinary applications. Bitdefender, CrowdStrike, ESET, SentinelOne, Sophos, Trellix, Trend Micro and WithSecure all gave statements supporting the work.

The technical picture

All three analyses describe the same basic design. wesp.sys is a file system minifilter that depends on the Filter Manager and sits at altitude 329500, just above Microsoft Defender’s own WdFilter. It has no device objects, so a client cannot talk to it with the usual DeviceIoControl calls. Instead it opens a filter communication port, \EspFilterPort, which Johnson found accepts up to 512 connections. espclient.dll exposes a C-style API of functions prefixed “Esp”. With it, a vendor registers as a client, creates event queues and installs rules that decide which events reach those queues.

Rules matter because registry and file reads occur in huge volumes, and sending all of them to user mode would swamp any agent. WESP therefore filters at the source and forwards only what a client has asked for. Oviedo’s research goes further and describes rules being compiled in user space into binary decision graphs that the driver evaluates directly. It lists 47 event types across processes, objects, registry, file system and transactions, plus an early-boot component, wesp_elam.sys.

The open question is prevention. Today an EDR driver can veto an action inside the kernel callback, the classic example being refusing to let a malicious process start. Elastic noticed that espclient.dll does not import FilterReplyMessage, the call a user-mode service would normally use to send a verdict back to a minifilter. Yosifovich concludes that a user-mode client probably cannot yet run its own logic and then tell the driver to block an operation. Oviedo’s material points to a different model, in which blocking happens inside the kernel when a precompiled enforcing rule matches, with no round trip to user mode. Johnson notes that CrowdStrike has already shown prevention working in a demonstration. Put together, the evidence suggests vendors will be able to block operations, but only with logic they have expressed in advance as rules, not with whatever code they like.

Access control is also taking shape. Johnson found that the driver checks a token attribute, WESP://Permission, and that one permission level requires the caller to run as an Antimalware Protected Process Light (PPL). He also found an ETW provider, Microsoft.Windows.WESP.Client, that records client API activity. On a test-signing machine he could connect from an ordinary elevated process. That is helpful for researchers but not a production setting.

Flow diagram showing how Windows Endpoint Security Platform passes kernel events through rules and queues to a user-mode EDR agent

Why it matters for UK organisations

Many UK organisations felt the CrowdStrike incident directly, through a run of blue-screened desktops and servers and long, hands-on recoveries. WESP is Microsoft’s structural answer to that problem: if vendor code crashes in user mode, the service fails, not the whole machine. For anyone running critical services, or relying on a managed service provider (MSP) to look after endpoints, that is a real gain in resilience.

The trade-off is visibility and control. Your detection capability will increasingly depend on what Microsoft’s driver chooses to expose, how quickly gaps are filled and how each vendor builds its rule logic. Running two architectures side by side during migration adds its own complexity, with some agents on legacy drivers and some on WESP, across a fleet that is rarely on a single Windows build. Attackers will study the new interfaces too. A single, documented telemetry pipeline will attract a great deal of research into tampering, blinding and abusing rule logic.

Expert view

I am cautiously in favour. In my experience, the kernel drivers that ship with security products have been a source of instability and, on occasion, privilege escalation flaws. Moving most vendor code out of ring 0 shrinks a dangerous attack surface. Moving the kernel component under Microsoft’s maintenance also brings the testing discipline it applies to the rest of the operating system.

But a preview binary is not a finished product. The analyses already disagree on how blocking works, and Johnson is right that the technology may arrive faster than organisations upgrade their machines. When we test endpoint controls, the most valuable findings are usually the gaps between what the console claims and what the agent actually sees. WESP will create new gaps of that kind, and red teams will go looking for them.

What to do now

  1. Ask your EDR vendor for its WESP roadmap. Which event types will move first? Will prevention stay at the same level? How will it behave on hosts that have not upgraded?
  2. Map your Windows build estate. Know which devices will be able to run WESP-based agents and when, and treat old builds as a detection risk. This supports the security update management control in Cyber Essentials.
  3. Lab-test Insider builds now, away from production. Detection engineers should compare telemetry from WESP-based and legacy agents for the same simulated activity.
  4. Revisit tamper protection monitoring. Alert when security services stop, PPL status changes or agents unregister, and watch the new client ETW provider once it stabilises.
  5. Keep your recovery plan current. Fewer driver crashes do not remove the need for tested rollback, staged update rings and offline recovery media, all of which fit the malware protection and secure configuration controls.

Bottom line

WESP is the most significant change to how Windows hosts endpoint security for many years, and it is now visible in public builds. It should make bad updates far less disruptive, but it will reshape what your SOC can see and stop. Start the conversations with vendors and the lab work now, before migration decisions get made for you.

Sources

Related Posts