Device Manager shows your NPU with a yellow warning: “Windows cannot verify the digital signature for the drivers required for this device (Code 52).” The neural processor is present, Windows knows what it is — and refuses to load its driver anyway. Studio Effects, Recall, and every other NPU feature goes dark.
Code 52 is Windows’ security boundary doing its job. Every kernel driver on Windows 11 must carry a valid digital signature proving it comes from a trusted publisher and hasn’t been tampered with. When that check fails, Windows blocks the driver completely rather than gamble on untrusted code running at the deepest level of your system.
The fix is almost never to weaken the security check — it is to give Windows a driver that passes it. This guide walks through six fixes in technician order: identify the bad package, replace it with a properly signed one, and clean up anything that keeps dragging the unsigned copy back.
Why this happens
- Driver from an unofficial source: Third-party driver updaters and random download sites distribute repackaged, outdated, or modified NPU drivers whose signatures are broken or missing. This is the number one cause of code 52.
- Corrupt driver files: A signature is a cryptographic seal over the driver files. If an interrupted install or disk error alters even one byte, the seal no longer matches and Windows reports code 52.
- Expired signing certificate: Driver signatures are timestamped, but very old packages can still trip verification on systems with strict policies or incorrect clocks.
- Wrong system clock: Signature verification is time-sensitive. A CMOS battery failure that resets your clock to 2015 can make a perfectly valid signature look untrustworthy.
- Leftover driver store contamination: An unsigned package lingering in the Driver Store can get reinstalled over your good driver, bringing code 52 back like a bad sequel.
- Tampered or patched driver: “Modded” drivers that unlock features or bypass limits break their signatures by definition — Windows will always block them with code 52 on a default configuration.
How to fix it
Work through these in order — diagnose first, then act.
Fix 1: Check where the current driver came from
Before replacing anything, confirm the diagnosis. The driver’s origin usually tells the whole story.
- In Device Manager, open the NPU’s Properties > Driver and note the Driver Provider and Driver Date.
- If the provider is unknown, blank, or a name you don’t recognize — instead of Intel, AMD, Qualcomm, or your laptop maker — you have found your unsigned package.
- Check the Digital Signer field on the Details tab (property: Digital Signer). Missing or untrusted signer confirms code 52’s complaint.
- If the driver came from a third-party updater, uninstall that updater too — otherwise it will “helpfully” reinstall the bad driver later.
Fix 2: Correct the system clock
It sounds too simple, but a wrong clock genuinely breaks signature verification. Rule it out in thirty seconds before doing driver surgery.
- Right-click the clock in the taskbar and open Adjust date/time.
- Enable Set time automatically and Set time zone automatically, then click Sync now.
- Restart and check Device Manager — if code 52 clears, the clock was the whole problem.
- If the clock resets to a wrong date on every boot, your CMOS battery is dying; replace it (or have a shop do it) so the problem doesn’t return.
Fix 3: Install the properly signed driver from your laptop maker
This is the real fix in most cases. OEM drivers are signed with the vendor’s certificate and validated against your exact model.
- Find your exact model in Settings > System > About.
- On Dell , HP , or Lenovo support, download the latest NPU/chipset driver package for Windows 11.
- In Device Manager, uninstall the NPU with “Attempt to remove the driver for this device” checked, then restart.
- Run the OEM installer as administrator, restart, and verify the warning is gone and the Digital Signer field shows a trusted publisher.
Fix 4: Purge the unsigned package from the Driver Store
If code 52 returns after you install the good driver, an unsigned copy is lurking in the Driver Store and Windows keeps reinstalling it. This is also worth doing when signature verification failed during the install itself .
- Open an elevated terminal and run
pnputil /enum-driversto list third-party driver packages. - Find entries from the NPU vendor with old dates or unknown providers and note their published names (oemNN.inf).
- Remove each suspect with
pnputil /delete-driver oemNN.inf /uninstall /force, being careful to target only NPU-related packages. - Reinstall your signed OEM driver, restart, and confirm code 52 stays gone.
Fix 5: Get the driver from the chip vendor as a fallback
When your laptop maker hasn’t published a recent NPU driver, the chip vendor’s own signed package is the next-best source — still properly signed, still trustworthy.
- Identify your NPU: Intel Core Ultra (AI Boost), AMD Ryzen AI, or Snapdragon X.
- For Intel, use Intel’s driver assistant ; for AMD, the AMD driver page . Download only from these official pages.
- Uninstall the current NPU driver with file deletion, restart, then install the vendor package as administrator.
- Verify the Digital Signer field and test an AI feature — Recall indexing is a good stress test since it exercises the NPU continuously.
Fix 6: Repair Windows’ signature infrastructure
Rare, but real: the problem isn’t the driver, it’s Windows’ ability to verify anything. Corrupt certificate stores or damaged system files make every signature check fail.
- Run
sfc /scannowin an elevated terminal, thenDISM /Online /Cleanup-Image /RestoreHealth. - Open certmgr.msc and confirm the Trusted Publishers and Trusted Root Certification Authorities stores are populated — on a healthy system they contain hundreds of entries.
- If you previously disabled driver signature enforcement (via bcdedit or the startup menu), re-enable it:
bcdedit /set testsigning offin an elevated terminal, then restart. - Reinstall the signed OEM driver one final time. If code 52 survives all of this, escalate to your laptop maker’s support — and if video features flicker or misbehave alongside it, mention that too, since both can trace to the same broken driver package.
Closing
Code 52 looks like Windows being stubborn, but it is Windows protecting you from untrusted kernel code. Don’t disable the protection — replace the driver with one that passes it. Get the package from your laptop maker or the chip vendor, purge unsigned leftovers from the Driver Store, and check the system clock. A properly signed driver loads silently, the warning disappears, and your NPU gets back to work with the security boundary intact.
