NTE_BAD_PROVIDER (0x80090013) – Invalid Provider Specified Fix

You see 0x80090013 (NTE_BAD_PROVIDER) when Windows tries to perform a cryptographic operation—like enrolling a certificate, starting BitLocker, or unlocking with Windows Hello—and the requested key storage provider isn't where the system expects it. The OS calls into CNG (Cryptography Next Generation), asks for a specific provider by name, and gets back nothing useful. That's the error.

The most common trigger? A Windows update that renames or removes the Microsoft Software Key Storage Provider, or a third-party security tool that messes with the CNG registry entries. I've also seen this after rolling back from Windows 11 Insider builds. You'll know it's hardware-independent, because it happens on devices with or without a TPM.

Let's walk through three causes, going from the most common to the least. Each fix is self-contained—you don't have to do them all.

1. Corrupted or missing Microsoft Software Key Storage Provider

This is the culprit maybe 70% of the time. Windows ships a built-in software KSP (key storage provider) that many things rely on—BitLocker, certificate services, even the SChannel TLS handshake. If the DLL that implements it (ncryptprov.dll) gets unregistered or the registry path for it gets corrupted, you'll see 0x80090013.

Fix: Re-register the provider via DISM and regsvr32

1. Open an admin Command Prompt (Win+R, type cmd, Ctrl+Shift+Enter).
2. Run these two commands in order:

   dism /online /cleanup-image /restorehealth
   sfc /scannow

   Wait for both to complete. This repairs system files that might be corrupt.
3. Then re-register the provider DLL:

   regsvr32 /s ncryptprov.dll

   The /s flag suppresses the success dialog—won't give you a popup.
4. Reboot. Test the operation that failed (certificate enrollment, BitLocker unlock, whatever it was).

What's actually happening here: dism checks the component store against the online Windows image and replaces any corrupted payloads. Then sfc verifies all protected system files. If ncryptprov.dll was missing or modified, step 3 re-registers it in the COM/CNG catalog so Windows knows which CLSID to call for the provider.

If that didn't work, the registry reference for the provider might be missing outright. Let's check.

2. Missing registry entries under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Providers\KeyStorage

CNG providers are registered in the Registry under a specific key. If the Microsoft Software Key Storage Provider subkey doesn't exist, or its DLL value points to nothing, Windows throws 0x80090013. This often happens after a third-party antivirus uninstaller deletes related registry keys.

Fix: Restore the CNG provider registry key

1. Open Regedit as admin (Win+R, regedit, Ctrl+Shift+Enter).
2. Navigate to:

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Providers\KeyStorage

3. Check if there's a subkey named Microsoft Software Key Storage Provider. If not, create it.
4. Inside that key, create these values:

   Name	Type	Data
   DLL	REG_EXPAND_SZ	%SystemRoot%\System32\ncryptprov.dll
   Name	REG_SZ	Microsoft Software Key Storage Provider
   Type	REG_DWORD	1

5. Close Regedit and reboot.

The reason step 3 works: CNG iterates over subkeys under KeyStorage to find the provider by name. If it can't find the key, or the DLL path is invalid, the function NCryptOpenStorageProvider returns NTE_BAD_PROVIDER. You're essentially telling Windows, "here's where the provider lives."

3. Group Policy or third-party software overrides provider mapping

Less common, but I've seen this in enterprise environments where an IT policy restricts which CNG providers can be used. Also, some VPN or disk encryption software (like McAfee Drive Encryption or BitLocker alternatives) install their own providers and then remove the Microsoft one.

Fix: Check Group Policy and uninstall conflicting software

1. Run gpedit.msc (Pro/Enterprise only). Navigate to Computer Configuration > Administrative Templates > System > Cryptography.
2. Look for a policy called "Configure supported key storage providers" or similar. If it's enabled, verify the Microsoft Software Key Storage Provider is listed. If not, add it as {A1D64B33-2f0b-4adf-9C6E-4F6A8E6B6B8C} (the provider's GUID).
3. If Group Policy isn't the issue, check installed programs for any third-party encryption software that might have hijacked CNG. Uninstall it, reboot.
4. As a last resort, re-run the dism and regsvr32 commands from Fix 1 after removal.

Why this works: Group Policy can override the local provider list. If your admin disabled the Microsoft provider (maybe to force a hardware token), you'll get 0x80090013. Re-enabling it restores the call path. For third-party software, the uninstaller often leaves registry leftovers—running dism after uninstall repairs the system file layer that those apps touched.

Quick-reference summary table

Start with Fix 1. If it works, you're done. If not, move to Fix 2. The registry edit is safe as long as you type the key names exactly—don't guess the GUID, just use the strings I gave you. Fix 3 only applies if you're on a managed PC or you recently installed something that touches encryption. Nine times out of ten, that first command chain sorts it out.