How to Sign a Windows Driver (Attestation Signing, Step by Step)

Why can't you sign a kernel driver yourself?

Because kernel code runs with more privilege than anything else on the machine, Windows holds it to a different trust standard than applications. An EXE with a valid publisher signature gets a SmartScreen decision; a kernel driver gets a boot-time code integrity check that, since Windows 10 version 1607, requires a signature from Microsoft's Hardware Dev Center — not from your certificate, whoever issued it.

The reasoning is straightforward: a malicious or compromised kernel driver doesn't just affect one app, it owns the operating system. Publicly trusted CAs vet publishers, but they never see the code. By routing every production kernel driver through its own signing service, Microsoft gets a central choke point — it knows exactly what was signed, by whom, and can revoke a specific driver version without touching the publisher's certificate.

Your certificate still matters — it's how Microsoft knows who you are. Partner Center accounts are anchored to an EV code signing certificate, and every submission CAB you upload must be signed. So the practical flow is always the same: you vouch for the submission, Microsoft signs the driver. Keep that in mind and the rest of this guide is mostly mechanics.

Cross-signing is gone: what changed and when

Cross-signing — CA-issued kernel signing certificates chained to Microsoft's cross-certificates — was the old way to sign drivers yourself. Microsoft deprecated the program in 2021, the certificates behind it have expired, and the April 2026 Windows update removed default trust for cross-signed kernel drivers on Windows 11 24H2, 25H2, 26H1, and Windows Server 2025. New driver work should assume that path no longer exists.

This matters even if you never cross-signed anything, because it explains the confusing advice still floating around. Older tutorials — and some CA marketing pages — describe buying a kernel-capable certificate and signing your .sys file directly. That workflow died in stages, and the residue of each stage still shows up in the wild:

The practical takeaway: timestamped cross-signed drivers kept loading for years after 2021, which let some vendors put off resubmission. Machines that took the April 2026 update on the affected versions now load only Microsoft-signed kernel drivers by default. If you maintain a driver that predates attestation, resubmitting it through Partner Center is no longer optional housekeeping — it's the difference between loading and not loading on current Windows.

What you need before you start

Three things, in order: an EV code signing certificate, a Microsoft Partner Center account for the hardware program (which requires that certificate to register), and the signing tools — SignTool from the Windows SDK plus MakeCab, which ships with Windows. The EV requirement is Microsoft's, not the CA's: attestation and WHQL submissions both demand at least one EV certificate on the account.

Attestation signing, step by step

Attestation signing means Microsoft signs your driver on your word — you attest that it's tested and safe, no lab tests required. The mechanics: package the driver files into a CAB, sign the CAB with your EV certificate, upload it in Partner Center, and download the Microsoft-signed result, usually within the hour. Here is each step with the exact commands.

Step 1: Build the CAB file

The CAB contains your driver folder: the INF, the compiled .sys binary, and ideally the .pdb symbol file so Microsoft can analyze crashes. Catalog files are optional — Microsoft regenerates them during signing anyway. Describe the contents in a DDF file and feed it to MakeCab. Two format rules: use real paths (mapped drives, not UNC paths), and keep every driver folder in the CAB to the same architecture set.

; MyDriver.ddf
.Set CabinetNameTemplate=MyDriver.cab
.Set DestinationDir=MyDriver
C:\MyDriver\MyDriver.inf
C:\MyDriver\MyDriver.sys
C:\MyDriver\MyDriver.pdb

REM Build it (output lands in .\disk1\):
MakeCab /f MyDriver.ddf

Step 2: Sign the CAB with your EV certificate

This is the only signature you apply in the whole production flow — and it goes on the CAB, not the driver. SHA-256 digest and a SHA-256 certificate are required; a timestamp is good practice on anything you sign. With a hardware token, expect the PIN prompt here.

signtool sign /s MY /n "Your Company Name" /fd SHA256 ^
  /tr http://time.certum.pl /td SHA256 disk1\MyDriver.cab

Step 3: Submit in Partner Center

In the Partner Center hardware dashboard, choose "Submit new hardware," name the product, upload the signed CAB, and pick the Windows versions the driver should be signed for. Leave the test-signing checkboxes unchecked — those produce test-only signatures. Microsoft runs automated malware and quality scans, signs the driver, and the submission page offers the signed package for download.

Step 4: Verify and ship

Download the signed package and check what came back before it goes anywhere near an installer. The signature on the .sys file should now chain to Microsoft, with your company listed in the attributes.

signtool verify /pa /ph /v /d MyDriver.sys

REM Install the package on a clean test VM with Secure Boot ON --
REM that's the environment your users actually run.

Attestation or WHQL: which submission do you need?

Attestation is faster and covers Windows 10 and 11 client systems; WHQL certification through the Windows Hardware Compatibility Program covers everything else. The two hard lines: Windows Server 2016 and later only loads dashboard-signed drivers that passed the HLK tests, and only certified drivers can be published through Windows Update. If neither applies to you, attestation is the sensible default.

WHQL is a bigger investment: you set up an HLK test environment (or hire a lab), run the test suite for your device class on each Windows version you target, and submit the results package. What you get for it is reach — Server support, Windows Update distribution, and the "certified" status some enterprise customers require in procurement. Plenty of teams run both tracks: attestation for fast fixes to client-only tools, WHQL for the flagship hardware driver.

One planning note: attestation-signed drivers aren't retroactively valid on Server, and there's no upgrade button — a Server-capable release means a fresh WHQL submission with HLK results. Deciding which audiences matter before you ship the first version saves an awkward re-release later.

Test signing during development

You don't submit every debug build to Microsoft. For development, Windows offers test signing mode: the machine accepts drivers signed with your own test certificate, and reminds you with a "Test Mode" watermark on the desktop. Enable it with bcdedit on a test machine or VM — Secure Boot blocks the change, so test boxes typically run with it off.

REM On the TEST machine (admin prompt, then reboot):
bcdedit /set testsigning on

REM Create a test certificate (developer machine, PowerShell):
New-SelfSignedCertificate -Type CodeSigningCert -Subject "CN=MyDriver Test" ^
  -CertStoreLocation Cert:\CurrentUser\My

REM Generate the catalog from the INF (WDK):
Inf2Cat /driver:C:\MyDriver /os:10_x64

REM Sign the catalog with the test certificate:
signtool sign /s MY /n "MyDriver Test" /fd SHA256 MyDriver.cat

REM Install the test certificate into the test machine's
REM Trusted Root and Trusted Publishers stores, then install the driver.

Keep the two worlds strictly separate: test-signed packages are for machines you control, production packages come back from Partner Center. If a test-signed build escapes to a customer, it simply won't load on their normally configured system — which is the policy working as designed, though it rarely feels that way at the support desk.

Common driver signing errors

Most driver signing failures trace back to one of three mismatches: the driver lacks a Microsoft signature, the signature type doesn't match the Windows edition, or the install package is missing a signed catalog. Here are the errors those produce and what actually fixes each one.