Signing a Windows Driver Package: From EV Certificate to Partner Center

This guide walks you through compiling, cross-signing, and submitting a Windows driver package to the Microsoft Hardware Partner Center using a hardware-backed code-signing certificate.

Understanding the Hardware Requirement and Prerequisites

Since June 2023, the CA/Browser Forum requires all Organization Validation (OV) and Extended Validation (EV) code-signing private keys to be stored on certified hardware. Software-only PFX files are no longer issued or permitted by trusted CAs. For a driver package, you need a machine that stays powered on with the USB token plugged in, or a signing service in front of that token that your build pipeline can call (see Automate Code Signing in CI/CD Without Cloud HSM).

Before you begin the signing process, ensure your development environment has the Windows Driver Kit (WDK) installed alongside Visual Studio, and verify that your hardware token (such as a YubiKey, SafeNet, or ePass2003) is inserted and recognized by the host operating system. You will also need signtool.exe (from the Windows SDK) and inf2cat.exe (from the WDK), which are used to generate and sign the catalog.

Preparing and Building the Driver Package

Driver packages consist of a driver binary (.sys), an installation inf file (.inf), and a catalog file (.cat) that contains cryptographic hashes of all files in the package. Start by compiling your driver in Visual Studio under the appropriate configuration, such as Release for x64. Once compiled, verify that your INF file is correctly structured for the target operating systems.

Next, generate the catalog file using the Microsoft INF Catalog Generator tool. Open your developer command prompt and run the following command against your driver directory, replacing path\to\driver with your actual directory path and specifying the operating systems you intend to support:

inf2cat.exe /driver:"C:\path\to\driver" /os:10_X64

Add further targets as a comma-separated list; inf2cat /? lists the exact identifiers it accepts for each Windows and Windows Server version.

If the tool executes successfully, it creates a .cat file in your driver directory. Signing it with your own certificate lets you test-install the package; for release, Partner Center returns the package signed by Microsoft, which is what Windows requires for kernel-mode drivers. If the command fails due to unsigned third-party dependencies or catalog formatting errors, resolve those INF warnings before proceeding, as Microsoft Partner Center automated validation will reject any malformed catalog headers.

Signing the Driver Binaries and Catalog File

With your catalog file and driver binaries prepared, you can apply your digital signature. When using a physical USB token, Windows accesses the certificate through the Windows Certificate Store via cryptographic service providers. You must locate your certificate thumbprint or subject name to instruct signtool.exe which key to use on the hardware token.

List the certificates in your local store using PowerShell to find the thumbprint of your code-signing certificate:

Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert

Execute the signing command using signtool.exe. Point it to your timestamp server to ensure the signature remains valid after the certificate expires. Run the following command, substituting your certificate thumbprint and the path to your compiled driver catalog file:

signtool.exe sign /sha1 YOUR_CERTIFICATE_THUMBPRINT_HASH /tr http://ts.ssl.com /td sha256 /fd sha256 "C:\path\to\driver\your_driver.cat"

You can repeat this command for the individual .sys binary if you are performing embedded signing in addition to catalog signing. When the command runs, your hardware token middleware will prompt you to enter your hardware token PIN. Once entered, signtool applies the cryptographic signature directly from the secure hardware boundary.

Verifying the Signature Locally

Never submit an unverified package to Partner Center. You should verify both the cryptographic validity of the signature and the chain of trust locally on your build machine. Windows provides built-in validation commands via signtool that inspect the embedded or catalog signature against the root certificate authorities.

Run the verification utility against your signed catalog file:

signtool.exe verify /pa /v "C:\path\to\driver\your_driver.cat"

Examine the command output carefully. The verification tool must report that the signature is successfully verified and that the certificate path resolves to a trusted root authority. If the output indicates an untrusted root or a timestamp mismatch, check that your system clock is synchronized and that intermediate certificates are correctly cached in your local Windows certificate store.

Submitting the Package to Microsoft Partner Center

Once your driver package and its accompanying catalog file are fully signed and verified locally, you are ready to package them for submission. Partner Center accepts driver packages as a CAB file, so create a .cab (for example with makecab and a .ddf directive file) containing your .inf file, the signed .cat file, the .sys binary, and any associated support files.

Log in to the Microsoft Partner Center dashboard using your organization account with Hardware Developer privileges. Before uploading, sign the CAB itself with your EV certificate using the same signtool sign command; Partner Center only accepts a CAB signed with the EV certificate registered to your account. Then open the Hardware section, start a new driver submission and upload the signed CAB. The automated workflow will ingest your package, check that the CAB is signed with the EV certificate registered to your account, validate the package, and sign the driver with Microsoft's signature for distribution.

Monitor the submission status page for any validation errors. If the automated checks pass, download your signed production binaries directly from Partner Center for final distribution to your customers.