• Digital Signature Requirements
  
  
• Driver Management
  
  
• Adding Drivers
  
  
• Driver Ranking
  
  

Signed device drivers are a key security feature in Windows. Drivers installed on X64-based computers must have a digital signature. Although it is not required, we recommend that drivers be signed before they are installed on X86-based and Itanium-based computers.

All boot-critical drivers must contain embedded signatures. A digital signature is not required for Plug and Play (PnP) drivers. However, when an unsigned PnP driver is installed on a running operating system, Administrator credentials are required, and such drivers will not install on x64 operating systems.

There are two ways a driver can be signed.

• Kernel mode and boot-critical drivers are digitally signed by using a method called embedded signing. With embedded signatures every binary in the driver package is signed. Embedded signatures improve boot loading performance. For drivers that are not PnP, signatures should be embedded so that they are not lost during an operating system upgrade.
  
  
• Digitally signed PnP drivers contain a catalog (.cat) file that gets digitally signed. The catalog file contains a hash of all the files in the driver .inf file for installation purposes. A signed catalog file is all that is necessary to correctly install most PnP drivers.
  
  

Drivers can be signed by one of two sources:

• Windows Hardware Quality Labs (WHQL), which ensures that your drivers qualify for the Windows Logo Program. WHQL creates a signed driver catalog. For boot-critical drivers, you should add additional embedded signatures rather than relying on the catalog. Embedded signatures in boot-critical driver image files optimize operating system boot performance by eliminating the need to locate the appropriate catalog file when the operating system loader verifies the driver signature.
  
  
• Certification Authority (CA), by using a Software Publishing Certificate (SPC). For boot-critical and x64 kernel drivers, Microsoft provides an additional certificate that can be used to cross-sign the drivers. Non-boot-critical drivers do not need to be cross-signed by Microsoft or embedded. You can use the Windows Kernel Mode Code Signing process if you need the flexibility of signing the drivers yourself. For information about digital signatures for kernel modules on x64-based systems, see this Microsoft Web site.
  
  

For testing purposes, you can also use test certificates.

If you have received a driver from a vendor for testing purposes that is not yet signed, you can use a test signature to validate the driver and to test the installation. Test signing is the act of digitally signing an application with a private key and corresponding code-signing certificate that is trusted only within the confines of a test environment.

There are two primary ways to generate such test-signing certificates:

• Developers can generate their own self-signed certificates.
  
  
• Certificates can be issued by a CA.
  
  

For either option, test-signing certificates must be clearly identified as appropriate only for testing purposes. For example, the word "test" can be included in the certificate subject name, and additional legal disclaimers can also be included in the certificate. Production certificates that are issued by commercial CAs must be reserved for signing only public beta releases and public final releases of software and internal line-of-business software.

For additional information, see this Microsoft Web site.

When adding test-signed driver packages to Windows, consider the following:

• The test certificates must be installed on a running operating system. They cannot be installed offline.
  
  
• The certificate of the CA that issued the test certificate must be inserted in the Trusted Root Certification Authority Certificate Store.
  
  

  	Note:
  	If the test certificate is self-signed—for example, by using the Certificate Creation Tool MakeCert—the test certificate must be inserted in the Trusted Root Certification Authority Certificate Store.

• The test certificate that is used to sign the driver package must be inserted in the Trusted Publishers Certificate Store.
  
  
• Test certificates must be added online (to a booted instance of the Windows image) before you can use the Deployment Image Servicing and Management (DISM) command-line tool to add test-signed drivers offline.
  
  
• DISM will validate WHQL certifications only for boot-critical drivers. However, there is a DISM command-line option to override this behavior. For more information, see Driver Servicing Command-Line Options.
  
  
• To install and verify test-signed drivers on 64-bit operating systems, Windows boot configuration must be set to test mode (by using BCDEdit on the target computer). Test mode verifies that the driver image is signed, but certificate path validation does not require the issuer to be configured as a trusted root authority. However, to ensure that the driver is treated correctly by the PnP driver installation and ranking logic, the test certificate must be stored in the trusted certificate store of the operating system image. For information about test mode during development, see this Microsoft Web site.
  
  

Caution:

If an unsigned or invalid boot-critical device driver is installed on an x64 computer, the computer will not boot. The unsigned or invalid boot-critical device driver will cause a Stop error. You should remove the driver from either the critical device database (CDDB) or its reflected location in the image. If you are performing an upgrade, unsigned drivers and their associated applications, services, or devices must be removed or updated with a signed driver. If you do not enable test mode by using BCDEdit, and you have a test-signed driver installed, your computer will not boot. If you use DISM to remove the driver, all instances of the reflected driver package might not be removed. Therefore, we recommend that you do not deploy images that have test-signed drivers installed.

If you are adding multiple drivers, you should create separate folders for each driver or driver category. This ensures that there are no conflicts when adding drivers with the same file name. After the driver is installed on the operating system, it is renamed to Oem*.inf to ensure unique file names in the operating system. For example, the staged drivers named MyDriver1.inf and MyDriver2.inf are renamed Oem0.inf and Oem1.inf after they are installed.

When you specify a device-driver path in an answer file, all .inf drivers in the specified directory and subdirectories are added to the driver store of the Windows image. For example, if you want to have all of the drivers in the C:\MyDrivers\Networking, C:\MyDrivers\Video, and C:\MyDrivers\Audio directories available in your Windows image, specify the device-driver path, C:\MyDrivers in your answer file. If you are not using an answer file, you can use the /recurse command in DISM. For more information about the /recurse command, see Driver Servicing Command-Line Options. This ensures that all drivers in each of the subdirectories will be added to the driver store in your Windows image.

If all drivers in the specified directory and subdirectories are added to the image, you should manage the answer file or your DISM commands and these directories carefully to address concerns about increasing the size of the image with unnecessary driver packages.

If it is not practical to manage your driver shares so that only the required drivers are added to your image, you can add non-boot-critical drivers online by calling the Driver Package Installer (DPInst). DPInst will selectively install non-boot-critical drivers only if the hardware is present or if the driver package is a better match for the device.

You can add device drivers to a Windows image at various phases of deployment. They can be added offline to an operating system image before deployment, during an automated deployment of the Windows image by using an unattended answer file (Unattend.xml) and Windows Setup, or after deployment on a running operating system. For more information, see Understanding Servicing Strategies.

When a driver is added to an offline image, it is either staged or reflected in the image.

• Non-boot-critical drivers are staged. In other words, they are added to the driver store of the offline image. When the computer is started, PnP will detect the driver and complete the installation.
  
  
• Boot-critical drivers are reflected on the system. In other words, the critical device database (CDDB) and the registry will be changed, and files will be copied to the system according to what is specified in the .inf file.
  
  

Offline (Before Deployment)

Using Windows Setup and an Answer File

On a Running Operating System

One of the most common issues in deploying drivers occurs when a driver is successfully imported into the driver store but, after the system is online, PnP finds a higher-ranking driver and installs that driver instead.

The Windows PnP manager ranks the following driver package properties in order of importance:

1. Signing
   
   
2. PnP ID match
   
   
3. Driver date
   
   
4. Driver version
   
   

For example, if a device has a better PnP ID match but is unsigned, a signed driver with a compatible ID match takes precedence. In addition, a newer driver can be outranked by an older driver if the older driver has a better PnP ID match or signature.

For information about driver ranking, see this Microsoft Web site.

The following Web sites provide more information about device-driver requirements:

• For more information about PnP driver deployment, see this Microsoft Web site.
  
  
• For information about digital signatures and developing drivers, see the relevant page on the Windows Hardware Developer Central Web site.
  
  

Add and Remove Drivers Offline

Add Device Drivers by Using Windows Setup

Add a Driver Online in Audit Mode