Driver certificates and signatures in Windows: a complete guide

In Windows, the controllers and their digital signatures They have become a key component of system security. Beyond simply enabling a printer, graphics card, or smart card to function, what's important today is that the system can verify that the software is genuine, has integrity, and comes from a trustworthy vendor.

If you have ever come across messages like “Windows cannot verify the publisher of this driver software” Or errors related to certificates when installing a driver—you know how frustrating that can be. In this article, we'll calmly break down how driver signing works in Windows (both in kernel and user mode), what requirements change depending on the Windows version, how to sign your own drivers, and what options you have to safely disable signature verification when you have no other choice.

What is driver signing in Windows and why is it so important?

The call driver signature This simply involves associating a digital signature (based on certificates) with a driver package. This signature is usually applied to the package's catalog file (.CAT) or directly to the driver binaries (.SYS, .DLL, etc.) using embedded signature techniques.

During device installation, Windows uses these digital signatures for two key thingsThe system checks that the package has not been modified since it was signed (integrity) and confirms the identity of the software vendor (driver publisher). If anything is amiss, a warning is displayed, or in stricter scenarios, the installation or loading of the driver is blocked.

In the 64-bit versions of Windows Vista and later, Microsoft introduced a fairly clear policy: All kernel-mode drivers must be signed to be able to load, with very few exceptions. This puts drivers in the same security category as the rest of the system binaries, because a kernel-level failure can completely compromise the system.

The rules have been getting stricter with ThereStarting with Windows 10 version 1507, all drivers signed through the Development center of hardware Microsoft They are mandatory to sign with SHA-2. The old SHA-1 became obsolete for cryptographic security reasons, and Microsoft has been progressively removing it from the entire ecosystem.

There is an important detail: kernel-mode driver binaries signed with dual certificates (SHA-1 + SHA-2) issued by non-Microsoft entities may have problems in systems prior to Windows 10...or even cause crashes in Windows 10 and later versions. To prevent this, Microsoft released update KB3081436, which includes the correct file hashes and fixes loading behavior in these cases.

Overview of driver signing in Windows

To fully understand how all this works, it's helpful to separate the concepts. On one hand, there's the driver code signature (kernel mode or user mode) and, on the other hand, the signing requirements for Plug and Play (PnP) device installation. Although they go hand in hand, they are not exactly the same: you can have a driver that is correctly signed at the binary level, but that does not meet some additional installation requirement.

Microsoft has specific documentation on digital signatures for kernel modules in Windows Vista and later systemsThis document details which certificates are valid, how trust chains should be built, and which hash algorithms are supported (currently SHA-2). For drivers that transmit protected content (audio and video with DRM, PUMA, PAP, PVP-OPM, etc.), there are also special code signing requirements focused on protecting multimedia content.

Regarding the publishing flow, today there are several ways to Submit drivers to the Microsoft hardware portalFor production drivers, the standard approach is to run tests using HLK or the older HCK and upload both the binary and the test logs. For client-only scenarios on Windows 10, attestation signing can be used, which reduces the need for automated testing while maintaining validation and signing by Microsoft.

The option of test signature Designed for internal development and testing, where non-public certificates or certificates issued by a private PKI are used. These drivers will only load if the system is configured in test mode or with specific policies that allow test drivers.

Exceptions and cross-signed controllers

In intermediate versions of Windows 10, the so-called “controllers with cross-signature” Cross-signed drivers are still allowed under certain conditions. These are drivers signed by the vendor with an Authenticode certificate chained to an intermediate certificate signed by Microsoft, bypassing the full hardware portal workflow.

Microsoft maintains several exceptions to prevent already deployed systems from failing to boot. Cross-signed drivers are permitted in the following situations: The computer was upgraded from a previous version of Windows to Windows 10 version 1607; the Boot Secure Boot is disabled in the BIOS/UEFI; or the driver is signed with a certificate issued before July 29, 2015 that chains to a supported cross-signed CA.

To reduce the risk of rendering the system unusable, the boot controllers They are not blocked even if they don't comply with the new policies, but the Program Compatibility Assistant can flag them and suggest their removal or replacement. The idea is to avoid disrupting the boot sequence, but to gradually remove non-compliant drivers.

Windows version signing requirements

Signature requirements vary depending on the specific version of the operating system and whether the system uses Secure Boot. In general terms, the signing policy table for client editions can be summarized as follows:

• Windows Vista and Windows 7and also Windows 8+ with secure boot disabledIn 64-bit certificates, a signature is required, while in 32-bit certificates, a signature was not mandatory. The signature can be embedded in the file or in an associated catalog, and the required algorithm is SHA-2. The certificate chain must terminate in standard trusted roots for Code Integrity.
• Windows 8 and 8.1, and Windows 10 versions 1507 and 1511 with Secure Boot enabledBoth 32-bit and 64-bit drivers require signed drivers. Embedded or catalog signing is still permitted, using SHA-2, relying on standard roots for code integrity.
• Windows 10 versions 1607, 1703 and 1709 with Secure BootThe requirement is tightened, and signatures must be anchored to specific Microsoft root certificates (Microsoft Root Authority 2010, Microsoft Root Certificate Authority and Microsoft Root Authority).
• Windows 10 version 1803 and later with Secure Boot: the same signature requirements anchored to the aforementioned Microsoft root authorities are maintained, for both 32-bit and 64-bit systems.

Along with the driver code signature, the package must also comply with the signature requirements for installing PnP devicesThis means that the .INF files, catalogs, and binaries must be correctly linked and reflected in the signature for the device installer (and the Device administrator) consider them valid.

There are also special types of drivers such as ELAM (Early Launch Anti-Malware)which are loaded very early in the boot process to protect the system from malware low-level. These drivers have additional signing and certification requirements documented in the early boot antimalware guide.

Signing a driver for Windows 10, Windows 8.x and Windows 7

If you are a driver developer or work in an environment where custom drivers are distributed, you need to comply with the Windows Hardware Compatibility Program (WHCP) using the appropriate tools for each version: HLK for Windows 10 and HCK for earlier versions.

In the case of Windows 10, the typical flow would be: download the Hardware Lab Kit (HLK) For each version of Windows 10 you want to support, install the testing environment and run a full certification pass on a client running that version. Each run will generate a test log.

If you've tested the driver in several versions, you'll have multiple logs. This is typical. combine all the logs in a single report using the latest version of HLK. This combination simplifies submission to the hardware portal and allows a single firm to cover multiple system versions.

Once you have the registers, you send the controller binary and the combined HLK results to Windows Hardware Developers Center panelThere you choose the type of signature you want (for example, production, attestation, etc.), configure the properties of the shipment and wait for the automatic Microsoft process to generate the signed catalogs and return the already certified package to you.

A similar approach is followed for Windows 7, Windows 8, and Windows 8.1, but using the Hardware Certification Kit (HCK) appropriate for each version. Microsoft maintains a user guide for this kit that explains the testing, validation, and delivery workflow.

Driver signing for versions prior to Windows 10 version 1607

Before the arrival of Windows 10 version 1607, many types of drivers needed a Authentic certificate combined with a Microsoft cross-certification. This technique, known as cross-signing, allowed manufacturers to sign their drivers and have Windows accept them as if they were "blessed" by Microsoft's infrastructure.

Among the controllers that required this signature model were the kernel-mode device driversThese include user-mode drivers that interact closely with the kernel and the drivers used to play or process protected content (DRM-protected audio and video). The latter includes PUMA- or PAP-based audio drivers, as well as video drivers that manage output protection (PVP-OPM).

Code signing for protected multimedia components has its own guidelines, as the chain of trust and certificate extensions must ensure that protected content cannot be easily intercepted or manipulated.

Practical use of SignTool to sign drivers in kernel mode (Windows 7 and 8)

In practical terms, the leading tool for signing binaries in Windows is SignTool, included in the Windows SDK. For kernel-mode drivers in Windows 7 and 8, there are a number of options that are particularly useful when signing and verifying.

Among the most important parameters of SignTool are: /ac to add an additional certificate (such as the Microsoft cross-certificate)/f to indicate the file containing the signing certificate (for example, a .pfx), /p for the password of that PFX, /fd to specify the hash algorithm (for example, /fd sha256 to force SHA-256, since SHA-1 is the historical default).

The parameter is also fundamental /n «Common name of the certificate»This allows you to select the correct certificate from the Windows certificate store using its Common Name. To add timestamps, you can use /t with a classic Authenticode server or /tr with an RFC 3161 compliant server, which is the most modern and recommended option.

One possible workflow would be to gather the driver binaries in a working directory or even copy everything to the Windows SDK's bin folder. Then, the code signing certificate is acquired and, if necessary, the Microsoft cross-certification (for example, the CrossCert corresponding to the CA that issued your certificate). Both are placed in the same directory from which you will run SignTool.

With everything ready, the example command could be something like: signtool sign /ac CrossCert.crt /f CodeSign.pfx /p password1234 /fd sha256 /tr http://timestamp.globalsign.com/tsa/r6advanced1 filter.sysThis generates a modern signature with SHA-256, includes the cross-certification, and adds an RFC 3161 timestamp, which is essential for the signature to remain valid even after the certificate expires.

Once signed, it is recommended to verify with a command like signtool verify -v -kp filter.sysThe -v flag displays detailed information, while -kp checks the signature against kernel-mode driver criteria. If the output indicates that the signature is valid and the chain of trust ends in an accepted root, the driver is ready for deployment.

It's important to remember that, in many cases, the catalog file (.CAT) is also signed. The process is repeated: the .CAT file is signed, verified, and, once everything is in order, the driver is installed normally on the system.

Signature for attestation and creation of CAB packages

Microsoft offers the signature as attestation as a relatively lightweight way to distribute drivers, especially on Windows 10 client systems. The vendor is responsible for ensuring the driver meets the requirements, and Microsoft is limited to validating and signing, avoiding the full battery of HLK tests in some scenarios.

To send a controller by attestation, a CAB file which groups the essential components of the package. A typical CAB includes the binary driver itself (.SYS), the INF file (.INF) that Windows will use during installation, the debug symbols (.PDB) for fault analysis, and sometimes .CAT catalogs that Microsoft will use as a reference to check the structure (although it then generates its own catalogs for the final distribution).

Creating it is simple: all the files to be signed are gathered in a single directory, for example C:\Echo. From a window of commands With administrator privileges, the MakeCab help is consulted to see its options and a DDF file is prepared with the necessary directives indicating which files will be compressed, which cabinet will be generated and in which subfolders they should be organized within the CAB.

For the Echo controller example, the DDF file could set the output name to Echo.cab, enable MSZIP compression, and define a destination directory (DestinationDir=Echo) so that there are no loose files in the root directory of the cab. Then, the full paths to Echo.inf and Echo.sys are listed so that MakeCab includes them.

With the DDF ready, you run something like this: MakeCab /f Echo.ddfThe tool will show how many files it has included, the compression level achieved, and in which folder (usually Disk1) it has placed the resulting CAB file. Simply open the Echo.cab file with File Explorer to confirm that it contains everything expected.

Sign the CAB with an EV certificate and send it to the Partners Center

Before uploading the package to the Microsoft hardware portal, it is normal to sign the CAB with an EV (Extended Validation) certificateThese certificates, which are more stringent in validating the entity, provide added confidence and are often a requirement for certain types of signatures.

The process varies slightly depending on the EV certificate provider, but the general idea is to use SignTool again, this time targeting the CAB. A typical command might be: SignTool sign /s MY /n “Company Name” /fd sha256 /tr http://sha256timestamp.ws.symantec.com/sha256/timestamp /td sha256 /v C:\Echo\Disk1\Echo.cab, which adds a SHA-256 signature with SHA-256 timestamp to the cockpit.

After signing, you gain access to Microsoft Partner CenterSpecifically, go to the hardware panel and log in with your organization's credentials. From there, select the "Submit New Hardware" option, upload the signed CAB file, and fill in the submission properties: product name, type of signature required, whether you want a test signature or only a production signature, etc.

It is important Do not activate the test signature options If you are looking for a production driver, in the required signatures section you choose the variants you want to include in the package (for example, signatures for different versions of Windows or architectures).

Once the form is completed, click Submit and let the portal process the package. When Microsoft finishes signing the driver, the panel will indicate that the submission has been processed and will allow Download the already signed driver, usually accompanied by the catalogs and metadata necessary for its distribution.

Verify that the controller is signed correctly

With the package downloaded, it's time to check that everything is in order. The first step is to extract the files from the shipment to a temporary folder and open a command prompt window with Administrator privilegesFrom there, you can use SignTool to verify the signatures applied to the key binaries.

A basic command would be SignTool verify Echo.syswhich quickly verifies the validity of the signature. For a more thorough verification, you can use SignTool verify /pa /ph /v /d Echo.syswhere /pa indicates that the Authenticode policy should be used, /ph adds hash checking and /v generates verbose output with all the certificate chain information.

To review the Enhanced Key Uses (EKUs) of the certificate used for signing, you can use Windows Explorer: right-click on the binary, select Properties, go to the "Digital Signatures" tab, select the relevant entry, and click "Details." From "View Certificate" and the "Details" tab, you can inspect the "Enhanced Key Uses" field to confirm that it includes the appropriate extensions for code signing or driver signing.

The internal process of some signing workflows implies that Microsoft re-insert your own SHA-2 signature In the binary, any signatures applied by the client are removed if they do not comply with current policies. A new catalog file signed by Microsoft is also generated, replacing any previous .CAT files sent by the vendor.

Testing and installing the driver on Windows

Once the driver is signed, it remains to be verified that it installs and functions correctly on the target system. From an administrator console, tools such as [insert tool names here] can be used. devcon to automate the installation. For example, if the package contains an echo.inf file that defines a root\ECHO device, it would be enough to run devcon install echo.inf root\ECHO in the appropriate folder.

During this process, if everything is properly signed, Ads should not appear Messages like “Windows cannot verify the publisher of this driver software” may appear. If they do, it indicates that something in the chain of trust or in the catalogs is misaligned, and it's advisable to review both the signatures and the root certificates installed on the system.

In more complex scenarios, it is possible to create shipments with multiple controllersTo do this, the usual approach is to create separate subfolders within the file structure, one for each driver package (DriverPackage1, DriverPackage2, etc.), and adjust the DDF file so that each set of .SYS and .INF files is placed in its own subfolder within the CAB. MakeCab then assembles everything into a single cabinet ready to be submitted to the portal.

Driver signatures from the user's point of view

From the end-user's perspective, driver signing is perceived as a security filter built into WindowsAs with signed applications, the idea is for the user to know that the software comes from a legitimate source and has not been altered. However, in the case of drivers, the requirement is greater because they operate at a very high level of privilege.

When a driver is properly signed and published through official channels, Windows Update The operating system itself distributes it quite transparently. This makes it easy for users to receive updated and fixed versions without having to search for anything manually, with the assurance that they have passed Microsoft's filters.

The problem arises when you need to install drivers that are not digitally signed or whose signature is no longer accepted by current policies (for example, when trying to use older hardware on newer systems). In these situations, Windows blocks the installation or displays repeated warnings, forcing the use of more advanced solutions to proceed.

Methods for installing unsigned drivers (and their risks)

There are several ways to install drivers that do not comply with the signing policies, but it is essential to keep in mind that Each method involves a different level of riskA temporary adjustment that is reverted upon restart is not the same as completely disabling integrity checks.

A commonly used method is Boot Windows by temporarily disabling the mandatory use of signed driversTo do this, restart your computer by accessing advanced options (for example, from the Start menu, by pressing Shift while clicking Restart), go to Troubleshoot > Advanced options > Startup Settings, and select the option "Disable driver signature enforcement." The system will then boot without requiring signatures, allowing you to install the driver. Upon restarting again, the protection will be automatically reapplied.

Another option, available only in Windows 10/11 Pro and higher editionsTo do this, use the Group Policy Editor (gpedit.msc). Within User Configuration > Administrative Templates > System > Driver Installation, you can edit the "Code signing for device drivers" policy and set it to Disabled. After restarting, Windows will be much more lenient with unsigned drivers or drivers with questionable signatures.

For testing and development scenarios there is the so-called Trial mode Windows Test Mode is activated from an administrator console by running the bcdedit command, and allows loading drivers signed with test certificates without needing to pass them through the public infrastructure. In this mode, a watermark usually appears on the desktop indicating that the system is in test mode.

Finally, there is the most extreme option: completely disable driver integrity checking using bcdedit.exe (nointegritychecks parameter). This leaves the system completely vulnerable to the installation of any driver, legitimate or not, and should only be used in very specific cases and with full knowledge of what is being done.

Real dangers of disabling driver signing

Disabling this protection is not just a minor inconvenience, but it opens the door to One of the most difficult threats to detect: driver-level rootkitsThese are installed as if they were legitimate drivers, but once loaded they have SYSTEM permissions and the ability to monitor or manipulate the system at a very low level.

A rootkit of this type can intercept internet traffic, insert fake certificates, redirect connections to attacker-controlled sites, block antivirus installation, and facilitate the entry of other malware. All of this can be done with virtually no visible trace for the user, and even for many traditional security solutions.

By operating with the highest privileges, these malicious drivers are practically invisible and difficult to eliminateIn many cases, the only realistic solution involves forma tear the entire PC and start from scratch, which represents a significant loss of time and data if there are no up-to-date backups.

Therefore, when an application asks you to disable driver signature enforcement to install "something magical," it's wise to be suspicious. Whenever possible, it's preferable to... look for alternatives or signed versionseven if it means giving up certain obsolete hardware or some specific functionality.

Windows drivers versus manufacturer drivers

When installing peripherals and components, Windows usually offers generic drivers These allow you to use the hardware in a basic way. For example, a multifunction printer can print without problems using the generic driver, but if you want to scan, use the automatic document feeder, or access advanced options, you will almost certainly need the manufacturer's official driver package.

The same applies to sound cards, graphics cards, and other complex devices: with generic drivers, the computer will function, but you'll lose features, performance optimizations, or advanced configuration tools. In many cases, official drivers also offer these features. specific bug fixes that never reach Microsoft's generic drivers.

The appropriate place to download these drivers is always the official website of the hardware manufacturerWhen you search on Google, you'll often see third-party pages full of suspicious "driver downloaders" or installers first. If the link isn't from the manufacturer's domain, it's best to ignore it.

If driver signing remains enabled, many of these dubious packages will be blocked by Windows upon detecting that they are invalid software or that the signatures are not in order. This acts as an extra layer of security against clumsy or outright malicious installers.

Practical case: Signing certificate error with GPU drivers in Windows 7

On computers with older systems such as Windows 7 64-bitIt's relatively common to encounter problems when installing modern drivers for graphics cards or other recent hardware. A typical example is the error "The signing certificates are not installed. Please install the required certificates" when trying to install drivers for Nvidia for GPUs like the GTX 1060 or the GTX 950.

In many cases, even if the user disables driver signing at startup, the driver fails to function after restarting because the signing policy is re-enabled. Solutions such as installing all previous versions of the driver, using alternative installers (like Snappy Driver Installer), applying SHA-2 support updates (like KB3033929), or reinstalling from Device Manager have been tried without success.

One practical solution that has worked is to manually extract the contents of the installer version 474.11 (latest WHQL driver for Windows 7) to a folder and, from Device Manager, update the GPU driver by choosing the option to search the computer for the driver and specifying that folder. The same method may fail with later versions, such as 474.14, if the wizard does not recognize INF files as valid for that system.

This type of case illustrates just how delicate the balance between recent drivers, SHA-2 certificates and OS no longer supportedIt is becoming increasingly difficult to install—and keep secure—modern drivers on older platforms that do not receive updates or security patches.

How to detect and fix problems with faulty drivers

Even if the drivers are properly signed, they may to become damaged or to become inconsistent This can happen for many reasons: conflicts with other programs, malware, interrupted installations, Windows updates that don't complete successfully, etc. When this occurs, the affected device usually stops working or operates erratically.

The first diagnostic tool is the Device administratorRight-clicking the Start button and selecting the corresponding option opens a complete list of all detected hardware. If a device has driver issues, it will be marked with a yellow warning icon.

In these cases, a first attempt at a solution is to right-click on the device, select "Update driver," and let Windows search for a more suitable driver, either locally or through Windows Update. If that doesn't work, you can uninstall the device (keeping the driver software or not) and restart so that Windows attempts to reinstall it from scratch.

Additionally, Windows includes a hardware and devices troubleshooter Within the Settings panel, specifically in the "Update & Security" > "Troubleshoot" section, this wizard scans the system for irregularities and suggests automated actions to restore the functionality of certain drivers.

If a specific driver update has caused the problem, it may be helpful to use the option of “Return to the previous controller” In the "Driver" tab of the device properties, provided Windows retains the previous version. This reverts the problematic installation and may restore system stability.

View and analyze third-party drivers installed on Windows

To have greater control over what is installed on the system, third-party tools such as Driverview Nirsoft's tool displays a detailed list of all drivers installed on your computer. It's a free, portable utility that greatly simplifies driver auditing.

DriverView uses a very simple color code: Microsoft drivers with a valid digital signature appear with a white background.Third-party drivers (from manufacturers or additional software) are highlighted in red. This helps quickly identify which pieces of the puzzle don't depend directly on the operating system.

The list can be sorted by columns, for example by "Company" to group all drivers from the same company. Additionally, the View menu usually includes an option to hide all Microsoft drivers and show only third-party drivers, allowing you to focus on those most likely to cause conflicts.

Double-clicking on any entry opens a window with detailed driver informationVersion, full path, description, manufacturer, upload date, etc. In the case of unknown or suspicious drivers, this data helps determine if they are part of a program we actually use or if it is advisable to investigate further and even uninstall them.

Given this whole picture, it is clear that the driver signatures and certificates in Windows They are not a mere formality, but a fundamental component for maintaining system stability and security. Understanding how drivers are signed, what requirements change between Windows versions, what tools exist for validation, and how to act when a driver is unsigned or fails allows us to get the most out of our hardware while remaining vigilant against very low-level threats.