NTE_BAD_PUBLIC_KEY (0x80090015) — Fix invalid provider public key

When you'll see this error

You're unlocking a BitLocker drive, importing a certificate into the Personal store, or maybe setting up Windows Hello PIN. Suddenly you get: NTE_BAD_PUBLIC_KEY (0x80090015) — "The provider's public key is invalid." The exact wording might say "The provider's public key is invalid" or just the hex code.

I've seen this most often after a system restore from a backup that didn't carry over the CNG key storage properly. Second most common trigger: manually moving or deleting files inside %APPDATA%\Microsoft\Crypto\Keys or C:\ProgramData\Microsoft\Crypto\Keys. Third: a registry editor script that modifies HKLM\SOFTWARE\Microsoft\Cryptography\Providers incorrectly.

What's actually happening here

Windows uses the Cryptography Next Generation (CNG) API to store private keys and public key pairs. Each key is stored as a file in one of those Crypto\Keys folders, with a metadata pointer in the registry under HKLM\SOFTWARE\Microsoft\Cryptography\MachineKeys or HKCU\SOFTWARE\Microsoft\Cryptography\UserKeys.

The error means the CNG provider (like Microsoft Software Key Storage Provider, or TPM-based provider) tried to load the public key blob from disk, but the data didn't match what the provider expected. The blob's header is wrong, the algorithm identifier is garbage, or the key length is zero. It's not a permissions issue — those give a different error. This is a data integrity failure.

Why does this happen? Usually because the key file got partially overwritten, truncated, or a registry pointer now points to a file that doesn't exist or has a mismatched name. Another cause: you imported a certificate that was encrypted with a different provider (e.g., a legacy CSP key into a CNG-only store). The provider can't parse the old blob format.

The fix — step by step

Before you start: this will remove the broken keys. If this is a BitLocker key, you need the recovery key (48-digit numeric) or a different unlock method. If it's a personal certificate, you'll need to re-import from a .pfx with the private key. Back up your keys first if possible — export any working certs to .pfx with private key.

Open an elevated PowerShell prompt. Right-click Start, select Windows PowerShell (Admin) or Terminal (Admin). Confirm the UAC prompt.

Identify the broken key. Run this to list machine-wide keys that are orphaned (no matching file):

Get-ChildItem -Path 'HKLM:\SOFTWARE\Microsoft\Cryptography\MachineKeys' -Recurse | ForEach-Object {
  $guid = $_.PSChildName
  $path = "$env:ProgramData\Microsoft\Crypto\Keys\$guid"
  if (-not (Test-Path -PathType Leaf $path)) {
    Write-Output "Orphan registry entry: $guid"
  }
}

For user keys (your current user), replace HKLM with HKCU and $env:ProgramData with $env:APPDATA. If you see orphans, the registry pointer is stale.

Delete the orphaned registry keys. Only do this if you're sure the key file is gone or corrupt. For each orphan GUID:
```
Remove-Item -Path 'HKLM:\SOFTWARE\Microsoft\Cryptography\MachineKeys\' -Force
```
The reason step 3 works: CNG regenerates the provider key when needed — only if the registry entry is gone. If the entry points to a corrupt file, Windows keeps trying to load that corrupt blob.

If no orphans exist, check the key files themselves for corruption. Run:

Get-ChildItem -Path "$env:ProgramData\Microsoft\Crypto\Keys" -Name | ForEach-Object {
  $size = (Get-Item "$env:ProgramData\Microsoft\Crypto\Keys\$_").Length
  if ($size -lt 100) {
    Write-Output "Suspicious small key file: $_ ($size bytes)"
  }
}

Normal CNG key files are between 200 and 1500 bytes. Anything under 100 is likely truncated. A 0-byte file is definitely corrupt.

Delete corrupt key files. For each file under 100 bytes (after verifying it's not in use — check with Handle.exe from Sysinternals or reboot first):
```
Remove-Item -Path "$env:ProgramData\Microsoft\Crypto\Keys\" -Force
```
Then remove the corresponding registry entry under MachineKeys or UserKeys (use step 2's script to find the matching GUID). Reboot.
Re-import or regenerate the key. For BitLocker: use the recovery key to unlock, then change the PIN or password. For certificates: import the .pfx again. For Windows Hello: go to Settings > Accounts > Sign-in options, remove and re-add PIN. This forces CNG to create a fresh key pair.

If it still fails — two more things to check

Provider mismatch in certificate import

If you're importing a .pfx and get 0x80090015, the certificate was originally generated by a different cryptographic provider. For example, a certificate from a hardware security module (HSM) or a legacy CryptoAPI CSP. The CNG provider can't parse it. Solution: export from the source system using "Microsoft Software Key Storage Provider" explicitly. Or convert the key using openssl pkcs12 and specify -keypbe NONE -certpbe NONE -nomaciter to strip provider-specific wrapping.

TPM key corruption

If the error appears when BitLocker tries to use TPM-based protector (the "TPM only" unlock method), the TPM itself may have a corrupted key. Try: Disable-BitLocker -MountPoint "C:" (requires recovery key), then re-enable with TPM-only protector. This clears the TPM's key cache for that volume. Don't clear the entire TPM — that wipes all keys and stored passwords.

Bottom line

The error is almost always a corrupt key file or a registry pointer to a missing file. The fix is to remove the dead entries and let Windows start fresh. Don't waste time with SFC or DISM — they won't touch CNG key files. And don't delete all key files — just the ones that are clearly broken. You'll know you got the right one when the error stops appearing and the operation completes normally.