Windows 10 & system drivers

Background of the problem

With the Windows 10, Microsoft has set-up stricter rules for verifying the suitability during the installation of Windows drivers. Unfortunately, due to the step-by-step implementation of this requirement and sometimes inconsistent with the published information, different behaviors can be observed for identical computer with the same (at least at first sight) configured system. The information presented below aims in a very simplified form to clarify the related issues, to mention the most common unexpected behavior of the system and to describe the solution.

A few words from history until the release of Windows 10
(i.e. Windows 8.1 or Windows Server 2012 R2 and earlier)

Kernel mode software (e.g. system drivers installed in the kernel of the system) required so-called "signing" since Windows XP, maybe even older - a certificate identifying the driver's publisher was inserted into the driver files (SYS, DLL, etc.). Requirements of Windows during installation completely unsigned drivers, or only signed by the publisher's identity (i.e. drivers which never attended WHQL testing), differs depending on Windows versions, as well as their settings. In general, it is not possible to install unsigned drivers in 64-bit versions of Windows, but 32-bit versions of Windows just made installation uncomfortable by alert notifications.

Significant change occurred with the Windows 10,

when Microsoft decided that drivers must be signed with an Extended Validation Certificate (EV) and subsequently co-signed with Microsoft Windows Hardware Developer Center Dashboard portal.

This information was published by Microsoft in a press release as early as April 1, 2015, subsequently confirmed on August 29, 2015, when Windows 10 was released (version 10240) and set a limited time of 90 days to make changes.

With the release of Windows 10 on July 29 2015, Microsoft has taken steps to ensure this is the most secure Windows platform it has launched to date. For driver developers this means all new Kernel and User Mode driver submission requirements will change 90 days after the Windows 10 launch.
On October 27, 2015, all new Kernel and User Mode driver submissions will need to be made via the Windows Hardware Developer Center Dashboard portal and signed by an Extended Validation (EV) code signing certificate. The EV code signing certificate requirement is to ensure that publisher private signing keys are stored securely on hardware tokens and organizations undergo a comprehensive and thorough authentication process. These EV code signing features increase the integrity of software assets that run on Windows 10 Operating System.

However, this strict limitation by Microsoft at the end of October did not occur, and not even after the first major update in November 2015 (Threshold 2, version 1511); Windows 10 accepted drivers signed without an EV certificate until July 2016.

With the coming of the second major update in July 2016 (Windows 10 Anniversary update, Redstone 1, version 1607), Microsoft defined the new rules as follows:

On 2016-07-26, Microsoft announced that this rule will only be enforced on Windows 10 systems that were freshly installed at build 1607 or later, with Secure Boot on.

The stricter signing rules are therefore mandatory only for systems that were installed from Windows 10 version 1607, and with active Secure Boot mode. Systems originally installed from earlier versions of Windows, even if they are updated regularly, do not require stricter signing rules.
I fact, the conditions described above are valid today (October 2017) and can not be relied upon any change in any further updates.

So what does the status described in the previous paragraphs allows?

You can run two identical computers with regularly updated Windows 10, no significant difference will be visible, and yet apply different rules to verify the suitability of the drivers.
You can use a Windows 10 computer installed from version 1607 with non-active Secure Boot mode and drivers without EV certificates.
However, when the Secure Boot mode is turned on, these devices will be deactivated and marked as incorrectly installed in the device manager. Subsequently, ot will be necessary to update the driver in the device manager, or turn off again Secure Boot mode.

What is the current status of TEDIA drivers (October 2017)

All TEDIA drivers are compliant with the new Windows 10 requirements.

Since drivers co-signed with Microsoft Windows Hardware Developer Center Dashboard portal are not compatible with Windows 8.1 and older, the same drivers signed in a traditional way are available in the Windows 7/8 package.

Note: In conclusion, the status Windows Server 2016 drivers should be mentioned; Microsoft set up on this system even more significant limitations than Windows 10, and only drivers that passed WHQL testing can be installed.

Finally, a few images for clarification

A warning that Windows expresses "dissatisfaction" with an unsigned driver. The same alert is displayed even if the signature was not recognized.

Information about certificates, respectively publisher's signatures can be easily found among file properties, just right-click on the driver file (SYS or DLL) and choose Properties => Digital Signatures. The picture below shows the file properties with only two TEDIA signatures. This driver cannot be compliant with the new Windows 10 requirements.

However, the following picture shows the file properties with two TEDIA signatures and one Microsoft signature, this driver can be (but may not) compliant with new requirements.

Windows 10, Device Manager - deactivated device when Secure Boot is turned on (i.e. it was fully operational before turning on Secure Boot).
The deactivated device (see the detailed image, indicated in red) remains in the same location as before Secure Boot was turned on, the rejection of the already installed driver is indicated by the yellow triangle. In the case of the first installation the device will be located in the yellow highlighted section "Other Devices", not in the USB controller class.