0X8028004F

TPM_E_OWNER_CONTROL (0x8028004F) Fix for Key Save Fail

This error pops up when TPM can't save a key because owner auth is missing. Clearing TPM or resetting owner control usually fixes it.

You're stuck with this TPM error. Let's cut to the fix.

The error 0x8028004F shows up when something tries to save a TPM key — like BitLocker, Windows Hello, or a virtual TPM in Hyper-V — but the TPM chip says "no, you don't have owner permission." It's not a hardware failure. It's a permission problem inside the TPM.

I've seen this on Windows 10 22H2 and Windows 11 23H2, especially after a BIOS update or a motherboard swap. The TPM remembers the old owner, and the new OS doesn't have the password. Here's how to kill it.

Step 1: Clear the TPM (quick fix, wipes all keys)

This is the nuclear option. It resets the TPM to factory state — removes all keys, including BitLocker, Windows Hello, and virtual TPMs. You'll need to re-setup those services.

  1. Press Win + R, type tpm.msc, hit Enter.
  2. In the TPM Management console, click Clear TPM on the right sidebar.
  3. Restart your PC. It'll ask you to press F12 (or whatever key your BIOS says) to confirm the clear. Do it.
  4. After Windows boots, the TPM is fresh. The error should be gone.

But wait — if you use BitLocker, you'll need your recovery key. Have it handy. Without it, you lose the drive.

Step 2: Reset owner control without clearing (safer)

If you can't or don't want to clear the TPM, you can reset just the owner authorization. This keeps existing keys working.

  1. Open PowerShell as Administrator.
  2. Run Clear-Tpm -Force. This removes the owner password but keeps keys.
  3. Run Initialize-Tpm -AllowClear. This sets a new owner password automatically.
  4. Reboot.

What's happening here: Clear-Tpm clears the owner auth value but leaves the key hierarchy intact. Then Initialize-Tpm creates a new owner password (stored by Windows in the registry). The error goes away because the OS now has valid owner permission for saving keys.

Why this error happens — the real cause

The TPM has a concept called "owner authorization." It's a password (actually a hash) that proves you own the TPM. When your OS tries to save a key — like during a BitLocker startup or a virtual TPM checkpoint — it sends this auth along with the key data. If the TPM doesn't recognize the auth, it spits out 0x8028004F.

Three common triggers:

  • BIOS update — the update often leaves TPM in a state where the old owner auth doesn't match the new firmware's expectation.
  • Motherboard swap — same chip, but the system board change resets TPM state without clearing the owner.
  • Hyper-V virtual TPM — moving a VM between hosts can break the vTPM owner auth. The error pops up when saving VM state.

Less common variations

Variation 1: Virtual TPM in Hyper-V

If you get this error inside a VM, the fix is different. Don't clear the host TPM. Instead:

  1. Open PowerShell on the Hyper-V host as Admin.
  2. Run Repair-VM -Name "YourVMName" -RepairType Tpm. This regenerates the vTPM key.
  3. Start the VM again.

The reason step 2 works: It creates a new vTPM instance with fresh owner auth. The old corrupt one is tossed.

Variation 2: Windows Hello after TPM clear

After clearing the TPM, Windows Hello may complain about "something went wrong." That's because its key is gone. You'll need to remove and re-add your PIN or fingerprint:

  1. Go to Settings > Accounts > Sign-in options.
  2. Under Windows Hello PIN, click Remove.
  3. Reboot, then add a new PIN.

This re-creates the key in the fresh TPM.

Variation 3: BitLocker recovery loop

If you clear the TPM and BitLocker asks for recovery key every boot, it means the drive encryption key was stored in TPM and got wiped. Enter the recovery key, then suspend and re-enable BitLocker:

  1. In an admin cmd: manage-bde -protectors -disable C:
  2. Reboot — it'll boot without asking.
  3. Then run manage-bde -protectors -enable C: — this re-writes the key to TPM with new owner auth.

Prevention — don't let it happen again

This error is almost always caused by a change in the TPM's relationship with the OS. To avoid it:

  • Before a BIOS update, suspend BitLocker first (manage-bde -protectors -disable C:). After the update, re-enable it.
  • Before swapping a motherboard, back up your BitLocker recovery key (print it or save to Microsoft account). Then clear TPM from the old board first (via BIOS).
  • With Hyper-V VMs, don't move VMs with vTPM between different host models. Export/import properly using the Hyper-V manager's export function.
  • Regular maintenance: You can check TPM health with Get-Tpm in PowerShell. If it shows IsEnabled: True and IsActivated: True, you're good. If IsOwned: True but you didn't set it up manually, something's off — investigate.

One more thing: Windows 11 requires TPM 2.0. If you're on a system that's flaky with TPM (like some early AMD Ryzen boards), consider updating your chipset drivers and BIOS to the latest stable version. Bad firmware can corrupt TPM owner state randomly.

That's it. The error is annoying but fixable in five minutes. Don't replace hardware over this — it's software state, not a dead chip.

Related Errors in Windows Errors
0XC00002E7 Domain join fails: 0XC00002E7 – machine account quota hit 0XC01E033C STATUS_GRAPHICS_INVALID_STRIDE Fix (0xC01E033C) 0X0000045D 0X0000045D I/O Device Error: Fix USB & Drive Failures Windows Cannot Repair This Drive – chkdsk Failed Fix

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.