BYOVD driver research from Atos says some Windows kernel drivers can be made reachable from user mode even when their intended hardware is absent, by manipulating Plug and Play initialization paths, software-emulated devices and driver binding state. That widens the triage burden for defenders who once treated hardware-gated bugs as lower risk.
The work, published on April 17, 2026 by Julian Horoszkiewicz, vulnerability researcher at Atos Threat Research Center, does not claim every missing device can be faked from user mode. Its sharper point is that driver exploitability often starts before the bug, at the moment Windows decides whether to create a device object, attach a stack and accept I/O from a handle.
The Hardware Gate That Stopped Looking Solid
Bring Your Own Vulnerable Driver (BYOVD, a post-exploitation technique that uses a legitimate but flawed kernel driver) has usually been discussed as a blocklist and endpoint detection problem. Atos pulls the lens back to a quieter dependency: reachability. A vulnerable instruction in a driver does not matter if user-mode code cannot make Windows enter the relevant path.
The Atos BYOVD hardware-gating research asks when that comfort fails. The paper separates drivers that create control device objects as soon as they load from Plug and Play (PnP, the Windows subsystem that discovers devices and builds driver stacks) drivers whose interesting code may sit behind callbacks and state created only after a device node appears.
- April 17, 2026 – Atos posted the public research and PDF.
- Windows 11 23H2 – Horoszkiewicz listed this as the test baseline.
- Almost twice – Atos said software-emulated device testing produced almost twice as many new device objects as a simple service-load approach.
That last number is not a global measurement of the Windows driver population. It is still a warning. If a lab method changes the number of reachable objects that much, then a vulnerability ticket that says hardware required may be missing half the story.
AddDevice Becomes the Pressure Point
The key Windows routine in the Atos paper is AddDevice. Microsoft describes an AddDevice routine for WDM drivers as the callback whose primary work is to create a device object and attach it to a device stack. That description sounds dry until it is mapped to exploitability. If AddDevice never runs, the target driver may never create the object that user-mode code can talk to.
At a low level, Windows drivers expose attackable surface through device objects. Microsoft says IoCreateDevice creates a driver device object, and Atos focuses on whether a driver creates that object at load time, during PnP initialization, or not at all without extra state. I/O request packet (IRP, the structure Windows uses to send operations to drivers) paths such as IRP_MJ_CREATE and IRP_MJ_DEVICE_CONTROL then decide whether a handle can be opened and useful requests can be sent.
This is where many executive summaries of BYOVD get thin. Endpoint detection and response (EDR, security software that monitors and blocks suspicious endpoint activity) products can be attacked only after the vulnerable driver reaches a useful state. A signed driver on disk, by itself, is not enough. A reachable device object with permissive access and dangerous behavior is the part that matters.
Four Reachability Paths In One Table
Atos tested several ways a driver can become more reachable than a first look suggests. The details belong in defensive labs and vendor triage queues, not production networks. The safe lesson is comparative: each path changes a different piece of Windows state, and each leaves a different detection trail.
| Path | Windows Piece Being Exercised | Why It Matters For Defenders |
|---|---|---|
| Plain service loading | DriverEntry and any unconditional device creation | Finds drivers that expose a control device object as soon as the kernel loads them. |
| Software-emulated device node | SetupAPI, PnP manager and the driver’s PnP callback path | Tests whether a matching device identity is enough to make the driver build a usable stack. |
| Software Device API creation | Software-only device enumeration and PnP state | Shows that hardware-like device nodes can exist without physical hardware attached. |
| Forced driver binding | Registry-backed device association and stack restart behavior | Challenges the assumption that the vendor INF file is the final gatekeeper for driver-to-device pairing. |
Microsoft’s Software Device API reference says SwDeviceCreate initiates enumeration of a software device, while UpdateDriverForPlugAndPlayDevicesW documentation says the function installs drivers for devices matching a hardware ID and an INF file. Atos ties those pieces to a security question: can the operating system be persuaded to initialize a driver enough for its vulnerable paths to appear?
The INF Lesson Makes Trust Messier
The most uncomfortable section of the Atos work is the one about Setup Information files (INF files, the driver package files that bind device identities to driver installation data). Security teams often treat the signed driver package as a neat boundary. Atos argues the boundary is administrative and packaging-related, not a complete security wall.
The paper’s forced-binding discussion says the registry structures that associate drivers with device nodes are what Windows ultimately uses after installation state exists. That matters because threat models often stop at file signature and known hardware ID. In a post-compromise setting, an attacker may already have enough local control to change system state in ways that do not look like a normal driver installer run.
There is also a safety caveat. Horoszkiewicz notes that forcing a mismatched driver onto a device can break the device or crash the system. That caveat does not make the technique irrelevant. It means defenders should treat failed device starts, odd driver bindings and sudden stack rebuilds as useful evidence, not just workstation noise.
Mind Cron has covered Microsoft’s newer push to reduce faulty Windows driver failures in its Windows 11 driver quality initiative report. The Atos research points at a related security problem: the same driver plumbing that must become more reliable also needs to become easier to audit after compromise.
Blocklists Help, But Reachability Moves Faster
Microsoft has not ignored vulnerable drivers. Its vulnerable driver blocklist guidance says the blocklist has been enabled by default for all devices since the Windows 11 2022 update, is updated quarterly and also receives updates through monthly Windows servicing. The same page recommends hypervisor-protected code integrity (HVCI, a virtualization-based protection for kernel code), Smart App Control, S mode or App Control for Business policies where appropriate.
That protection is necessary, but it is reactive by design. The Network and Distributed System Security (NDSS) Symposium paper Unveiling BYOVD Threats analyzed 8,779 malware samples loading 773 drivers and reported seven unknown vulnerable drivers through responsible disclosure. Its dataset tables also separated 162 known vulnerable driver groups from 611 potentially vulnerable groups, a useful reminder that the public lists trail the research frontier.
The defensive gap is timing. A blocklist can stop a known bad hash, and attack surface reduction rules can stop some attempts to write vulnerable signed drivers to disk. But Atos is asking a different question: for a driver not yet blocked, how many machine states make its dangerous path reachable?
Forensic Footprints Belong In Driver Triage
The best defensive use of the Atos paper is not to copy the lab procedure. It is to update triage. A driver flaw should now be scored against device creation, stack attachment, handle access and hardware probing, not merely against whether the intended laptop, audio chip or peripheral is present.
- Driver load events – Alert on unusual kernel service creation, rare driver names and new loads from user-writable staging paths.
- PnP churn – Track sudden creation of software device nodes, unknown devices and repeated device start failures.
- Stack shape changes – Compare class filters, function drivers and unexpected upper or lower filters against known-good baselines.
- Handle access – Watch processes that open device objects tied to security, disk, firmware, gaming peripheral or audio drivers outside normal vendor tools.
- Registry binding changes – Monitor driver-to-device association keys and class filter keys with the same care given to service persistence.
- Blocklist misses – Treat unsigned-looking package state, old vendor utilities and rare signed drivers as triage leads even when no public CVE appears.
One limit remains important. Atos says generic bypass of active hardware probing from user mode alone appears out of reach without adding kernel components or hypervisor access. That line keeps the research grounded. Some gates still hold. Others turn out to be initialization puzzles, and those puzzles are now part of the defender’s job.
If vendors add reachability testing to driver security reviews, hardware-gated bugs should shrink into a better-defined class of risk. If they do not, the next BYOVD case may start with a device that was never plugged in.
Frequently Asked Questions
What Is BYOVD In Windows Security?
BYOVD means Bring Your Own Vulnerable Driver. It describes attacks where an intruder with administrative execution loads a legitimate but flawed kernel driver, then uses that driver to reach privileged Windows functions.
Why Does Hardware Absence Matter For Driver Bugs?
Hardware absence matters because many drivers initialize their useful attack surface only when Windows believes a matching device exists. Atos shows that some of those initialization paths can still be reached without the intended physical hardware.
What Did Atos Add To BYOVD Research?
Atos focused on driver reachability, especially how Plug and Play callbacks, software-emulated device nodes and driver binding state can make code paths accessible that may look hardware-gated during a shallow review.
Does The Microsoft Vulnerable Driver Blocklist Stop This Risk?
The Microsoft vulnerable driver blocklist helps against known blocked drivers, but it cannot fully answer whether an unlisted signed driver can be made reachable in a new device state or stack configuration.
What Should Defenders Log First?
Defenders should prioritize kernel driver loads, software device creation, unexpected Plug and Play changes, class filter modifications, device-object handle opens and driver binding registry changes.
