Audit Windows kernel driver access

Kernel access lets software interact directly with an operating system's core. It can enable low-level security and hardware functions, but a faulty driver can compromise or crash the whole machine.

The CrowdStrike outage showed that risk at global scale. This guide explains how to spot installed kernel components and decide whether their function justifies the access.

Hidden in plain sight

The following is a list of applications that may require kernel access.

Install kernel drivers only when their function justifies the added risk.

Application	Purpose	Examples
Anti-Cheat Software	Monitors game processes, memory, and hardware to detect low-level cheating	Vanguard, EasyAntiCheat, BattlEye
Security Software	Protects against malware by monitoring system calls and intercepting malicious activities	Antivirus, EDR solutions
Virtualization Software	Manages virtual machines with direct hardware access for near-native performance	VMware, VirtualBox, Hyper-V
Performance Monitoring Tools	Monitors CPU frequencies, temperatures, voltages; enables hardware overclocking	MSI Afterburner, HWiNFO
Remote Access Software	Mostly user-mode today; some install optional display/virtual-device drivers	Some remote-control tools
Backup and Recovery Software	Creates disk images, backs up locked files, performs bare-metal recovery	Acronis, Macrium Reflect
Disk Management Tools	Manipulates partition tables, file systems, and disk structures at low level	EaseUS, MiniTool Partition Wizard
VPN Clients	Install virtual network adapter drivers (TUN/TAP, WireGuard) for tunneling	Most VPN clients
Development and Debugging Tools	Inspects kernel memory, sets hardware breakpoints, analyzes system crashes	WinDbg, Sysinternals tools

Identifying kernel components

One correction to the folk wisdom first: UAC prompts, administrator rights, and restart requirements are not proof of kernel access. Plenty of ordinary software elevates or asks for a reboot without ever touching the kernel. The reliable signal is a driver being installed, a signed kernel-mode driver package (.sys), which is what the items in the table above load.

Signals worth reading, roughly in order of strength:

• Driver installation: a kernel-mode driver package, usually containing a .sys file, is the strongest signal
• Digital signatures: modern 64-bit Windows generally requires signed kernel drivers; a signature identifies a publisher and integrity chain, not software quality
• Installation warnings: antivirus software may flag kernel-mode components during installation
• UAC elevation and restart requirements: weak signals on their own and common to ordinary installers, but frequent elevation plus a driver install plus a mandatory reboot usually means a kernel component

To inspect the kernel drivers installed on a Windows machine:

• driverquery /v in a terminal lists every installed driver and its state
• msinfo32 → Software Environment → System Drivers gives the same view with a UI
• Sysinternals Autoruns (Drivers tab) shows third-party drivers that load at boot, with signature status
• pnputil /enum-drivers lists third-party driver packages in the driver store

Risk reduction

When kernel access is unavoidable, implement these protective measures:

• Application Sandboxing: Use Windows Sandbox or virtual machines for untrusted software (note: sandboxes help you evaluate software; a kernel driver ultimately runs on the host you install it on)
• Recovery plan: Know how to enter Windows Recovery Environment and remove or roll back a driver; a restore point can help but is not a substitute for a backup
• Regular Backups: Maintain current system and data backups
• Staged Deployment: Test kernel-level software on non-critical systems first

User-mode alternatives

Consider these alternatives before granting kernel access:

• Application-Level Monitoring: Many monitoring tasks can be performed without kernel access
• Windows Performance Counters: Access system metrics through standard APIs
• User-Mode Network Filters: Use the Windows Filtering Platform (WFP) APIs for network monitoring (the older WinSock LSP mechanism is deprecated and should not be used)
• Managed security services: Prefer products that document which controls run locally and which kernel components, if any, they install
• Hardware Abstraction Layers: Use manufacturer-provided APIs instead of direct hardware access

Warning signs

Be alert to these red flags when evaluating software requesting kernel access:

• Unsigned Drivers: Lack of valid digital signatures from trusted publishers
• Unknown Publishers: Software from unestablished or suspicious developers
• Excessive Permissions: Requests for more access than functionally necessary
• Poor Documentation: Vague explanations for why kernel access is required
• Bundled Software: Kernel components included with unrelated applications
• Emergency Updates: Rushed patches that bypass normal testing procedures

A short decision checklist

Before letting anything install a kernel driver, answer five questions:

1. Does the job require the kernel? Check the User-Mode Alternatives above; if the vendor can't say why user mode is insufficient, stop.
2. Who signed the driver? A valid signature helps establish provenance. It does not prove that the driver is safe or well tested.
3. What's the blast radius? A kernel bug can take down the machine (see the CrowdStrike incident). Is this machine one you can afford to lose to a bad update?
4. Can you stage it? Try it on a non-critical machine first, with a restore point and current backups.
5. Can you audit it later? Note what got installed, and re-run driverquery or Autoruns afterward so you can find and remove it.

If an answer fails, the honest options are: run it in a VM, find a user-mode alternative, or go without.

(This essay is a layperson's overview, not a specialist security review; weigh it accordingly.)