Windows 10 Version 1607 (aka Anniversary Update) is now enforcing the tightened kernel driver certification which was already announced 2015 as a requirement for Windows 10. The new rule is that all Windows 10 drivers must be digitally signed by Microsoft, no more cross signing! Kernel driver developers must now use an Extended Validation (EV) code signing certificate and submit their drivers to the Windows Hardware Developer Center Dashboard Portal where the drivers will be signed by Microsoft after passing certain tests.

However, there are exceptions to that rule. Cross-signed kernel drivers are still accepted by Windows 10 version 1607 if any of the following is true:

  • The driver is signed with a certificate that was issued before 29th of July 2015
  • The driver is a boot up driver
  • Secure Boot is Off
  • The Windows 10 version 1607 System was upgraded and not directly installed
  • A secret registry key is set that allows cross-signed drivers to load even on systems with Secure Boot enabled

In my company we do have the issue that several drivers are now disabled on systems that received a clean Windows 10 version 1607 installation, and even certain Intel drivers are affected. In addition, highly secured KVM virtual machines that use the TianoCore UEFI BIOS with secure boot enabled now don't load the VirtIO network and balloon drivers because of digital signature errors.

And I can confirm that the drivers work fine on systems with secure boot disabled and on Windows 10 systems that were upgraded (in-place) to version 1607, even with secure boot enabled.

Now I'm wondering what the name and value of that secret registry is that was announced by Microsoft in the following video at 00 h 11 m 00 s:

Channel 9 - Plugfest28 - Driver-Certification-on-Windows-Client-and-Server

... and then finally we are actually going to have a registry key ... and this registry key is ... you know ... intended just for testing so we definitely don't want you to ... setting this registry key as you install the driver and ... the registry key essentially mimics the same behavior as if you have an upgraded system ...

That key was never announced by Microsoft and because of the following message in OSR's ntdev list I believe this will never happen:

I hate to say this, but since you asked: The registry key information is only available under NDA. Which means it'll probably turn-up in lots of places online eventually, but until that time WE WILL NOT be discussing it here.

And this leaves me at my actual Super User question:

What is that secret registry key that tells Windows 10 version 1607 that it was upgraded from a previous version?

  • If I were to hazard to guess. The same key that has always been used when you upgrade from a previous version of Windows to a newer version of Windows.
    – Ramhound
    Aug 15, 2016 at 12:45
  • 1
    @Ramhound ... which would be ?
    – gollum
    Aug 15, 2016 at 12:46
  • Any hint of who is using that key? Its existence suggests it is given to outside parties for use in certain situations. If that's true, wouldn't it make sense to approach Microsoft to ask to be one included among them?
    – user939
    Aug 15, 2016 at 14:56
  • @Will Microsoft is using that key in order to not apply the stricter driver signing policy on Windows 10 systems which have performed the in-place anniversary update (they don't want to disable systems that have been working before the update). On the other hand the existence of this key might be considered a security risk because it can nuke the stricter policy which people might want to have in place eventually.
    – gollum
    Aug 15, 2016 at 17:42
  • Have you tried this one? [HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows NT\Driver Signing] Change the BehaviorOnFailedVerify key value to "0".
    – HackSlash
    Apr 19, 2018 at 20:19

2 Answers 2


Both the blogpost and the forum post corroborate each other. I have added the following registry value on a Windows 10 version 1909 machine that had been upgraded from 1903 (therefore, the restrictions from 1607 apply).

Lo and behold...it worked. Previously, the driver had installed itself and appeared in the Device Manager, albeit with the oft-described "Code 52" warning. Now that error is gone.

I'm a Linux user and not a Windows guru. My previous (naïve) experiences have shown me that modifying the registry can lead to issues, so I don't really know what sort of externalities will follow from adding this registry value. I'll defer instead to Geoff Chappell's blogpost, as he seems to know what he's writing about; it seems like adding this registry value is, at least to date, harmless.


you can try the TESTSIGNING Boot Configuration Option

Bcdedit.exe -set TESTSIGNING ON

Make sure to disable the Secure Boot and boot to OS to execute bcedit commands, once done you can reboot to OS with secure boot enabled

The TESTSIGNING boot configuration option determines whether Windows Vista and later versions of Windows will load any type of test-signed kernel-mode code. This option is not set by default, which means test-signed kernel-mode drivers will not load by default on 64-bit versions of Windows Vista and later versions of Windows.

Note After you change the TESTSIGNING boot configuration option, restart the computer for the change to take effect.

  • Testsigning mode is not an option since the kernel would load drivers that are signed by any certificate and the validation is not required to chain up to a trusted root certification authority. Basically the question is about making a freshly installed system behave like an upgraded system with regard to the driver signature validation policy.
    – gollum
    Sep 19, 2018 at 10:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .