A quick answer: if Windows refuses to accept a driver you just installed, the most common culprit is that Driver signature enforcement not working in Windows 10 — either because Windows is still enforcing signatures when you expect it not to, or because the driver’s signature is invalid or being blocked. This article explains the usual causes and shows clear, step‑by‑step fixes so you can install or test drivers safely.
You’ll learn why enforcement fails (Secure Boot, test mode, corrupted signatures, policies, antivirus interference, wrong architecture, cached boot state, stricter Windows signing rules) and how to resolve each problem with exact commands and menu paths.
Key Takeaway
If a driver fails signature validation, first check whether Windows is enforcing signatures (Secure Boot, Test Mode, or Startup settings), then verify the driver’s certificate and architecture; use the temporary startup option to disable signature enforcement for testing, and only disable security features (Secure Boot/Test Mode) when absolutely necessary and on a test system.
Quick Fix Guide
| Reason for the Problem | Quick Solution |
|---|---|
| Secure Boot is blocking unsigned or test-signed drivers | Disable Secure Boot in UEFI or obtain a Microsoft/WHQL-signed driver. |
| Test signing not enabled (or you need a temporary bypass) | Use bcdedit /set testsigning on or use the temporary Startup Settings (F7). |
| Driver signature is invalid, expired, or revoked | Check the driver’s Digital Signatures and update/download a properly signed driver. |
| Wrong driver architecture (x86 vs x64) | Install the correct architecture driver that matches Settings > About > System type. |
| Windows 10 enforces stronger signing (attestation/SHA-2) | Get an updated driver signed for current Windows 10 requirements from the vendor. |
| Group Policy or registry enforces blocking | Change gpedit.msc or set registry key HKLM\SOFTWARE\Policies\Microsoft\Windows\DriverSigning\Policy to allow/warn. |
| Fast Startup or cached boot state prevents changes | Disable Fast Startup in Control Panel > Power Options and reboot. |
| Third-party security software interferes | Temporarily disable/uninstall the security product and reinstall the driver. |
Detailed Fixes for “Driver signature enforcement not working in Windows 10”
Below are the eight common reasons listed above with clear explanations and step‑by‑step solutions.
1) Secure Boot is blocking unsigned or test‑signed drivers
Why this causes the problem:
Secure Boot (UEFI firmware feature) prevents unsigned or improperly signed kernel components from loading. Even if you enable test signing at the OS level, Secure Boot can still block those drivers.
Step-by-step solution:
- Check Secure Boot state: Open Start, type msinfo32 and run System Information; look for Secure Boot State.
- If Secure Boot is On and you need to load a test‑signed driver, reboot into UEFI: Settings > Update & Security > Recovery > Advanced startup > Restart now.
Then choose Troubleshoot > Advanced options > UEFI Firmware Settings > Restart. - In the UEFI/BIOS menu find Secure Boot (location varies by vendor) and set it to Disabled. Save and exit.
- Reboot Windows and retry the driver install.
Notes/tips:
- Disabling Secure Boot reduces security; only do it on a test machine or temporarily.
- If possible, get a driver that is properly Microsoft/WHQL signed instead of disabling Secure Boot.
2) Test signing not enabled (or you need a temporary bypass)
Why this causes the problem:
Developers often use test‑signing for unsigned kernel drivers. Windows will refuse these unless Test Mode is enabled or you use the temporary Startup Settings bypass.
Step-by-step solution (temporary):
- Hold Shift and click Restart (Start > Power > Hold Shift > Restart).
- Choose Troubleshoot > Advanced options > Startup Settings > Restart.
- Press 7 or F7 to Disable driver signature enforcement.
Windows will boot with enforcement disabled for that session only.
Step-by-step solution (persistent test mode):
- Open Command Prompt as Administrator (right‑click Start, Command Prompt (Admin) or Windows PowerShell (Admin)).
- Run: bcdedit /set testsigning on
- Reboot. Windows should show “Test Mode” in the desktop corners; test‑signed drivers will load.
- To undo: run bcdedit /set testsigning off and reboot.
Notes/tips:
- The temporary F7 option is safer for single installs.
- Test Mode weakens protection; don’t leave it enabled on a production machine.
3) Driver signature is invalid, expired, or revoked
Why this causes the problem:
Even if a driver has a “signature”, the certificate chain can be invalid, expired, or revoked, or the file may be corrupt.
Step-by-step solution:
- Locate the driver file (for example C:\Windows\System32\drivers\driver.sys) or the driver package (.inf/.cat).
- Right‑click the file, choose Properties > Digital Signatures and inspect the signer and timestamp.
- For deeper verification, open an elevated Command Prompt and run (if you have signtool): signtool verify /v /kp “C:\path\driver.sys”.
If you don’t have signtool, use the Properties method or check Windows Event Viewer for driver installation errors: Event Viewer > Windows Logs > System. - If the certificate is expired/revoked or shows errors, download the latest driver from the vendor or request a Microsoft‑signed/WHQL version.
Notes/tips:
- Some driver installers bundle older/corrupt files — uninstall the existing driver and do a clean reinstall from the vendor.
- If you’re a developer, re‑sign the driver with a valid EV code signing certificate or use Microsoft attestation signing where required.
4) Wrong driver architecture (x86 vs x64)
Why this causes the problem:
A 32‑bit driver cannot run on 64‑bit Windows kernel and vice versa; Windows will not accept mismatched binaries.
Step-by-step solution:
- Check your system type: Settings > System > About (look at Device specifications > System type) or Control Panel > System.
- Download the correct driver package (look for x64 or x86 on the vendor site).
- Uninstall the incorrect driver: Device Manager > find device > right‑click > Uninstall device (check Delete the driver software for this device if present).
- Install the correct‑architecture driver package and reboot.
Notes/tips:
- Some vendors provide “universal” installers; confirm which binary is used during install.
- If a packaged installer installs both versions, check the installation log.
5) Windows 10 enforces stronger signing rules (attestation / SHA‑2 requirements)
Why this causes the problem:
Microsoft tightened kernel‑mode signing requirements (SHA‑2, Microsoft attestation/WHQL) in newer Windows 10 releases. Older SHA‑1 or self‑signed drivers may be rejected.
Step-by-step solution:
- Contact the hardware vendor and request a driver specifically signed for current Windows 10 (look for WHQL or Microsoft attestation).
- If you are a developer, submit a driver to Microsoft for attestation signing or sign with the required SHA‑2 certificate chain.
- As a temporary workaround, use the F7 temporary disable method (see section 2) on a test machine — not recommended for production.
Notes/tips:
- Microsoft provides guidance for driver signing to developers; production drivers should follow it.
- If a vendor refuses, consider alternatives or replacement hardware.
6) Group Policy or registry enforces blocking of unsigned drivers
Why this causes the problem:
Local or domain Group Policy can enforce driver code signing behavior, overriding local user actions.
Step-by-step solution (using Local Group Policy Editor):
- Press Win + R, type gpedit.msc, and press Enter.
- Navigate to Computer Configuration > Administrative Templates > System > Driver Installation.
- Open Code signing for device drivers, set to Enabled and choose Ignore or Warn to allow unsigned drivers as needed, then OK.
- Update policy: open elevated Command Prompt and run gpupdate /force.
Registry method (Windows Home / no gpedit):
- Open an elevated Command Prompt and run:
reg add “HKLM\SOFTWARE\Policies\Microsoft\Windows\DriverSigning” /v Policy /t REG_DWORD /d 0 /f
(0 = Ignore, 1 = Warn, 2 = Block) - Reboot.
Notes/tips:
- Domain policies set by IT may reapply; consult your administrator before changing domain-managed machines.
- Changing policy to Ignore reduces protection and should be temporary.
7) Fast Startup / hybrid hibernation caches old boot state
Why this causes the problem:
Fast Startup can cache kernel state across boots, meaning changes to boot configuration (like disabling testsigning) or driver load flags may not take effect until a full shutdown.
Step-by-step solution:
- Open Control Panel > Hardware and Sound > Power Options > Choose what the power buttons do.
- Click Change settings that are currently unavailable.
- Uncheck Turn on fast startup (recommended) and click Save changes.
- Perform a full shutdown: open Command Prompt (Admin) and run shutdown /s /t 0, then power on and test the driver.
Notes/tips:
- You can re-enable Fast Startup later if desired.
- Full shutdowns ensure bootloader and firmware options are applied cleanly.
8) Third‑party security or anti‑tamper software interferes
Why this causes the problem:
Security suites, anti‑cheat, or kernel protection software may block unsigned drivers or quarantine driver files during install.
Step-by-step solution:
- Identify the security software running: check the system tray or Settings > Apps.
- Temporarily disable real‑time protection via the vendor’s UI or Windows Security: Settings > Update & Security > Windows Security > Virus & threat protection > Manage settings > Real‑time protection (toggle off temporarily).
- If the vendor blocks kernel drivers via tamper protection, either disable that feature or uninstall the security product temporarily: Settings > Apps > Apps & features, find the product, and uninstall.
- Install the driver, reboot, and then re‑enable the security product immediately.
Notes/tips:
- Temporarily disabling antivirus is risky; do this only if you trust the driver source and preferably on a test system.
- Check vendor support for whitelisting signed drivers.
Safety and testing (additional section)
- Always test unsigned or test‑signed drivers on a non‑production machine or in a virtual machine. Use Hyper‑V, VirtualBox, or VMware to reduce risk.
- Use the built‑in Driver Verifier tool to detect unstable drivers: open Command Prompt (Admin) and run verifier, choose Create custom settings > select drivers and reboot. Remove Verifier settings if the system becomes unstable.
- Keep full backups or system restore points before changing boot or signing policies.
- Re-enable Secure Boot, Test Signing off, and antivirus after testing.
FAQ
What is the safest way to test an unsigned driver?
Use the temporary Startup Settings bypass (Shift + Restart → Troubleshoot → Advanced options → Startup Settings → F7) on a test machine or in a virtual machine, and never disable Secure Boot on a production PC.
Can I permanently disable driver signature enforcement?
You can enable testsigning with bcdedit /set testsigning on, but this is not recommended for daily use because it lowers kernel security. Secure Boot may still prevent test‑signed drivers from loading; disabling Secure Boot is required in that case.
How do I re‑enable enforcement after testing?
Open an elevated Command Prompt and run bcdedit /set testsigning off, re‑enable Secure Boot in UEFI if you disabled it, and restart the PC.
Why does Windows say a driver is unsigned but the file shows a Digital Signature?
There are different signature types. Windows requires kernel‑mode drivers to be signed for kernel enforcement; a user‑mode signature or an invalid certificate chain might appear but still fail kernel checks. Check the Digital Signatures tab and validate the certificate chain and timestamp.
How do I get a driver properly signed for Windows 10?
If you’re a hardware vendor/developer, obtain an EV code signing certificate and submit the driver to Microsoft for attestation signing or WHQL certification where required. For end users, request a signed driver package from the hardware vendor.
Conclusion
Most driver install problems labeled as Driver signature enforcement not working in Windows 10 stem from Secure Boot, test signing state, invalid certificates, policy settings, or interference from security software. Follow the step‑by‑step checks above — starting with temporary bypasses and signature validation — and only change firmware or security settings on a test system or when absolutely necessary.
