NTE_BAD_VER (0x80090007): Bad version of provider

Cause 1: Corrupted Microsoft Platform Crypto Provider registry key

What's actually happening here is that Windows can't load the cryptographic service provider (CSP) because the registry entry for Microsoft Platform Crypto Provider points to a non-existent or wrong version. This usually shows up when you run a BitLocker command, PowerShell's Get-Tpm cmdlet, or an app that calls the TPM. The error text — Bad version of provider — is literal: Windows finds the provider but its version number in the registry doesn't match what the system expects.

I've seen this most often on Windows 11 22H2 machines that went through a feature update. The update leaves the old provider registry key behind while the new provider DLL is already installed. The system picks up the old key first, sees version 10.0.19041 instead of 10.0.22621, and throws 0x80090007.

Fix: Re-register the provider via registry

1. Press Win+R, type regedit, hit Enter.
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Platform Crypto Provider.
3. Double-click Image Path. Ensure the value is exactly %SystemRoot%\System32\securekernel.dll. If it's anything else — like a path to an old sys file — fix it.
4. Now check Type — it should be 1 (REG_DWORD). If it's missing or wrong, set it to 1.
5. Close regedit, reboot.

After the reboot, run certutil -csplist in an admin PowerShell. If the provider shows up without errors, you're good. If not, move to cause 2.

Cause 2: Corrupt or outdated TPM driver

The reason cause 1 can fail is that sometimes the registry is fine, but the driver itself is broken. The TPM driver stack in Windows uses two layers: tpm.sys (the kernel driver) and securekernel.dll (the user-mode provider). If one of them is from a different build — like you manually installed an OEM driver that's newer than the OS build — the version check fails. You get the exact same 0x80090007.

I've seen this happen after a BIOS update that shipped a new TPM firmware, but Windows didn't update its driver to match. The TPM hardware reports a newer firmware version, the driver tries to use an older interface, and the provider spits out "bad version." Another common scenario: you uninstalled a security tool like McAfee or Symantec that replaced the TPM driver with its own stub.

Fix: Force reinstall the Microsoft TPM driver

1. Open Device Manager (devmgmt.msc).
2. Expand Security Devices — look for Trusted Platform Module 2.0 (or 1.2 if you're on older hardware).
3. Right-click it, select Uninstall device. Check Attempt to remove the driver for this software if it appears.
4. Reboot. Windows will automatically reinstall the built-in Microsoft driver.
5. After reboot, check the driver version in Device Manager > Driver tab. It should match your Windows build number — e.g., 10.0.22621.x for Windows 11 22H2.

If that doesn't work, you can manually install the driver from the %SystemRoot%\System32\DriverStore\FileRepository\tpm.inf_amd64_... folder. Find the folder with tpm.inf, right-click it, select Install. But honestly, the uninstall-reboot dance works 9 times out of 10.

Cause 3: Third-party cryptographic provider overriding the Microsoft one

This one's trickier. Some enterprise security software — especially VPN clients and disk encryption tools — register their own cryptographic providers that sit in front of the Windows TPM provider. When their version is off (because of an update that didn't re-register, or because they target a different Windows version), you get the 0x80090007. I've seen this with older versions of McAfee Drive Encryption and Symantec Endpoint Encryption.

The symptom here is specific: the error only occurs when a specific app runs, not system-wide. You'll see the error in Application event logs under the app's provider name, not under Microsoft.

Fix: Identify and remove the offending provider

1. Open an admin PowerShell. Run certutil -csplist.
2. Scroll through the list. Look for any provider whose name includes the third-party software — like McAfee Crypto Provider or Symantec Crypto Provider.
3. If you find one, note its name. Then run certutil -delstore -csp "Provider Name" to remove it.
4. Now check if the error still occurs. If it does, you may need to reinstall the third-party software from scratch — their installer should re-register a correct version.

One real-world case: a user had Cisco AnyConnect installed. After a Windows update, AnyConnect's VPN module registered its own provider with a hardcoded version string. Since the Windows build changed, the version mismatch triggered 0x80090007 every time AnyConnect tried to use TPM for certificate storage. Reinstalling AnyConnect fixed it.

Quick-reference summary table

If none of these work, check if your TPM firmware is up to date from the motherboard vendor. I've seen one case where an Intel NUC had TPM 2.0 firmware version 5.0 but Windows required 7.0 — the vendor provided a firmware update that resolved the 0x80090007 immediately.