Windows Kernel Driver Signing in 2026: EV Certs, WHQL, and the signed third-party driver Blocklist

Shipping a kernel driver on Windows 11 24H2 in 2026 is not the free-for-all it was in 2015. Every legitimate path through the loader now requires either an attestation signature from Microsoft's Partner Center or a WHQL cross-signature backed by an EV code-signing certificate. The signed-third-party-driver shortcut that let a decade of cheat authors ride other vendors' signed drivers is largely closed by the signed third-party driver Blocklist. The manual-map shortcut is closed by HVCI. What is left is the boring, expensive, paperwork-heavy path that shipping a real product on modern Windows actually requires.

This post is a working reference for that path: what an EV cert costs and how you get one, what WHQL and attestation signing actually mean at the mechanical level, how the signed third-party driver Blocklist gets updated and enforced, and what the revocation calculus looks like when a driver you signed ends up in the wrong hands.

Windows driver signing in 2026

Windows treats kernel drivers as a class apart from user-mode binaries. A user-mode PE with a valid Authenticode signature runs fine anywhere; a driver PE has to satisfy the Kernel-Mode Code Signing (KMCS) rules, which are more restrictive and have tightened three times in the last decade.

The current (24H2) matrix:

The two paths that matter for a new driver in 2026 are WHQL and attestation. Everything else is legacy or enterprise-only.

What an EV certificate actually is

An EV (Extended Validation) code-signing certificate is not a special file. It is an ordinary code-signing cert with a specific issuance policy: the CA verifies the applicant through documented Extended Validation vetting (business registration, address, phone verification, sometimes an in-person notary), and the private key must live on a FIPS 140-2 Level 2 hardware token that the CA ships to the applicant. The token is a small USB dongle that requires a PIN for every signing operation.

Vendors: Sectigo, DigiCert, GlobalSign, SSL.com are the current major issuers. Pricing sits around USD 400 to 700 per year for a single certificate, plus one-time fees for the hardware token if the CA charges for it separately. Renewal requires re-verifying business status.

The EV requirement matters because Microsoft's Partner Center will not accept driver submissions signed by non-EV certificates. There is no path to WHQL or attestation without one. The dongle requirement means signing is not fully automatable; every signed build requires a human with the PIN, which is why serious kernel-mode vendors build their signing pipeline around a dedicated air-gapped signing machine rather than baking the token into CI.

Attestation signing: the shorter path

Attestation signing is the newer, lighter-weight of the two Partner Center paths. Microsoft added it because WHQL is heavy and many drivers do not need boot-start capability. The workflow:

1. Sign the driver locally with the EV certificate.
2. Package the driver with an INF and any dependent files.
3. Submit the package through Partner Center (partner.microsoft.com).
4. Microsoft's Attestation Signing service adds a Microsoft signature to the driver.
5. Download the signed package.

The mechanical signing step uses signtool.exe from the Windows SDK with the EV token plugged in and the PIN prompted per invocation:

signtool sign /v /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /sha1 <ev-cert-thumbprint> /a /as MyDriver.sys
signtool sign /v /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /sha1 <ev-cert-thumbprint> /a /as MyDriver.cat

/tr timestamps the signature so it keeps verifying past cert expiry; /as appends rather than replaces, so the .sys can carry both the vendor EV signature and the Microsoft attestation signature after Partner Center returns.

Verifying with Get-AuthenticodeSignature before upload catches wrong-cert, unreachable-timestamp, or skipped-cat mistakes:

Get-AuthenticodeSignature .\MyDriver.sys | Format-List Status,SignerCertificate,TimeStamperCertificate
# Status                  : Valid
# SignerCertificate       : [Subject] CN=Contoso, Inc., ...
# TimeStamperCertificate  : [Subject] CN=DigiCert Timestamp Responder ...

Sysinternals sigcheck -a -h MyDriver.sys prints the same plus the SHA256 the signed third-party driver Blocklist keys on.

The turnaround is measured in minutes to hours, not days. No hardware compatibility tests, no test lab, no test report. The tradeoff: attestation-signed drivers cannot be marked as boot-start, and they cannot ship as part of a Windows Update driver package. For any driver that only needs to load after user session start (which covers nearly every anti-cheat and every game-adjacent driver), this is fine.

The Partner Center dashboard for driver submission is documented at learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/. The submission has to include a valid INF file and an EV-signed driver binary. Common submission failures: unsigned or wrongly-signed cat files, INF syntax errors, references to non-existent files in the package.

Inside Partner Center the flow is Hardware > Drivers > New submission: upload a ZIP containing the .sys, .cat, .inf, and any dependent files, then pick target OS versions. The portal validates INF syntax and cat signatures synchronously and rejects malformed uploads immediately with a line pointing at the offending file. On success the submission queues by driver class; attestation typically returns the signed package inside a couple of hours, downloadable from the same submission page with an updated Microsoft-countersigned .cat included.

WHQL: the fuller path

WHQL (Windows Hardware Quality Labs) certification is the older, heavier path. In addition to attestation, WHQL requires:

• Passing the Hardware Lab Kit (HLK) test suite for the driver's device class. The HLK is a downloadable test framework that runs a battery of tests appropriate to the device.
• Uploading the HLK test report to Partner Center alongside the driver.
• Optional: publishing the driver to Windows Update for automatic distribution.

WHQL takes days to weeks depending on the queue and the driver class. The upside is that WHQL-signed drivers can be marked boot-start, can ship on Windows Update, and carry the full Microsoft signature that some enterprise deployments require.

For most anti-cheat and cheat-adjacent kernel components, attestation is sufficient. WHQL is worth the pain only for drivers that must load early in boot or that need OEM distribution.

The signed third-party driver Blocklist

Microsoft maintains a driver.stl blocklist at %SystemRoot%\System32\CodeIntegrity\driver.stl (and the newer SiPolicy.p7b). The list names, by SHA256 hash, drivers that Microsoft has judged to expose privilege-escalation primitives. HVCI enforces the list at load time, and starting with Windows 11 22H2 it is enabled by default when HVCI is on. Windows Update pushes blocklist updates on a quarterly cadence, with out-of-band updates when a particularly notorious driver enters wide use.

The quarterly cadence in 2026 lands in the March, June, September, and December Windows Update rollups, with out-of-band pushes when a specific driver hits wide malicious use. The public GitHub repo lags the shipped policy by a few days. Enterprise admins can pin an older WDAC policy for compatibility; consumer boxes take the update automatically in the Patch Tuesday rollup.

The list is public and documented by Microsoft, with the block rules mirrored on GitHub at github.com/microsoft/Microsoft-recommended-driver-block-rules. It currently contains 400+ entries covering essentially every publicly-known signed-driver-abuse candidate: iqvw64e.sys, RTCore64.sys, gdrv.sys, AsIO.sys, WinRing0x64.sys, and a long tail of similar vendor drivers.

For a legitimate driver author, the blocklist is mostly benign. The rule is straightforward: do not ship exploitable IOCTLs. Do not expose arbitrary MmMapIoSpace, arbitrary MSR writes, arbitrary PCI config access, or any memory-write primitive that a user-mode caller can influence. Every driver that ends up on the blocklist got there by breaking that rule.

For a driver author who did break it, once the hash is on the blocklist, that specific binary is dead on HVCI machines. Recompiling with a new hash lets the new binary load until Microsoft catches up and adds it too. That is the treadmill vendors relying on third-party signed drivers spend their engineering budget on, and it is exactly what a serious kernel-mode vendor is trying not to build a business on.

Certificate revocation and the reset it forces

When a signed driver ends up doing something Microsoft dislikes at scale, the response can go one of two ways:

1. Add the specific driver hash to the blocklist. This kills that binary but does not affect other drivers signed by the same certificate.
2. Revoke the code-signing certificate. This kills every binary signed by that certificate, past, present, and future.

Certificate revocation is the nuclear option and it hurts. A vendor who ships a driver line under one EV certificate and gets that certificate revoked has to obtain a new certificate (which means going through EV validation again, which takes days) and re-sign every currently-deployed driver. Customers on the old signature see load failures until they update.

The revocation trigger in practice is either (a) the cert was compromised and confirmed stolen, or (b) the driver signed under the cert has been used maliciously at scale and Microsoft judges that revoking is the correct response. Sober driver vendors keep multiple certificates in reserve for exactly this contingency, and structure their loader so that a certificate swap is a signed configuration change rather than a full re-release.

The comparison table

The high-level shape of the current paths:

The only two rows that lead to a viable product on 2026 Windows are the first two.

The compliance surface a driver author actually thinks about

Beyond the mechanical signing question, a driver targeting 2026 Windows has to satisfy several ongoing hygienic requirements:

• No exploitable IOCTLs. No arbitrary memory access primitives, no user-controllable MSR access, no unchecked physical memory operations. Any of these and the driver goes on the blocklist.
• Correct pool tagging and lifetime. Pool allocations use a driver-specific tag so they show up correctly in !pool under WinDbg and in memory-dump triage. Leaked allocations show up in Driver Verifier and get flagged.
• HVCI compatibility. No RWX allocations, no self-modifying code, no MmAllocateContiguousMemory with PAGE_EXECUTE_READWRITE, no PatchGuard-triggering writes to protected structures.
• PnP and power management sanity. If the driver claims to be a device driver, its PnP handling has to be correct. Failure to handle IRP_MN_REMOVE_DEVICE cleanly, or leaving devices in the wrong power state, both surface in Driver Verifier as bugchecks.
• Signed catalog. The .cat file that ships with the .sys must be Microsoft-signed via the Partner Center flow. Local test signing does not satisfy the loader on HVCI machines.

Driver Verifier (verifier.exe) is the tool every driver author runs against their own code before submission. Enable it against the driver, run under Verifier for the full test surface, resolve every bugcheck it produces. Skipping this step is how attestation submissions come back rejected.

Test signing on the development box

Nobody round-trips every intermediate driver build through Partner Center. Development iteration uses local test signing: a self-signed cert dropped into the machine's trusted cert stores, bcdedit flipping the boot loader into test mode, and a small watermark in the corner of the desktop that reminds you the box is in a permissive state.

# Enable test signing (requires admin, requires a reboot, requires Secure Boot off)
bcdedit /set testsigning on

# Roll back after the debug session
bcdedit /set testsigning off

On a Secure Boot machine the first command succeeds at the bcdedit layer, but the boot manager refuses to honor it: the next boot lands at a Secure Boot violation and refuses to start Windows until Secure Boot is disabled in firmware or testsigning is turned back off from recovery. HVCI is stricter still. Test-signed drivers do not load when Memory Integrity is enforcing, because the policy runs inside the secure kernel and is not gated by boot flags. Practical setup: a dedicated bare-metal box or Hyper-V VM with Secure Boot off, HVCI off, testsigning on, kernel debugger attached, and nothing else happening on that machine.

How KyTech handles this

KyTech was founded in 2025 by two engineers with backgrounds in Windows kernel work, and the entire product line rests on the paperwork side of driver signing. We maintain an EV certificate through a mainstream CA, we submit drivers through Partner Center attestation signing, and we do not manual-map or depend on Microsoft failing to notice a signed third-party driver we might otherwise chauffeur on.

The tradeoff is explicit. We pay for the certificate every year, we run each new driver through Driver Verifier before submission, and we accept the multi-hour attestation turnaround as the cost of shipping a driver that survives Windows 11 24H2 with HVCI on. The upside is that a KyTech driver load in Windows Event Viewer looks like any other legitimate driver load, and Microsoft's next monthly Cumulative Update does not silently kill our loader the way it kills competitors who depend on third-party signed drivers.

Our current supported titles (Apex Legends, CS2, Overwatch 2, Black Ops 7, Forza Horizon 6, Roblox) all ride the same signed KyTech driver, with per-title user-mode components on top. The flagship signed-driver build is KyTech Apex. The HWID spoofer beta is Apex-only for now while we finish per-title validation, and it uses the same signing pipeline as everything else we ship. Current build status and pricing are on the purchase page. For the wider context of what the signing regime replaced and why the shortcuts died, see our posts on manual mapping kernel drivers and HVCI.