Section 8: Driver Signing

The Big Picture: The Wax Seal on a Letter

In old times, a king sealed his letters with wax and his ring. If the seal was unbroken and matched his ring, you knew two things: the letter really came from him, and nobody had opened it on the way.

A digital signature does the same for software. Remember: a driver runs in ring 0 with full power (Section 3). If an attacker slips in a bad driver, they own the PC. So Windows wants proof of who made this driver and that it hasn't been changed.

8.1 Why Signing Exists (Integrity, Malware Prevention)

What it is: Driver signing means the driver package carries a digital signature that Windows checks before it lets the code into the kernel.

How a signature works in plain words (a short version):

1. The maker calculates a hash (a short fingerprint) of the files. (This is the catalog from Section 5.2.)
2. The maker encrypts the fingerprint with a private key that only they hold. That is the signature.
3. The maker also gets a certificate: a document, issued by a trusted authority, that says "this public key belongs to Company X."
4. Windows uses the public key (from the certificate) to check the signature, and recomputes the hash of the files. If both match, the files are genuine and unchanged.

   MAKER                                       WINDOWS
 files ──► hash ──► sign with private key ──►  check signature with public key
                                               recompute hash of files
                                                 │
                                    match? ──► YES: load driver
                                           └─► NO : refuse

What signing gives you:

Important: A signature proves who and unchanged. It does not prove the driver has no bugs or that it is not abusable. Attackers have been known to misuse legitimate, signed-but-vulnerable drivers. Windows has a blocklist of known-bad drivers for exactly this reason.

8.2 WHQL Certification

What it is: WHQL stands for Windows Hardware Quality Labs. This is the older name that many people still use. Today the programme is called the Windows Hardware Compatibility Program (and its tests the Windows Hardware Lab Kit, HLK).

The idea: the maker runs Microsoft's test suite on the hardware and driver. If it passes, the results are sent to Microsoft through the Windows Hardware Dev Center, and Microsoft signs the driver (or approves it). A WHQL/WHCP-certified driver is shown as published by "Microsoft Windows Hardware Compatibility Publisher".

Ways a driver gets a Microsoft-trusted signature (simplified):

Since Windows 10 version 1607, new kernel-mode drivers on Secure Boot systems generally must be signed through the Microsoft Dev Center (WHQL or attestation) to load. A maker needs a special Extended Validation (EV) code-signing certificate to use the Dev Center. (Details change over time; the idea is that Microsoft's signature is the one that counts for kernel drivers.)

See it yourself: Device Manager → device → Properties → Driver → shows Digital Signer. For many drivers it says Microsoft Windows Hardware Compatibility Publisher. Or, in PowerShell (read-only):

Get-CimInstance Win32_PnPSignedDriver |
  Select-Object -First 10 DeviceName, DriverProviderName, DriverVersion, Signer, IsSigned

8.3 Test Signing Mode

What it is: Developers write drivers and need to test them before they get Microsoft's signature. For that, Windows has test signing mode. When it is on, Windows accepts drivers signed with a test certificate that the developer made for their own use.

How it is turned on (for developers on a test PC only):

bcdedit /set testsigning on      (administrator, then restart)

When active, a watermark reads "Test Mode" at the bottom-right of the desktop, as a reminder that the PC accepts non-Microsoft-signed drivers.

Warning: Do not turn on test signing on your everyday PC just to make an "unsigned" driver install. Treat that as a red flag. It is better to find a signed version.

Also seen in older guides: "Disable driver signature enforcement" in the Advanced Startup menu. This is a one-time switch for a single boot. It lets an unsigned driver load that once. It is likewise something to avoid unless you are sure.

8.4 Signature Enforcement (Kernel-Mode Code Signing)

What it is: Kernel-Mode Code Signing (KMCS) is the rule that says on 64-bit Windows, every kernel-mode driver must have a valid digital signature, or it will not load. (32-bit Windows had a weaker rule; modern PCs are 64-bit.)

When is the check made?

If a driver fails, you see a message such as "Windows can't verify the digital signature for this file" (Device Manager Code 52), and the driver does not load.

How it connects with other protections (hedged on details):

  Power on ──► Secure Boot checks boot loader
                   │
                   ▼
            Boot loader checks the kernel and boot drivers
                   │
                   ▼
            Kernel checks every driver it loads (KMCS)
                   │
                   ▼
            (optional) HVCI keeps kernel code from being changed

Check it on your PC (safe): Run msinfo32 and look at Secure Boot State on the System Summary page. You can also see Memory integrity under Windows Security → Device security → Core isolation details. (On some PCs these are off or unavailable. That is normal.)

User-mode drivers (UMDF) and signing: They are still part of a driver package and are expected to be signed as part of the package, but because they do not run in the kernel, they do not carry the same risk.

Summary