0x8009002C is Windows telling you it found a key but can't use it. The data's there, the key handle resolves, and then the crypto operation blows up. Nine times out of ten this is a corrupted user profile key store. Had a client last month whose Outlook just stopped loading their S/MIME cert after a power cut mid-update. Same error. Rebuilt the key container, back in business in 10 minutes.
The error string "NTE_DECRYPTION_FAILURE" comes from the CryptoAPI layer. It fires during cert import, EFS file access, Outlook signing, VPN clients doing smartcard auth, and any app leaning on DPAPI. Knowing where you saw it tells you which fix below to grab.
Cause 1: Corrupted user profile crypto key store (the 80% case)
Every Windows user has a hidden key container under %APPDATA%\Microsoft\Crypto\RSA plus a master key set in %APPDATA%\Microsoft\Protect. If either folder gets mangled, half-corrupted, or has bad ACLs, every DPAPI call dies with 0x8009002C. Common triggers: an unclean shutdown during a Windows update, a profile migration done with a copy instead of a proper tool, roaming profiles syncing the Protect folder across machines, or an antivirus that "cleaned" a file it shouldn't have touched.
The fix is to rebuild the user's key material. You can't repair the old keys, but you can regenerate them.
- Log in as the affected user.
- Back up the broken folders first — if there's an encrypted file you still need, those old keys are the only way in. Copy
%APPDATA%\Microsoft\Cryptoand%APPDATA%\Microsoft\Protectto a USB drive. Don't skip this. - Close every app. Outlook, Teams, Edge, VPN clients, anything with a lock or key icon in the tray.
- Rename both folders by adding
.oldto the end. Don't delete yet. - Log out and back in. Windows recreates them on demand.
- Test with a cert import or EFS file access.
If the error clears, you're done. Delete the .old folders after a week of clean operation.
If that didn't work — nuke and recreate the profile
Sometimes the key store itself is fine but the profile registry hive is hosed. Pull the user's data, delete the profile via System Properties > Advanced > User Profiles, and let them log in fresh. Painful but it works. Do this on a Friday afternoon, not a Monday.
Cause 2: Bad certificate or missing private key
You clicked "Import" on a .pfx and Windows threw 0x8009002C. Or your smartcard cert went sideways. This one's usually the cert itself — the private key got generated on a different machine, or the .pfx is password-protected with an algorithm this Windows version doesn't like, or the cert chain is incomplete.
Open certmgr.msc, find the cert, and check the General tab. If it says "You have a private key that corresponds to this certificate" — good, jump to the reimport step. If it says nothing about a private key, the cert is public-only and useless for decryption. You need the original .pfx or a reissue from the CA.
Reimport cleanly:
- Delete the bad cert from Personal > Certificates.
- Run
certmgr.mscas the affected user — not admin. This matters. Importing into the admin store is the number one reason people get 0x8009002C on cert import. - Right-click Personal > Certificates > All Tasks > Import.
- Pick the .pfx. On the password screen, tick "Mark this key as exportable" only if you actually need to move it later. Otherwise leave it off — less attack surface.
- On the next screen, "Automatically select the certificate store" is fine for most cases.
- Finish, then double-click the cert and confirm the private key line appears.
If the import still fails, the .pfx is probably corrupted. Test with certutil -dump yourcert.pfx. Garbage output means the file's bad — get a fresh export.
Smartcard and TPM-backed certs
If the cert lives on a smartcard or in the TPM, 0x8009002C usually means the card reader driver or the TPM itself is having a bad day. Reboot. Reseat the card. Install the vendor's middleware (SafeNet, YubiKey PIV, whatever you've got). For TPM issues, tpm.msc will tell you if the chip is ready or in a weird state. Clearing the TPM is a last resort — it wipes BitLocker keys if you're not careful.
Cause 3: Machine-level DPAPI master key corruption
Rarer, but nasty. If the error shows up for every user on the box, you're not dealing with a user profile issue — the system master key in C:\Windows\System32\Microsoft\Protect\S-1-5-18 is hosed. This kills services that store secrets via DPAPI: scheduled tasks with saved credentials, some backup agents, IIS app pool identities, and a bunch of third-party management tools.
You can't just delete these — the system key is protected by the machine's boot key, which lives in the registry. Rebuilding it is doable but you need to know what you're doing.
- Back up the whole
C:\Windows\System32\Microsoft\Protectfolder to external media. - Back up the registry key at
HKLM\SYSTEM\CurrentControlSet\Control\Lsa— export the whole thing. - Note the value of
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\JDandGBG. These are the boot key components. Export them. - Only then consider deleting the Protect subfolders for the machine SID.
Honestly? If you're at this point and the machine isn't a critical server, reimage it. The time you'll spend chasing orphaned DPAPI blobs across services isn't worth it. I've done this rebuild exactly twice in fifteen years, and both times I wished I'd just wiped the box.
When it's actually a domain controller
Stop. Don't touch DPAPI on a DC without a full AD backup and a change window. A corrupted DC DPAPI store can break Group Policy Preferences passwords across the whole domain. Get Microsoft support on the line before you start renaming folders.
Quick-reference summary
| Symptom | Likely cause | Fix |
|---|---|---|
| Error only for one user, certs and EFS both broken | Corrupted user crypto key store | Rename %APPDATA%\Microsoft\Crypto and Protect, log out/in |
| Error during .pfx import | Bad cert, missing private key, or wrong store | Reimport via certmgr.msc as the user, not admin |
| Smartcard or TPM cert fails | Card middleware or TPM state | Reboot, reseat, reinstall vendor middleware, check tpm.msc |
| Error for every user on the machine | Machine DPAPI master key corruption | Back up, then rebuild system Protect store — or reimage |
| Error on a domain controller | DC DPAPI or LSA issue | Call Microsoft. Back up AD first. Don't improvise. |
Rule of thumb: 0x8009002C is a key problem, not a data problem. Your files are fine. The thing that unlocks them isn't. Back up before you touch anything, and the worst case is a profile rebuild, not data loss.
One more thing — if you're seeing this on a freshly imaged machine that was cloned with Sysprep done wrong, all bets are off. Cloned machines share DPAPI keys and everything falls apart the moment one of them rotates. Run sysprep /generalize properly or use a real deployment tool. That's the root cause more often than anyone wants to admit.