Windows Driver Code Signing: Requirements, Certificates & How It Works (2026)

Windows driver signature enforcement requires all device drivers to be signed with a trusted code signing certificate before Windows will load them. This protects against malicious drivers that could compromise system security. Since Windows 10 version 1607, Microsoft requires kernel-mode drivers to be signed through the Windows Hardware Dev Center using either the Hardware Lab Kit (HLK) or Microsoft's attestation signing service - self-signed certificates are no longer accepted for kernel-mode production drivers.

What Is Driver Signature Enforcement?

Driver signature enforcement is a Windows security policy that blocks any driver lacking a valid cryptographic signature from loading into the kernel. It was introduced in 64-bit Windows Vista and significantly tightened with Windows 10 version 1607, when Microsoft required all new kernel-mode drivers to carry a Microsoft-issued countersignature. A "signature" in this context is cryptographic proof that a specific, verified publisher produced the driver and that no one has modified it since.

When Windows encounters an unsigned driver - or one signed with an untrusted certificate - it refuses to load it and surfaces an error. This policy exists specifically to block rootkits and other malware that historically exploited unsigned kernel drivers to gain complete control of a system. For a broader look at digital certificate types used in code security, see our guide on code signing certificate fundamentals.

How Does Driver Code Signing Work?

The signing process binds your identity, as a verified organization, to the driver binary using public key cryptography. Windows verifies that binding at load time - if the hash of the file no longer matches the signature, or if the certificate chain is untrusted, the driver is rejected. The full production flow follows these steps:

1. Install the Windows Driver Kit (WDK): This includes SignTool.exe and the required test frameworks.
2. Obtain an EV code signing certificate: From a Microsoft-trusted Certificate Authority, delivered on a hardware security token.
3. Sign the driver binary: Using SignTool.exe with SHA-256 hashing and a timestamp server URL.
4. Submit to Microsoft's Hardware Dev Center: For attestation signing or full HLK certification.
5. Receive Microsoft's countersignature: This is what Windows actually verifies at load time.
6. Distribute the signed driver package: Signed drivers install without security warnings on supported Windows versions.

Important: Windows Server 2016 and later requires drivers to pass HLK testing - attestation signing alone is not accepted for Server environments, according to Microsoft's driver code signing requirements (updated 2024).

What Type of Certificate Do You Need to Sign Windows Drivers?

The certificate type determines what you can sign and where the driver can run. The table below maps each certificate type to its use case and kernel-mode support. For a deeper comparison of OV vs EV for general Windows applications, see OV vs EV for Windows apps.

The most critical distinction: only an EV code signing certificate allows you to submit drivers to the Microsoft Hardware Dev Center. OV certificates work for user-mode software but are rejected for kernel-mode driver submissions.

EV Code Signing Certificate - Required for Kernel Drivers

An Extended Validation (EV) code signing certificate requires the CA to physically verify your organization's legal existence, operational address, and authorized contacts. The private key must be stored on a FIPS 140-2 Level 2 compliant hardware token - it cannot be exported or cloned. This hardware requirement is what makes EV certificates suitable as a submission credential for Microsoft's portal.

As of 2026, the leading CA providers for driver EV certificates are DigiCert ($409/yr), Sectigo ($290–$499/yr), and GlobalSign - all of which are accepted by Microsoft's Hardware Dev Center. See the full breakdown in our EV code signing certificate guide, or compare options across top CA providers.

Microsoft Attestation Signing - Free for Desktop Drivers

Attestation signing is a free service where Microsoft countersigns your driver after running automated compatibility checks, without requiring full HLK testing. Your Hardware Dev Center account must have at least one valid EV certificate associated with it before any submission is accepted, according to Microsoft's official code signing requirements. Attestation-signed drivers work on Windows 10/11 Desktop but cannot be distributed via Windows Update to retail audiences.

To push a driver to retail audiences through Windows Update, you must go through the full Windows Hardware Compatibility Program (WHCP), which requires passing the complete HLK test suite. Attestation signing is best suited for enterprise internal deployments or pre-release testing.

How to Sign a Windows Driver Step by Step

The following steps cover the production signing workflow for a kernel-mode driver targeting Windows 10 and Windows 11. Run these commands from an elevated Developer Command Prompt with your EV token inserted.

1. Install the Windows SDK and WDK: Download from Microsoft's developer site. This installs SignTool.exe and all necessary driver development tools.
2. Obtain your EV code signing certificate: Purchase from a Microsoft-trusted CA, complete identity verification, and install the hardware token drivers on your signing machine.
3. Sign the driver .sys file:

signtool sign /fd sha256 /tr http://timestamp.digicert.com /td sha256 /a driver.sys

4. Verify the signature:

  signtool verify /v /pa driver.sys

5. Log into the Microsoft Hardware Dev Center at microsoft.com/dashboard/hardware, sign your submission package with your EV certificate and submit for attestation or HLK signing.
6. Test on a clean Windows VM before distributing - verify the driver loads without errors and passes basic functional checks in the target OS environment.

Common SignTool Errors and How to Fix Them

Three errors account for the majority of signing failures:

Disabling Driver Signature Enforcement - Development and Testing Only

Warning: Disabling driver signature enforcement removes a critical security layer. Only do this on isolated development VMs or test machines. Never disable it on production systems or instruct end users to disable it - a proper EV certificate is the correct solution for any driver intended for real-world deployment.

For legitimate development scenarios, Windows provides three methods:

Any driver that exits the test environment must go through proper Microsoft signing before deployment. Test mode bypasses the protection - it does not replace it.

The table above summarizes when each method is appropriate. Attestation and WHQL are the only paths for real-world driver deployment.

Final Thoughts

Driver signing is not a compliance checkbox - it is the mechanism that keeps kernel-mode code trustworthy across every Windows machine. The process is straightforward once you have an EV certificate: sign with SignTool.exe, submit to Microsoft's Hardware Dev Center, and distribute a driver that loads without friction on Windows 10 and 11.

The test-mode bypass covered in this article serves one purpose: letting developers iterate quickly before the driver is ready for submission. As Microsoft tightens HLK requirements with each Windows release cycle, starting the certification process early - and choosing a CA whose roots Microsoft accepts - saves significant delays at release time.

Frequently Asked Questions

Why does Windows require driver signature enforcement?

Windows requires driver signing to prevent malicious software from loading kernel-mode drivers that could compromise system security. Unsigned or tampered drivers are blocked because they could give attackers complete control of the operating system. The policy became mandatory for new kernel-mode drivers with Windows 10 version 1607.

Can I use a self-signed certificate to sign Windows drivers?

Only for testing on machines with test mode enabled. Self-signed certificates work when bcdedit /set testsigning on is active, but Windows rejects them on standard production systems. For any driver distributed to end users, an EV code signing certificate from a Microsoft-trusted CA is required.

How much does a driver signing certificate cost?

EV code signing certificates, which are required for kernel-mode driver submissions, cost between $249 and $500 per year from providers such as DigiCert, Sectigo, and GlobalSign. They are delivered on a hardware security token and the private key cannot be exported or transferred to another device.

What is the difference between WHQL and attestation signing?

WHQL (Windows Hardware Quality Labs) certification requires passing the full HLK hardware compatibility test suite and grants Microsoft logo certification. Attestation signing skips HLK testing - Microsoft runs automated checks and countersigns the driver, but does not grant WHQL certification. Attestation-signed drivers cannot be distributed to retail audiences via Windows Update; WHQL-certified drivers can.

Is it safe to disable driver signature enforcement?

Not on any machine that handles real workloads. Disabling enforcement removes the protection that blocks malicious kernel drivers from loading. The correct approach is to sign the driver properly using an EV certificate and Microsoft's Hardware Dev Center - test mode is exclusively for isolated development environments.

What is Microsoft Trusted Signing and should I use it instead of an EV certificate?

Microsoft Trusted Signing (formerly Azure Code Signing) is a managed cloud-based alternative launched in 2024, available at $9.99/month. It stores credentials in FIPS 140-2 Level 3 HSMs without requiring a physical token. As of 2026, it supports user-mode signing scenarios - developers should verify current Hardware Dev Center portal requirements before using it for kernel-mode driver submissions.