Signed vs. unsigned drivers: WHQL, EV, Test Mode

Whenever Windows installs a driver, the question of digital signature comes up — visible or not. Modern Windows (10/11 64-bit) refuses to load unsigned drivers by default. We explain why this is good, what WHQL means, and when you might still install an unsigned driver.

Why driver signing matters

Drivers run in Kernel Mode — the most privileged level. A malicious or buggy driver can:

• Steal data from any process
• Hide rootkits at OS level
• Bypass anti-malware
• Crash the entire system

Driver signing is meant to ensure that an installed driver:

1. Hasn't been altered after release (file integrity)
2. Comes from a verified entity (publisher identity)
3. For WHQL-signed drivers: has been tested by Microsoft on a reference configuration

Driver signature types

1. Standard code signing

The driver developer purchases a code-signing certificate from a CA (Certificate Authority — DigiCert, Sectigo, etc.) and signs the driver with it. Windows then accepts the driver as long as the certificate is valid.

Typical for: niche peripherals, smaller hardware brands, beta/insider drivers.

2. Extended Validation (EV) Code Signing

Higher trust level — the developer must undergo additional vetting (legal documentation, in-person verification). EV certificates are stored on hardware tokens, not on regular machines.

Microsoft requires EV signatures for kernel-mode drivers since Windows 10 1607.

3. WHQL (Microsoft Hardware Quality Labs)

The strictest level: Microsoft tests the driver on a defined reference configuration and signs it itself. WHQL drivers are guaranteed to work without UAC prompts.

Manufacturers like Nvidia, AMD, Intel, Realtek almost always release WHQL versions — sometimes also "Beta" versions without WHQL alongside.

Checking a driver's signature

Via Explorer

1. Right-click the driver file (.sys, .inf) → Properties
2. "Digital Signatures" tab
3. Click signer → Details — shows certificate path

Via signtool (Microsoft)

For more detail (e.g. for installer files):

signtool verify /pa /v "C:\path\to\driver.sys"

signtool comes with the Windows SDK. Output includes "Successfully verified" or signs of cross-signing chain breaks.

When can you (carefully) install unsigned drivers?

Some scenarios where unsigned drivers are unavoidable:

• Self-developed driver during testing
• Very old hardware whose driver was never re-signed
• Hobbyist projects, e.g. for retro hardware

For these cases Windows offers Test Mode:

bcdedit /set testsigning on

(in cmd as administrator, then reboot)

Test Mode allows installation of unsigned drivers but:

• "Test Mode" watermark on the desktop
• HVCI doesn't work
• Some games (with anti-cheat) refuse to launch
• Banks/credit-card sites can refuse functions

Disable Test Mode again with:

bcdedit /set testsigning off

Important caveat: signed ≠ trusted

A signed driver is verified — but not necessarily safe. Many BYOVD-attacked drivers (CVE-2021-21551 Dell DBUtil, CVE-2019-16098 MSI RTCore64, CVE-2020-15368 ASRock RGB) were perfectly signed. Microsoft maintains a separate Vulnerable Driver Blocklist for known dangerous-but-signed drivers.

Activate the blocklist via HVCI (see article on Vulnerable Drivers).

Practical recommendations

1. Standard for everyone: only install WHQL drivers. Sufficient for 95% of needs.
2. For active gamers: beta drivers (signed but not WHQL) of Nvidia/AMD are OK if you accept the risk.
3. For developers/hobbyists: Test Mode is acceptable — but only on dedicated test machines.
4. Never: disable Driver Signature Enforcement permanently. That's an open door for malware.
5. Always verify: Microsoft Vulnerable Driver Blocklist active, HVCI active.