Turning off driver signature enforcement system-wide is the fastest way to get an unsigned Android USB driver installed, but it's a blunt instrument — it weakens Windows' protection against any unsigned kernel driver, not just the one you're trying to install, for as long as it stays disabled. Self-signing the specific driver package with a local test certificate is more work up front, but it lets the driver install normally afterward without leaving the whole system less protected.
Self-signing is worth the extra steps when a driver needs to be reinstalled repeatedly — across a reformat, a different machine, or after Windows Update resets driver state — since a self-signed package installs cleanly every time afterward without needing signature enforcement toggled off first. For a one-time install of a driver you'll never touch again, the standard disable signature enforcement approach is simpler and perfectly adequate; this is the option for anyone building or repeatedly deploying custom driver packages.
.inf file and, for kernel-mode components, a matching .cat catalog file — user-mode-only driver packages don't need this process at all.Inf2Cat, MakeCert, and SignTool command-line utilities they include.bcdedit /set testsigning on and a reboot), since a locally generated test certificate is only trusted by Windows when test signing is active.MakeCert, specifying a subject name and marking it for code signing (-eku 1.3.6.1.5.5.7.3.3).Inf2Cat against the driver folder, targeting the correct OS version, to generate a fresh catalog file that matches the current INF contents.SignTool, using the test certificate created earlier.A self-signed test certificate only works on machines where Test Mode is explicitly enabled; it has no effect on a normal, out-of-the-box Windows install, and it isn't a way to get a driver genuinely trusted by Microsoft or distributed to other people's machines without them repeating the same setup. It's strictly a local development and repeated-personal-use workaround, not a substitute for a real Microsoft-issued signing certificate, which is a separate paid program intended for actual driver vendors.
Since Test Mode weakens signature checking system-wide while active (similar in effect to disabling enforcement, just scoped differently), running bcdedit /set testsigning off and rebooting once the driver is no longer needed restores normal signing requirements. Microsoft's own Test Mode documentation covers the option in more depth for anyone doing this regularly as part of driver development rather than a one-off Android driver install.
Test Mode and Secure Boot don't always coexist cleanly, and on some systems, enabling Test Mode with Secure Boot active in firmware prevents the test-signed driver from loading even though the certificate itself installed without complaint. If a self-signed driver still won't load after following every step correctly, checking Secure Boot status in the BIOS/UEFI settings, and temporarily disabling it if Test Mode alone doesn't resolve the load failure, is worth trying before concluding the certificate or signing process itself was done wrong.
For the overwhelming majority of people installing an unsigned Android USB driver a single time, this entire process is more effort than it's worth, and the simpler signature-enforcement bypass is the right tool. Self-signing earns its extra complexity specifically for repeated deployment scenarios: technicians reimaging multiple machines with the same custom driver set, developers iterating on their own driver package during testing, or IT environments that need a driver to survive Windows Update resets without repeating the boot-menu bypass every time. Recognizing which category a given situation falls into before starting saves time either way.