0X8028005E

Fix TPM_E_MA_SOURCE (0x8028005E) – Migration source incorrect

Windows Errors Intermediate 👁 1 views 📅 May 28, 2026

Your TPM key can't be migrated because the source is wrong. We'll fix this in under 30 seconds or go deeper if needed.

What's actually happening here

Error 0x8028005E with message TPM_E_MA_SOURCE means the TPM thinks the key you're trying to migrate came from a different TPM or a different system. This usually pops up when you're working with BitLocker, virtual smart cards, or any TPM-protected key that needs to move between machines. The TPM is essentially saying, "I don't trust where this key came from."

I've seen this most often after cloning a VM, restoring a system image to different hardware, or swapping a motherboard without clearing the TPM first. If you're dealing with a physical PC, it's usually a bad TPM provisioning state.

Simple fix (30 seconds) – Clear TPM via tpm.msc

This is the first thing to try. You'll lose any keys stored in the TPM (like BitLocker keys), so have the recovery key handy if BitLocker's active.

  1. Press Win + R, type tpm.msc, hit Enter.
  2. In the right-hand pane, click Clear TPM. You'll need to restart.
  3. During the restart, your BIOS will ask you to confirm the clear. Hit F12 (or whatever key the screen says).
  4. After Windows boots, the TPM will re-initialize automatically. Your error should be gone.

The reason this works: clearing the TPM resets the endorsement key and the migration authority. Any mismatched source hash gets wiped. It's like factory resetting the chip.

Moderate fix (5 minutes) – Use manage-bde to force-remove TPM protectors

If the simple clear didn't work—or you can't clear the TPM because of group policy—we can target the specific BitLocker volume that's causing the grief.

  1. Open an elevated Command Prompt (right-click Start, choose Command Prompt (Admin) or Terminal (Admin)).
  2. Run manage-bde -status to see which volumes have TPM protectors.
  3. If the system drive (C:) shows a TPM protector, remove it with:
    manage-bde -protectors -disable C:
    This doesn't decrypt the drive, just disables the TPM protector temporarily. You'll get a pop-up confirmation – restart when you're ready.
  4. After reboot, re-enable the protector:
    manage-bde -protectors -enable C:
    This forces the TPM to re-create the migration authority for that volume.

If you get an access denied error here, you likely need BitLocker recovery. Use your 48-digit recovery key first via manage-bde -unlock C: -RecoveryPassword followed by the key.

Advanced fix (15+ minutes) – Reprovision the TPM from scratch

When both above fail, the TPM's internal state is truly corrupted for migration purposes. We'll nuke it from PowerShell and rebuild.

Warning: This will wipe all TPM keys. Have your BitLocker recovery key saved elsewhere—not on this drive.

  1. Boot into Windows Recovery Environment (hold Shift while clicking Restart, or boot from a Windows install USB).
  2. Open a command prompt: TroubleshootAdvanced OptionsCommand Prompt.
  3. Run
    tpmtool clear
    . This is Windows 10/11's built-in TPM clearing tool. It's more thorough than tpm.msc because it doesn't rely on the current Windows TPM driver stack.
  4. If that fails with an "access denied" or "TPM is not present" error, you need to clear from the UEFI/BIOS. Reboot, mash Del or F2 to enter BIOS, find the TPM submenu (varies by vendor: Intel PTT, AMD fTPM, or dedicated TPM). Look for Clear TPM or Factory Reset TPM.
  5. After clearing, boot back into Windows and open PowerShell as admin. Run:
    Initialize-Tpm -AllowClear -AllowPhysicalPresence
    This re-initializes the TPM with a fresh endorsement key and migration authority.
  6. Now re-enable BitLocker protectors if you need them:
    manage-bde -protectors -addition C: -TPM
    That adds a fresh TPM protector with a correctly linked migration source.

Why this works where the other steps don't: tpmtool clear and BIOS-level clearing bypass any OS-level policy that might block the clear. The Initialize-Tpm cmdlet then sets up the TPM from a completely clean state, guaranteeing the migration source hash is generated fresh.

When to just give up and replace the motherboard

If you've done all three steps and still get 0x8028005E, the TPM hardware itself might be failing. I've seen this on early Intel Skylake systems (Lenovo ThinkPad T460, Dell Optiplex 7040) where the TPM chip developed a fault. In that case, the only real fix is a motherboard replacement or disabling the TPM in BIOS and using a software-based solution (like BitLocker with a startup PIN).

One last check: run tpmtool getdeviceinformation in PowerShell. If the TPM manufacturer is "Microsoft" or "Simulator", you're on a VM that doesn't have a real TPM—you can't expect migration to work across hosts.

Was this solution helpful?