How to Check a Driver’s Digital Signature in Windows 11

A Windows driver can be “signed” in more than one sense. The driver package normally contains an INF plus the files it installs, and Plug and Play can treat a digitally signed catalog (.cat) as the signature for that package. A driver binary such as a .sys file can also carry an embedded Authenticode signature. Those are related mechanisms, but they are not interchangeable inspection results.

That distinction matters when a file-properties dialog or PowerShell reports no embedded signature on one driver binary. Microsoft documents catalog signing as a detached-signature mechanism: the catalog stores hashes for package files and the catalog itself is signed. A package can therefore be validly catalog-signed even when an individual file does not contain the embedded signature you expected to find.

Open Device Manager, open the relevant device, and use the Driver and Driver Details information to identify the installed provider, version, and files. Treat this as identification evidence rather than a complete cryptographic verification step. The useful question is which installed package and files belong to this device, not merely whether one .sys filename looks familiar.

If you are troubleshooting an unknown device or deciding which package to install, first identify the exact hardware and use Windows Update or the PC, motherboard, or device manufacturer as the package source. Signature status should not be used to make an unrelated package appropriate for your hardware.

Microsoft’s driver-signing model makes the catalog the important package-level artifact. A catalog contains cryptographic hashes for files in the package, and Plug and Play recognizes the signed catalog as the package signature. If a covered package file changes after signing, its hash no longer matches and the package signature is invalid for that modified content.

For technical verification, Microsoft’s SignTool can verify a catalog and can also verify that a particular package file is represented by that catalog. Microsoft documents `SignTool verify /kp CatalogFileName.cat` for kernel-mode/PnP policy verification and `SignTool verify /kp /c CatalogFileName.cat DriverFileName` for a file listed in that catalog. SignTool is supplied with Microsoft’s Windows SDK/WDK tooling, so this method is aimed at cases where you need stronger evidence than a normal UI inspection.

Authenticode identifies the publisher of signed software and lets Windows verify that the signed content has not changed since it was signed. For a file that actually has an embedded signature, inspecting that signature can therefore answer who signed that file and whether its signature validates under the applicable trust chain.

Do not turn an individual-file result into a package-level conclusion without checking how that driver is signed. Microsoft explicitly supports both embedded signatures and digitally signed catalog files. If a driver package relies on its catalog, checking only for an embedded signature on the .sys file can produce a misleading “unsigned” conclusion.

A valid digital signature is evidence about publisher identity, integrity, and compliance with the verification policy being applied. It is not a quality score. A legitimately signed driver can still be old, contain bugs, be intended for different hardware, or be the wrong choice for your current Windows build. Conversely, seeing a familiar vendor name is not enough to establish that a package came through the support path intended for your exact system.

WHQL or Windows Hardware Program signing adds a different kind of evidence from an ordinary third-party release signature. Microsoft notes that a WHQL release signature reflects the applicable Windows hardware-program testing as well as publisher identity and integrity, whereas a third-party release signature does not by itself verify driver functionality. Keep that distinction separate from simple “signed versus unsigned” language.

Windows kernel-mode signing policy is an enforcement mechanism, not a nuisance switch to bypass whenever an installer fails. Microsoft documents test-signing and temporary enforcement changes for driver-development and testing scenarios, but those workflows are not a generic repair for a consumer PC.

If Windows rejects a driver, first verify the package source, exact hardware support, Windows version and architecture, and whether the package has been altered or is simply obsolete. If a manufacturer still requires an unsigned or test-signed driver for supported hardware, follow that manufacturer’s documented deployment path and understand the security tradeoff rather than weakening signature enforcement as the first troubleshooting step.

For a normal installed device, the useful sequence is: identify the device and installed driver, determine whether you need package-level or individual-file evidence, verify the appropriate signature mechanism, then compare the package with the supported source for that exact hardware. This avoids the common mistake of calling a catalog-signed driver “unsigned” because one binary lacks an embedded signature.

If the signature validates but the device is malfunctioning, continue with driver rollback, update, device-specific diagnostics, or hardware troubleshooting according to the symptoms. If verification fails, do not assume malware from that result alone: confirm that you inspected the correct catalog/file pair and that the package has not been modified, then obtain a clean supported package from Windows Update or the manufacturer before drawing a stronger conclusion.