If you’re a software publisher or device manufacturer developing drivers for Windows, you can’t just compile your .sys files, bundle them in an installer, and call it a day. Drivers dig deep into the operating system’s core — they interact with hardware, kernel processes, and critical system functions. Because of this, Microsoft locks down driver installation with strict security checks to protect users from malicious or faulty drivers.
That’s where code signing comes in — and for drivers, it’s not optional. If your driver isn’t properly signed and approved, Windows will reject it outright, block installation, or show alarming warnings that scare off users and corporate IT teams alike.
Two terms often come up when you dive into Windows driver signing: EV Code Signing Certificates and WHQL Signing. They’re not the same, but they’re closely related in the driver trust chain. Many developers confuse the two — so let’s clear it up, step by step, and see how DigiCert Code Signing Certificates fit into both.
Why Drivers Need Code Signing
First, it helps to understand the why.
When you sign a driver, you’re attaching a verified cryptographic signature to the driver files (.sys, .cat, .inf files). This signature does two critical things:
1️⃣ It proves authenticity — the driver really came from you, the verified publisher, not some shady hacker who tampered with the file.
2️⃣ It guarantees integrity — the driver code hasn’t been modified since you signed it. If even one byte changes, Windows will reject the signature.
For standard user-mode applications, you can often get away with just a regular code signing certificate (OV) — but for drivers, Microsoft is much stricter because these files operate at the kernel level.
What is WHQL Signing?
WHQL stands for Windows Hardware Quality Labs. This is Microsoft’s official program to test, certify, and approve drivers for Windows.
When you submit a driver package to Microsoft for WHQL certification:
-
Microsoft tests your driver in their labs for compatibility, stability, and security.
-
If it passes, they sign it with a special Microsoft signature.
-
This WHQL signature tells Windows that your driver is trusted by Microsoft and can be installed without additional warnings.
For many device makers (especially those shipping hardware to end-users), WHQL certification is practically mandatory — not only for user trust but because many OEM partners or big retailers won’t touch hardware without it.
Where Does DigiCert EV Code Signing Fit In?
Here’s where it gets interesting: You can’t submit a driver for WHQL certification unless you first sign it yourself — and that signature must come from an Extended Validation (EV) Code Signing Certificate.
In other words, the EV Code Signing Certificate acts as the “passport” that proves your identity to Microsoft’s Windows Hardware Developer Center Dashboard. Without it, you won’t even get past the front door.
Why EV? Because Microsoft wants maximum identity assurance for kernel-mode drivers. Standard (OV) code signing certificates aren’t strong enough. EV certificates, by contrast, require rigorous vetting and the private key is stored on a secure hardware token — meaning it can’t be easily stolen or copied.
So:
-
To sign a standard app or user-mode driver, you can use OV, but it won’t get you WHQL.
-
To sign a kernel-mode driver for Windows 10 or newer, Microsoft requires EV code signing.
-
To submit for WHQL certification, you must sign with EV first
The Windows Driver Signing Chain: How It Works
Let’s connect the dots in plain English:
1️⃣ You develop your driver package — including your .sys driver file, .inf setup file, and .cat catalog file.
2️⃣ You sign the driver package with your DigiCert EV Code Signing Certificate.
-
This confirms that the driver came from you, the verified publisher.
-
It uses your EV certificate’s private key on a secure USB token — adding tamper resistance.
3️⃣ You submit the signed driver to Microsoft’s Windows Hardware Developer Center Dashboard.
-
Microsoft tests the driver for compatibility and stability (this is the WHQL process).
-
If the driver passes, Microsoft adds their own digital signature to the package.
4️⃣ When users install your driver, Windows checks both signatures.
-
First, it checks your EV signature to confirm the package is legitimate.
-
Then it checks Microsoft’s WHQL signature to see that it was officially approved.
5️⃣ If everything checks out, Windows installs the driver silently — no scary pop-ups, no red flags, no “untrusted publisher” errors.
What Happens if You Skip EV or WHQL?
Some developers think they can cut corners by signing drivers with a standard OV certificate or skipping WHQL altogether. This almost always backfires.
Starting with Windows 10 Anniversary Update and Windows 11:
-
Kernel-mode drivers must be submitted to Microsoft for signing through the WHQL process.
-
Your EV signature is required to submit the driver in the first place.
-
If you skip WHQL, your driver won’t load by default. On modern 64-bit Windows, users can’t just “click to install” unsigned or improperly signed drivers. They’d have to disable driver signature enforcement — a risky step that very few users or IT admins will allow.
So practically speaking, if you want your driver to install cleanly, get loaded by the OS, and gain trust with users, you need both:
✅ DigiCert EV Code Signing Certificate for your signature.
✅ WHQL Signing to get Microsoft’s official blessing.
Does WHQL Cover All Versions of Windows?
This is another point of confusion. When your driver passes WHQL and gets Microsoft’s signature, it means:
-
Your driver is trusted on all supported Windows versions that use that driver model (like Windows 10, Windows 11, Windows Server).
-
The driver can be published via Windows Update, so your hardware works out of the box for end-users.
So yes — WHQL + EV covers you for modern Windows platforms and makes distribution far simpler.
Steps to Get WHQL with DigiCert EV Code Signing
Here’s what the process typically looks like:
1️⃣ Buy a DigiCert EV Code Signing Certificate — DigiCert is a trusted root CA with a strong reputation for developer trust.
2️⃣ Complete DigiCert’s strict identity verification process.
-
For EV, you’ll receive a physical USB token to store your private key securely.
3️⃣ Sign your driver package files (.sys, .inf, .cat) with your EV certificate.
-
Use Microsoft’s SignTool with
/trfor timestamping so your signature stays valid even after the cert expires.
4️⃣ Create a Hardware Developer account on Microsoft’s Windows Hardware Developer Center Dashboard.
5️⃣ Upload your signed driver package for WHQL testing.
6️⃣ If your driver passes the tests, Microsoft signs it and sends you the signed package or publishes it via Windows Update.
Key Takeaway
The main thing to remember is that EV and WHQL work together, not separately. You need both to sign drivers the right way:
-
EV Code Signing proves your identity.
-
WHQL Signing proves your driver’s technical quality and compatibility.
Together, they keep Windows secure, protect your users, and help your drivers install smoothly — whether your customer is a casual home user or a major corporate IT department.
Conclusion
So, should you get a DigiCert EV Code Signing Certificate or rely only on WHQL?
You need both. There’s no “either/or” here — your EV certificate is your verified stamp that allows you to submit your driver for WHQL approval. Without it, you can’t even start.
If you’re building serious hardware, peripherals, or anything that requires kernel-level drivers, this is non-negotiable. Do it right the first time — protect your reputation, protect your users, and sleep well at night knowing your drivers won’t break Windows security.
