Driver Signing changes in Windows 10

NOTE: These driver signing changes correspond to the initial Windows 10 release. For driver signing changes in Windows 10, version 1607, see this post.

Beginning with the release of Windows 10, all new Windows 10 kernel mode drivers must be submitted to and digitally signed by the Windows Hardware Developer Center Dashboard portal.  Windows 10 will not load new kernel mode drivers which are not signed by the portal.

Additionally, starting 90 days after the release of Windows 10, the portal will only accept driver submissions, including both kernel and user mode driver submissions, that have a valid Extended Validation (“EV”) Code Signing Certificate.

We’re making these changes to help make Windows more secure.  These changes limit the risk of a driver publisher’s signing keys being lost or stolen and also ensures that driver publishers are strongly authenticated.

If you are a driver developer, here is what you need to do:

  1. Ensure that you submit new drivers to Microsoft via the Windows Hardware Developer Center Dashboard portal.
  2. Get started with the process of getting an EV Code Signing Certificate.


What about existing drivers?  Do I need to re-sign these drivers to get them to work with Windows 10?
No, existing drivers do not need to be re-signed.  To ensure backwards compatibility, drivers which are properly signed by a valid cross-signing certificate that was issued before the release of Windows 10 will continue to pass signing checks on Windows 10.

What about older versions of Windows?
The changes described in this post apply only to Windows 10, so cross-signing can continue to be used on previous versions of Windows.  However, the Windows Hardware Developer Center Dashboard portal will require an EV Code Signing Certificate no matter what OS you plan to support.

How to sign drivers during development and testing?
Please see this page for information on how to test sign.

How do I sign a driver so that it is compatible with Vista, Windows 7, Windows 8, Windows 8.1, and Windows 10?
Simple.  All you need to do is run the HLK tests for Windows 10, and run the HCK tests for Windows 8.1 and earlier versions as you have in the past. Then, submit your driver and the merged HLK/HCK test results to the Windows Hardware Developer Center Dashboard portal.  The portal will sign the driver the right way so that it will work on all platforms that you indicate the driver is applicable for.

Are there web services for submitting to the
Windows Hardware Developer Center Dashboard portal?
Yes.  Take a look at this and this.

Comments (47)

  1. Arpo Adhikari says:


    Just to confirm one thing.

    While not  having "EV Code Signing Certificate" we can submit drivers for signing for Win 10 within the 90 days grace period after the release of Win 10.  

    So, the device drivers certified / signed during that 90 days grace period,  will it be valid for Win 10 after the 90 days grace period ? Pleas confirm.


  2. Tania says:


    Just to confirm:  The file that needs to have the EV signature is the .hckx file (or whatever the new extension is in the Win10 WHQL test kit), right?

    We've always had to sign that one when we select "Create Package" in the WHQL test kit.  What you're saying is that it will now need to be signed with the EV cert instead, right?


  3. Mathiu Silverberg says:

    Let's see the cost that we can find for these "EV Code Signing Certificate", for 3 years: $950, $995, and… yes, $1549.

    Without speaking of the fact that we are forced to first buy a Symantec certificate (and nothing else!) to register a company account…

    So, here is my question: what about developers of free software? These amounts are not a problem for a company that sells hardware. But for an independent developer who sells nothing, this is often prohibitive. So what are the possibilities?

    There is a common case where a driver is required even for a simple software: each time a volume is required for managing data. E.g.: encryption software, image file mounting tool, ramdisk…

    And as long as you will not provide an API for that, a driver will remain required.

  4. L. says:

    Mathiu Silverberg is spot on.  With this move, you are killing any kind of freelance development that involves extending the Windows kernel (low level disk tools, VPNs, filesystems, etc).  The previous signing requirements were bad enough, these new ones are prohibitively expensive.

    Considering the publication date, I had hoped that it was some kind of April Fools' joke.  Unfortunately, it seems that it is not.

  5. Steve Bayless says:

    Will all driver's submitted to the  Windows Hardware Developer Center Dashboard portal require a full passing HCK submission to be signed?   Or is it possible to have a driver signed through the portal without the HCK tests being run on the driver?

  6. Don Burn says:

    Steve, the presentations on the signing indicate the rules are the same as present, the procedure of how to sign is what has changed.

    I do wish the Microsoft would move most of the materials out from behind the Windows Hardware Developer Center Dashboard.   Years ago, I was able to convince most of my customers to design their hardware so that it was likely to meet Windows requirements.  Now with much of the material that was publicly available behind the portal, most of the customers say "You are kidding me, I need a cert just to see Microsoft information, forget it!!!"   I suspect it will become even more common to hear this with the EV Certs.

  7. dstevens says:

    Not 100% related, but I'm hoping this finds it way to correct group as I can't find any other HCK contact method, and I don't want to pay for tech support to report a bug.

    There is a bug in the HCK which makes it impossible to pass the usb IF validation test.

    The test to validate USB30CV Tool log files has a bug.  The test uses USBIFValidation.exe to parse the .html log files output from the USB30CV Tool.  USBIFValidation.exe fails with the error 'Unexpected log type, or malformed log'.  

    It took two days to work this out, but the problem is that USBIFValidation.exe looks specifically for a string 'Chapter 9 Tests [USB 2.0 devices].cvtests' in the log files.  The USB30CV Tool produces log files with a string 'Chapter 9 Tests [USB 2 devices].cvtests'.  Editing the string from 2 to 2.0 fixes the problem.  To be fair, it is likely that the USB-IF changed the tool to cause the bug.

    May I suggest a regular expression match?

  8. paul_Reed55 says:

    Hi Arpo,

    Yes, those driver will be valid for Windows 10.

  9. paul_Reed55 says:

    HI Tania,

    Yes, that is correct.

  10. paul_Reed55 says:

    Hi Dstevens,

    The appropriate channel for technical support questions is via Microsoft support.  You can also try posting your question in the forum I have linked to down below.…/home

  11. paul_Reed55 says:

    Hi Steve

    With the release of Windows 10, we are enabling a new driver signing service for Windows 10 Desktop.  This new service does not require HLK test logs.  However products that are submitted using the new driver signing service will not appear on the certified products list.

  12. Rachel says:

    Just to confirm several things :

    1. When we submit .hckx file (submission), Is 'EV code siging certificates' required?

      We saw that when we want submissions(including HCK/Download Signatures), Standard Code signing certificate is ok as well. right?

      Link here :…/hh801887.aspx

    2. If we want to validate the driver on all OS(XP~10), What sholud we do?

    3. No signature driver was loaded in Technical Preview version(Build 10049).

      So, driver having no signature, can be loaded in formal version?

    4. How can we inquire the more detailed information? Where can we contact?

  13. Gobind says:

    How about Server driver submissions ?

  14. vparthas says:

    I see that the new driver signing page went live a few days back. Is there any more information available on this? Something from the BUILD conference?

  15. paul_Reed55 says:

    Hi Gobind,

    Yes, the EV certificate policy applies to all driver submissions, including server.  

  16. Evelyn says:


       I have reviewed the "Dashboard submission REST API reference" and "Driver Signing" , but I can't found about use REST API to submit a driver for signing.

       Could I use API to create driver signing submission?

       Link please refer below:

         Dashboard submission REST API reference:


          Driver Signing :


       Thank you!

  17. zwang94 says:

    Does this apply to the legacy driver which does not normally go through WHQL process? The legacy driver is not associated with any device and may not have an INF file.


  18. Jeff says:

    You say that to sign a driver that's compatible with all versions Vista through to 10, "all you need to do is submit your drivers to the Windows Hardware Developer Center Dashboard portal. The portal will sign the driver the right way so that it will work on all platforms that you indicate the driver is applicable for." However, on the submission page, the only platforms available to be selected are "Microsoft Windows 10 Client Family x86" and "Microsoft Windows 10 Client Family x64". Will this still work on earlier versions with just these selected?

    Also, it allows me to select both x86 and x64, but on the Driver Signing help page it says, "Driver Signing supports only one architecture per submission. All driver folders in your cab must support the same set of architectures, for example, all drivers are x86." Which is correct?

  19. Alex says:


    to revisit the topic from Rachel question 2. "If we want to validate the driver on all OS(XP~10), What sholud we do?"

    At the moment we merge the .hckx packages on all OS and than sign the merged packages. Should we now merge all packeges with HLK (including the .hlkx package [Win10]) and sign with the new EV Signature?


  20. Pino says:

    DigiCert appears to be less expensive. But if you find the cost of an EV code signing certificate prohibitive, you could always refrain from shipping drivers for Windows and instead ship drivers for GNU/Linux.

  21. Jyrki says:

    Submission with non-EV signed stuff gives:

    "The digital certificate is not from Symantec Inc. Only Symantec class 3 certificate is accepted."

    Documentation mentions Symantec and DigiCert:…/hh801887.aspx

    Please clarify: EV certs from other cert authorities, are they ok?

  22. Maxim Masiutin says:

    We are using a Thawte SHA-256 code signing certificates. The current owner of Thawte is Symantec. I've signed WinQual.exe with that certificate but gave me an error "The digital certificate is not from Symantec Inc. Only Symantec class 3 certificate is accepted". Could you please fix this, to allow Thawte code signing certificates also work? We develop a regular application (MSI package of .EXE and data), not a driver.

  23. vparthas says:

    I'm trying to use the API at, as documented here…/dn800659.aspx, but the page does not exist. Is there a different URL I should be using?

    Windows 10 is releasing in less than 2 weeks and there are still so many open questions regarding driver signing. Not very helpful!

  24. David Grayson says:

    Where exactly is the portal?  The portal links in this blog post goes to a page that does not contain the word "portal"?  Also, could you answer the other questions people have been asking, such as whether EV certs from other certificate authorities are OK?

  25. M2050 says:

    I understand the procedure of manually signing windows 10 driver but is there any way I can automate this process. In the current build setup, we sign the drivers on all OS everyday with nightly builds as we don't need to submit anything to microsoft to get the digital signature. How do I get the same results for signing windows 10 drivers. Does anybody knows how to achieve this ??

  26. Mumak says:

    It seems this whole stuff is not yet finished by MS and the lack of documentation and support is really alarming!

    We have tried to sign a driver on the portal with a new EV cert, but the validation process failed without giving and exact reason why (step 5/10) ! Our drivers are SYS only (we don't need nor ship any INF/CAT files), so I'm not sure how to have them properly signed on the portal. Some sources say that the package needs to contain SYS, CAT, INF and PDB (!) files too. Is this really required?! What kind of validation is performed?

    MS – you need to give us more information. W10 is already out and we are still not sure how to proceed, even though there's probably a grace period, but we also need to pay a significant amount for the new certs.

  27. B says:

    Everyone should carefully read this part: "To ensure backwards compatibility, drivers which are properly signed by a valid cross-signing certificate that was issued before the release of Windows 10 will continue to pass signing checks on Windows 10."

    This essentially means that the old method of cross-signing will likely continue to work for many years to come, depending on your CA. The cross-signing certificate provided by mine will only expire in 2021. Again, this is unrelated to the time of the actual signing, so even new drivers signed post Win10 release using the conventional method will still be loadable.

    So it appears at this point there is no reason to panic.

  28. Andreas M says:

    Like M2050, I would also like to know if it will be possible to automate the signing process? Otherwise it will be very disruptive to our fully automated one-step build process!

  29. Tibor P says:

    Everything is clear, I'm afraid

    The beautiful white clouds on the sky -> "We’re making these changes to help make Windows more secure."

    and the simple real life ->"Let's see the cost that we can find for these "EV Code Signing Certificate", for 3 years: $950, $995, and… yes, $1549."

  30. Peter says:

    I wonder how many exploits have been found in the past, that were caused by "somehow unsecure signed kernel mode drivers" and how many were based on hasty network implementations issued by Microsoft. Haha, what a joke.

  31. Vince says:

    " To ensure backwards compatibility, drivers which are properly signed by a valid cross-signing certificate that was issued before the release of Windows 10 will continue to pass signing checks on Windows 10."

    That's not what I obtained on Windows10 with SecureBoot activated : all the drivers cross-signed before 29/07 are trusted/allowed. All the drivers signed after 29/07 are not trusted (kind of BSOD).

  32. Vince says:

    And if you want that the driver signed by Microsoft works fine on Windows 7 SP1, you MUST have the KB3033929 to support SHA256 :…/3033929

  33. Michael says:


    I’m using an old method of cross-signing and my certificate will expire in 2017,

    Are new drivers signed post Win10 release (29/07) using my certificate will still be loadable/trusted?


  34. B says:

    Yes Michael, the signing time has no impact. I have verified this myself.

    Also, I need to correct myself: What I stated above is wrong. Your own actual certificate matters, not the public cross-certificate. Microsoft just expressed this in a very confusing way IMO (with "cross-signing certificate" they simply refer to the original driver signing process that uses cross-certificates).

  35. JS says:


    I just switched to windows 10. How can I set testsigning on? I cant seem to figure it out from microsofts page.

    Thanks in advance..

  36. Cere says:


    There was a new post from Japan WDK Support Blog:…/windows-10-sha-1.aspx

    All the drivers signed before 29/07 are trusted. Also, all the drivers signed by a valid authenticode certificate that was issued before 29/07 are trusted. but, all the drivers signed by a valid authenticode certificate that was issued after 29/07 are not trusted !

    However, this process is not being applied at the moment, it will be applied in future windows update.

  37. Steve says:

    What about File System Filter Drivers… do these need to be EV signed, since they are not hardware specific or have anything to do with browsers?

  38. Manoj says:

    We have Global signed kernel driver which works fine in win7/8.1. But In Windows 10 when we uninstall the driver or install the driver, during restart it goes to recovery mode. If we disable Signature verification during boot time, we do not see the issues. We have also checked Code Integrity policy and disabled it, but the issue persists. This issue is happening only on win10 64 bit. Any clue? anybody has faced this issues.

  39. Mumak says:

    The date of this article (1 Apr) absolutely justifies the confusion this brings to developers !

    Today is Oct-28 and the 90-day grace period for accepting non-EV certs should be expired, but for what ??!!

    Thank you MS for creating such a mess and not providing detailed information !

  40. Kashif says:

    Can anyone confirm which date is being referred to in the statements which describe how existing drivers will function, such as: "drivers which are properly signed by a valid cross-signing certificate that was issued before the release of Windows 10 will continue to pass signing checks on Windows 10"

    Does this refer to the issue date of the Cross-Signing certificate which we downloaded from Microsoft's website? Or does this refer to the issue date of the certificate issued to be us by our 3rd party Certificate Authority?

  41. B says:

    Kashif, definitely the latter, otherwise in my case I could still cross-sign for Windows 10 for another 6 years – that makes no sense.

    I can confirm what Cere said though, the post-RTM cutoff policy is not being enforced yet – I just tested loading a driver signed by a newly issued non-EV cert.

  42. David Grayson says:

    I would like to see Microsoft issue an official answer to Kashif's question.

    To the user posting comments as "B": These rules from Microsoft are arbitrary and it's easy for them to defy what you would consider common sense.  The results of your recent test and the precise wording of this document should count as much stronger evidence for the opposing viewpoint.

  43. B says:

    David, I agree, but check Cere's post. Apparently on a Japanese blog someone from MS confirmed that the policy is not being enforced yet.

  44. Roger says:

    .. and how about virtual drivers privede with a bundled software package (file system or network filter) ?


    cibonk cubunk,chacha chichi,piring pendaringan,nusa dan bangsa satu untuk selamanya bray,,,.

  46. Tim Kelly says:

    Ok, I have an issue.  I had my certificate (cross sign Globalsign) reissued on 11/2015 for another two years and signed my kernel driver as I have been and everything worked fine.  Then we released our software and customers starting calling as systems crashed.  However, I could not reproduce it, as it only happens randomly.

    Finally, I narrowed it down.  On Build 10240 which Dell uses (new out of the box PC's) crashe when we install our Kernel driver.  It will not reboot.  If we turn off signed drivers then Windows 10 boots.  I CANNOT reproduce this on my 10240 ISO I have in VM.

    Now here is the strange part.  If I tell Windows 10, on these Dell's to do Windows update they update to Build 10586 and the problem goes away.  I am assuming it is because MS originally released requiring EV signed drivers and then changed that behavior requirement.

    Can some confirm this and if so how do I detect which versions of Windows 10 will not work?

    Also, does anyone know how long this will be?  Signing Kernel drivers with a EV signature seems to impact rapid development.  In the past, we would compile then sign and test hundreds of time each day.  If I now have to have MS in the loop what's the solution?  Seems like booting each time to turn off signed drivers is a hassle.

    Lastly, we have multiple locations which would just sign their drivers themselves with a copy of the company certificate (and some automated server scripts).  No the EV signing seems to on available if you have a USB 'dongle' and turn around time can be hours.  So what am I missing?



Skip to main content