---

name: driver-signing description: | Windows driver signing and certification: EV (Extended Validation) code-signing certificates, Microsoft Hardware Dev Center attestation signing, WHQL/HLK certification, INF Section requirements, dual-signing, kernel driver signing policy (Win10 1607+), test signing, cross-signing legacy notes, and signtool/signability validation.

USE WHEN: user mentions "driver signing", "EV cert", "attestation signing", "WHQL", "HLK", "Hardware Dev Center", "Partner Center", "signtool", "test signing", "DSE bypass", "cross-signed driver", "INF compliance", "dual-signed kernel driver"

DO NOT USE FOR: Authenticode signing of normal apps, certificate management unrelated to drivers, macOS / Linux signing allowed-tools: Read, Grep, Glob, Write, Edit

Driver Signing & Certification - Quick Reference

Deep Knowledge: Use mcp__documentation__fetch_docs with technology: driver-signing. Authoritative sources:

• learn.microsoft.com/en-us/windows-hardware/drivers/install/driver-signing
• learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/

The two signing tracks (post-Windows 10 1607)

Track	What it gives you	Cost / time
Attestation signing (Partner Center)	A driver that loads on every modern Windows. No HLK tests, no logo.	EV cert (~$300-500/yr) + free attestation submission, hours-to-1-day turnaround
WHQL / HLK certification	"Certified for Windows" branding, can ship via Windows Update, broader test pass evidence	EV cert + HLK lab (your own or a partner) + submission, days-to-weeks

Both require an EV (Extended Validation) code-signing certificate issued to your company. Standard OV/Authenticode certs are no longer accepted for kernel drivers as of 1607.

What "kernel-mode signing" actually checks at load time

When ntoskrnl (or a UMDF reflector) loads a driver:

1. The .sys (or .dll for UMDF) must be Authenticode-signed
2. The signature chain must terminate at a Microsoft-issued cert (delivered via Partner Center attestation or WHQL flow)
3. Optionally page-hashes inside the PE are checked under HVCI

If the OS is in test mode (bcdedit /set testsigning on), the load policy is relaxed: any test-signed driver loads. Test mode is for development only — production users should never need it.

Workflow: development → ship

[develop]   build .sys + .inf
   |
[test sign] makecert / signtool with self-signed test cert
   |        bcdedit /set testsigning on  (one-time on test box)
   |        load with pnputil /add-driver MyDrv.inf /install
   |
[verify]    SDV + CodeQL + Driver Verifier + (HLK if going WHQL)
   |
[package]   build a .cab containing INF + SYS + CAT (catalog) + co-files
   |        sign the .cab with EV cert (timestamped)
   |
[submit]    Partner Center → Hardware → Driver → New submission
   |        - attestation only (single OS family) or
   |        - HLK package + test results (full WHQL)
   |
[receive]   Microsoft signs the catalog — download signed package
   |
[ship]      Distribute the signed package via installer / Windows Update

Test signing (development only)

:: Create a self-signed test cert
makecert -r -pe -ss PrivateCertStore -n "CN=WDKTestCert" -eku 1.3.6.1.5.5.7.3.3 wdktest.cer

:: Sign the .sys
signtool sign /v /s PrivateCertStore /n WDKTestCert /t http://timestamp.digicert.com ^
    /fd sha256 MyDriver.sys

:: Generate the catalog from the INF
inf2cat /driver:C:\path\to\driverpkg /os:10_X64

:: Sign the catalog
signtool sign /v /s PrivateCertStore /n WDKTestCert /t http://timestamp.digicert.com ^
    /fd sha256 MyDriver.cat

:: Enable test signing on target machine (admin, requires reboot)
bcdedit /set testsigning on

Production: attestation signing

Prerequisites:

1. EV code-signing certificate in a hardware token (DigiCert, Sectigo, GlobalSign — any provider in the Microsoft trust list)
2. Partner Center account with the Hardware program enabled (one-time EV-signed registration)
3. Driver passes Inf2Cat and signtool verify /v /kp /a clean

Build a driver package (.cab):

:: 1. Layout in a folder:
::    pkg\
::      MyDriver.inf
::      MyDriver.sys
::      MyDriver.cat   <-- generated by inf2cat
::      <co-installers, additional bins>

:: 2. Make a CAB
makecab /D CabinetNameTemplate=MyDriverPackage.cab /D DiskDirectoryTemplate=. /F sources.ddf

:: 3. Sign the CAB with the EV cert
signtool sign /v /a /n "Your Company" /tr http://timestamp.digicert.com /td sha256 ^
    /fd sha256 MyDriverPackage.cab

:: 4. Upload via Partner Center → Hardware → Driver → New submission
::    Choose Submission type = Automatic / Attested / etc.

Microsoft signs the catalog inside the package and returns a signed package — that's what you ship.

INF — what reviewers (and infverif) flag

Run infverif.exe /v /w MyDriver.inf for Windows 10/11 universal compliance:

• Class and ClassGuid must be one of the standard classes (or your custom class is also registered correctly)
• CatalogFile= directive must reference the .cat
• DriverVer= date format MM/DD/YYYY,X.Y.Z.W (date must be ≤ today, version monotonic)
• Architecture decorations: [Standard.NT$ARCH$.10.0...19041] (no NT5/XP-only sections)
• No deprecated Include/Needs patterns
• No co-installers unless absolutely needed (deprecated for universal drivers)
• File destination dirs must be in the allowed set (12 = \Drivers, 13 = \DriverStore)

WHQL / HLK in one paragraph

The Hardware Lab Kit is a Microsoft test harness: install the controller on one machine, the studio on another, point at your driver and device, choose a feature playlist (HID, Display, Mobile Broadband, etc.), and run. The output is a .hlkx package with logs + filters; you upload that with the signing submission. HLK takes hours to days depending on the playlist size; some scenarios need specific reference hardware.

Dual signing (legacy + modern)

For drivers targeting Win7/8/8.1 in addition to Win10+, dual-sign with an SHA-1 cross-cert + an SHA-256 EV cert. Win7/8 won't trust SHA-256 only; Win10 1607+ won't trust unattested cross-signed drivers. Most new projects target 10+ only and skip the SHA-1 leg.

Verifying a signed binary

signtool verify /v /pa MyDriver.sys
signtool verify /v /kp /a MyDriver.sys     :: kernel policy

/kp simulates the kernel-mode policy check — if this fails, the driver won't load on production machines even with a valid signature.

Anti-Patterns

Anti-Pattern	Why It's Bad	Correct Approach
Shipping with bcdedit testsigning on instructions for end users	Disables a security boundary, support nightmare	Get EV + attestation signing
Standard OV cert (not EV)	Won't be accepted by Partner Center for drivers	Use a real EV cert in a hardware token
Forgetting the timestamp server	Signature expires when the cert expires	Always pass /tr <RFC3161> and /td sha256
Modifying the driver after inf2cat	Catalog hashes don't match → "WHQL fails", driver won't load	Re-run inf2cat and re-sign after every change
Co-installers in a universal driver package	Deprecated, breaks infverif /v /w	Move logic into EvtDevicePrepareHardware or a separate service
Mixing test-signed and production binaries in one INF	Catalog can't cover both	One INF per signing track
Shipping unsigned UMDF drivers because "they're user-mode"	Reflector still requires the catalog signed	Sign UMDF DLLs and INF the same way as KMDF
Forgetting /kp in verification	Loads on dev, fails on prod	Always run signtool verify /v /kp /a before shipping