Some smaller Android OEMs, older driver packages, and community-built drivers for niche chipsets are not signed with a certificate Windows trusts, and installation fails with "Windows cannot verify the digital signature" or the driver silently refuses to bind even though the .inf file looks correct. Signature enforcement exists for good security reasons, so this should be a last resort after confirming the official driver truly does not work, not a routine first step.
This method disables enforcement for a single boot session only, which re-enables itself automatically the next time you restart normally — the safer option since you do not have to remember to turn security back on afterward.
Because this only lasts one session, you must complete the driver installation before rebooting again. If you reboot before finishing, repeat the whole sequence.
For drivers that need to keep working across reboots without repeating the F7 sequence every time, a permanent change is available through an elevated Command Prompt:
bcdedit /set testsigning onThis also requires disabling Secure Boot in your PC's UEFI/BIOS settings first, since Secure Boot independently blocks unsigned drivers at a level bcdedit alone cannot override. A watermark reading "Test Mode" appears in the bottom-right corner of the desktop while this is active, as a persistent reminder that the security setting is weakened.
To revert:
bcdedit /set testsigning offThen re-enable Secure Boot in the UEFI settings and reboot. Do not leave test mode enabled indefinitely on a daily-use PC; the watermark is intentionally visible because Microsoft wants this treated as a temporary development configuration, not a permanent setting.
Since Windows 10, kernel-mode drivers must carry a valid Microsoft-issued signature (through the Windows Hardware Compatibility Program) to load without one of the workarounds above. Smaller manufacturers sometimes skip this certification for a niche USB driver that sees limited use, or a driver package predates the enforcement requirement and was never updated. This is more common with regional or budget-brand Android devices than with major OEMs, whose ADB/Fastboot drivers are almost always properly signed.
Before going through either method, confirm the failure is actually about signing rather than a corrupted download or wrong architecture. Right-click the .inf file's containing folder, and if Windows shows a SmartScreen warning specifically mentioning an unrecognized publisher when you try to run any installer .exe inside it, that is a different (unrelated) warning about the installer executable, not the driver signature itself. The actual signature error appears specifically inside the Device Manager driver update wizard, worded as "The third-party INF does not contain digital signature information."
Both methods lower the bar for what kernel-mode code Windows will load without verification, which is exactly the mechanism that normally prevents malicious drivers from loading silently. Only use this for a driver you obtained from the manufacturer's own site or a well-known Android development community source, and revert the setting once the driver is confirmed working rather than leaving it enabled long-term.
Occasionally a driver is properly signed but still refuses to load purely because Secure Boot policy on the specific PC rejects the signing chain used (this happens more with older cross-signed certificates than with current ones). In that narrow case, disabling Secure Boot in the UEFI settings without touching test signing mode at all is enough, and it avoids the "Test Mode" watermark entirely. Try this first if the driver installer completes without any signature warning during setup but the device still fails to bind afterward, since that pattern points more toward a Secure Boot policy mismatch than an actual unsigned driver.
On a company-managed or domain-joined PC, Group Policy or an MDM profile frequently locks out both the F7 boot menu option and bcdedit changes entirely, regardless of local administrator rights. If the F7 option does not appear in the Startup Settings menu, or bcdedit /set testsigning on returns an access-denied style error despite running as administrator, this is a policy restriction rather than a bug, and getting an unsigned driver working will require either an exception from IT or reverting to trying the properly signed Google USB Driver package instead, which needs no security setting changes at all.