How Windows driver code signing actually works - Authenticode, Driver Signature Enforcement, WHQL certification, and HVCI - and why a valid signature does not mean a driver is safe.
Windows requires kernel drivers to be digitally signed before they load. That requirement stops casual tampering and unsigned malware - but it is routinely misunderstood as a guarantee of safety. This guide explains each layer of the driver-signing model and where its limits are.
Authenticode: who signed it
Authenticode is Microsoft's PE code-signing format. A signed driver carries a PKCS#7 SignedData blob in its certificate table containing the signer's certificate chain, the signature, and optionally a trusted timestamp. Verification answers two questions: has the file been modified since signing, and does the certificate chain up to a trusted root. It does not evaluate what the driver does.
Driver Signature Enforcement (DSE): the load-time gate
DSE is the 64-bit Windows feature that refuses to load a kernel driver unless it is validly signed. It can only be turned off through Test Mode or by exploitation, which is why attackers prefer to bring a driver that is already signed rather than try to disable DSE.
WHQL: tested for compatibility, not security
WHQL (Windows Hardware Quality Labs) certification adds a Microsoft signature attesting that a driver passed compatibility and reliability testing. It improves trust and distribution, but WHQL testing is not a security audit - vulnerable drivers have shipped with valid WHQL signatures and been abused for years afterward.
HVCI: validating code in the kernel
HVCI (Hypervisor-Protected Code Integrity) goes further than signing by using virtualization-based security to enforce that only validated code runs in the kernel, with W^X protection on kernel pages. It materially raises the cost of BYOVD attacks, though it is not universally enabled.
Why a signature is not safety
The crucial takeaway: signing proves provenance and integrity, not behaviour. A reputable, validly signed driver can still expose an arbitrary read/write IOCTL that turns it into a kernel weapon. This gap is exactly what BYOVD exploits, and it is why a signed driver should still be analysed before it is trusted.
How to check a driver's signature - and its real risk
You can inspect a signature manually with the file properties dialog or signtool. But to learn whether a signed driver is actually dangerous, you need to look at its imports and IOCTL surface as well. DriverShield does both: it parses the full Authenticode chain and combines it with import analysis, IOCTL extraction, YARA matching, and known-vulnerable cross-referencing to produce a single risk verdict. Try it on the scan page, browse signers in the code signing atlas, or learn the terms in the glossary.