Driver signing is the requirement that a device driver carry a valid digital signature from a trusted authority before the operating system loads it into the kernel. In OS security, it is one of the built-in protections that guards the most privileged part of a desktop system, because a driver runs with full kernel rights and can bypass almost every other safeguard.
The signature proves two things: who published the driver and that the file has not been altered since it was signed. Windows enforces this through kernel-mode code signing policies, and macOS applies a comparable rule to system extensions and driver extensions.
How driver signing works
Driver signing is built on public key cryptography. The publisher computes a cryptographic hash of the driver files, encrypts that hash with a private key, and attaches the result together with a certificate chain. Windows packages usually record the hashes of all files in a catalog file (.cat), so a single signature covers the whole package.
When the driver loads, the kernel’s code integrity component recomputes the hash, checks it against the signature and walks the certificate chain up to a trusted root. If any step fails, the load is blocked and an event is written to the system log.
| Component | Role in verification |
|---|---|
| Hash | Fingerprint of the driver files, usually SHA-256 |
| Signature | Hash encrypted with the publisher’s private key |
| Certificate chain | Links the publisher key to a trusted root |
| Timestamp | Proves the file was signed while the certificate was valid |
| Code integrity engine | Kernel component that checks every load |
| Revocation list | Blocks certificates or files known to be abused |
The timestamp matters more than many developers expect. Without it, a driver stops loading when the signing certificate expires; with it, the signature remains valid because it was created during the certificate’s validity period.
Signature checks apply most strictly to kernel-mode drivers. User-mode drivers, such as many printer and sensor components, run in an ordinary process with limited rights, so a flaw in them is far less dangerous. This difference is why operating system vendors push hardware makers to move as much driver logic as possible out of the kernel and into user space, where a crash or compromise affects one process rather than the whole system.
Signing policies in Windows and macOS
The rules have tightened steadily. 64-bit Windows has required signed kernel drivers since Windows Vista, and since Windows 10 version 1607 new kernel drivers must be signed by Microsoft through its hardware developer portal rather than by the vendor’s own certificate alone, with exceptions for older drivers and certain upgrade paths.
| Signing type | Who signs | What it proves | Where it is accepted |
|---|---|---|---|
| Attestation signing | Microsoft, after vendor submission | Identity and integrity, no testing | Windows client editions |
| WHQL certification | Microsoft, after compatibility tests | Identity, integrity and tested behavior | All editions, including Windows Update |
| Test signing | Developer’s own test certificate | Nothing to other machines | Only in test signing mode |
| Cross-signing (legacy) | Vendor with a cross-certificate | Identity and integrity | Older drivers only |
On macOS, kernel extensions are deprecated in favor of DriverKit system extensions, which run in user space. They must be signed with an Apple developer identity and notarized, and the remaining kernel extensions require explicit user approval and, on Apple silicon, a reduced security setting.
Driver signing and related protections
Driver signing is one layer among several in the security of a desktop operating system. It answers who wrote the code, not whether the code is safe, so neighboring mechanisms close the remaining gaps.
| Protection | What it controls | Relation to driver signing |
|---|---|---|
| Secure Boot | Boot loaders and early boot components | Extends the chain of trust before the kernel starts |
| HVCI (memory integrity) | Kernel code pages at run time | Enforces signature checks from the hypervisor |
| Vulnerable driver blocklist | Known exploitable signed drivers | Blocks drivers that are signed but dangerous |
| App notarization | User applications on macOS | Same principle for apps instead of drivers |
| SIP | Protected macOS system files | Prevents replacement of signed system components |
Hypervisor-protected code integrity (HVCI) is especially important. It moves the signature check into a virtualized environment, so even malware that has reached the kernel cannot easily mark its own unsigned code as executable.
Bypasses, risks and common mistakes
The best-known weakness is bring your own vulnerable driver (BYOVD). An attacker installs a legitimate, properly signed driver that contains a flaw, then exploits that flaw to run arbitrary code in the kernel. The signature is valid, so signing alone cannot stop this attack; blocklists and memory integrity are needed.
Stolen code signing certificates are a second risk. Several major malware campaigns used certificates stolen from real hardware vendors, which is why revocation and Microsoft-controlled signing were introduced.
| Symptom | Likely cause | Recommended fix |
|---|---|---|
| Device shows error code 52 | Missing or invalid signature | Obtain a properly signed driver from the vendor |
| Old driver stops loading after update | Blocklist or HVCI incompatibility | Install an updated driver version |
| Driver failed after certificate expiry | No timestamp on signature | Re-sign with a timestamp |
| Test driver will not load | Test signing mode disabled | Enable it only on development machines |
A common mistake is disabling signature enforcement permanently to get one old device working. This removes protection for the whole system; a safer choice is replacing the device or isolating it on a separate machine.
Stripped to the essentials
A driver is a small program that lets the operating system talk to a piece of hardware, such as a printer or a graphics card. Because drivers work at the deepest level of the computer, a malicious one could take over everything.
Driver signing works like a tamper-proof seal on a medicine bottle. The operating system checks that the seal comes from a known, trusted maker and has not been broken. If the seal is missing or damaged, the driver is not allowed in. The seal does not prove the contents are perfect, but it shows where they came from and that nobody changed them.
Where it is applied
A hospital IT department manages about 2,000 Windows workstations connected to label printers, barcode scanners and imaging devices. Policy requires that every workstation keep driver signature enforcement and memory integrity enabled.
When a supplier delivers a new scanner whose driver is only test-signed, Windows refuses to load it and logs a code integrity event. Instead of disabling enforcement, the IT team asks the supplier for an attestation-signed release, which arrives two weeks later and installs without warnings.
Months later, a security advisory lists an old, signed hardware utility driver as exploitable. Because the workstations use the vulnerable driver blocklist, the driver is already blocked, and the team only has to remove the utility from its software catalog.