CRYPT_E_NO_PROVIDER (0x80092006) fix – No provider specified

You're getting this error and it's driving you crazy

I get it. You're trying to open a certificate, sign a driver, or install software and you hit CRYPT_E_NO_PROVIDER (0x80092006). It's cryptic and vague—exactly the kind of error that makes you want to throw your laptop out the window. But the fix is straightforward once you know where to look.

The real fix: Reset the crypto environment

Skip the registry edits everyone suggests—they rarely work for this specific error. The core issue is that Windows' cryptographic service provider (CSP) can't initialize properly. This usually happens after a partial Windows update, a botched security tool install, or a system corruption event.

Step 1: Run SFC and DISM

Open an elevated Command Prompt (right-click Start > Command Prompt (Admin) or Windows Terminal Admin).

DISM /Online /Cleanup-Image /RestoreHealth

Wait—this takes 5-15 minutes. When it finishes, run:

sfc /scannow

SFC will repair any corrupted system files. Reboot when it's done.

Step 2: Re-register crypt32.dll

crypt32.dll is the heart of Windows' certificate and crypto operations. If it's corrupted or its registration is borked, you'll see this error.

regsvr32 /u crypt32.dll
regsvr32 crypt32.dll

Run each command separately. You'll see a success message for both. If you get a failure, proceed to step 3.

Step 3: Repair the Cryptographic Services

Open Services.msc (Win+R, type services.msc). Find these three services:

Cryptographic Services
Certificate Propagation
CNG Key Isolation

Stop all three. Then restart each one in this order: Cryptographic Services first, CNG Key Isolation, then Certificate Propagation. Test your operation again.

Why this works

Error 0x80092006 hits when the Cryptographic Service Provider (CSP) can't load or find itself. The CSP is like a translator between your app and the certificate store. When crypt32.dll gets corrupted (often from a failed Windows update or a virus scanner that quarantines crypto files), the CSP goes blind. Re-registering the DLL tells Windows where to find it again. DISM and SFC fix the underlying file corruption that caused the registration to drop.

Less common variations

I've seen this error pop up in a few specific scenarios:

After installing Visual Studio 2019/2022: The Visual C++ redistributables sometimes overwrite crypto files. Re-run the VC++ redist installer or repair Visual Studio.
Windows 11 22H2 with certain VPN clients: Some VPNs (especially OpenVPN-based) mess with the CSP. Uninstall the VPN, fix crypto files as above, then reinstall the VPN.
During driver signing with an EV certificate: This is common if you're using an older version of signtool.exe. Update to the latest Windows SDK—older signtool versions have known CSP lookup bugs.
In a domain environment with PKI: Group Policy sometimes pushes certificate store configurations that conflict with local CSPs. Run gpupdate /force and then re-register crypt32.dll.

Prevention: Keep your crypto clean

This error is almost always caused by corruption, so prevention is about keeping Windows healthy:

Never skip Windows updates. Microsoft fixes crypto bugs regularly. I can't tell you how many tickets I closed with 'install the latest cumulative update'.
Don't use registry cleaners. They love deleting crypt32.dll registry entries thinking they're orphaned. They're not. Stop.
If you use a third-party antivirus, whitelist crypt32.dll. Some aggressive antivirus (looking at you, McAfee and Norton) quarantine it during scans of system32.
Back up your certificate store if you have important certs. Use certlm.msc (Local Machine) or certmgr.msc (Current User) and export your certificates as .pfx with private keys.

I had a client once who got this error every month—turns out his IT guy was running a scheduled task that cleaned registry keys daily. Stopped that task, error never came back.

If you've gone through all these steps and still see 0x80092006, check the Windows Application Event Log (Event Viewer > Windows Logs > Application). Look for events from source Crypt32. They'll tell you exactly which CSP it's trying (and failing) to load. That's your next clue. But 9 times out of 10, the steps above will get you there.