TPM_E_BAD_SIGNATURE 0x80280062 — Real Fix

Your TPM's endorsement key signature doesn't match what Windows expects. Clearing the TPM from firmware usually fixes it, but you'll lose BitLocker keys if you don't back them up first.

Quick answer: Back up your BitLocker recovery key, then clear the TPM from firmware setup or tpm.msc, reboot, and let Windows re-provision the endorsement key.

What's actually happening here is the TPM has a stale or corrupted endorsement key (EK) certificate, so when Windows tries to validate the CMK (Customer Managed Key) ticket, the signature doesn't match. The TPM itself is fine — it's the certificate chain that's gone sideways. This typically shows up after a firmware update, a motherboard swap, clearing CMOS, or pulling the CMOS battery. It also pops up on OEM machines that shipped with a test-signed EK from the factory, or after you migrate a BitLocker-protected drive to a new board. You'll see it in Event Viewer under TPM-WMI, or the failure surfaces as a BitLocker recovery prompt at every boot, Windows Hello refusing to enroll, or tpm.msc showing the TPM as "ready" while every operation that touches the EK fails.

Before you touch anything: grab your BitLocker key

Clearing the TPM destroys the key material stored inside it. If your OS drive is BitLocker-encrypted and you skip this step, you're recovering from your Microsoft account portal or the printed key — assuming you have one.

manage-bde -protectors -get C:

Copy the 48-digit numerical password somewhere that isn't the machine you're about to wipe. Or check aka.ms/myrecoverykey. Don't skip this.

Fix 1: Clear and re-provision the TPM

Suspend BitLocker so the drive doesn't demand a recovery key on the next boot.
```
manage-bde -protectors -disable C: -rc 3
```
Open an elevated PowerShell and check current state.
```
Get-Tpm
```
Look at TpmReady and TpmPresent. If TpmReady is False despite the chip being present, that's your smoking gun.
Clear the TPM. Two paths here. From Windows:
```
Clear-Tpm
```
Or from tpm.msc → Clear TPM. If Windows won't let you, do it from UEFI firmware — Dell calls it "Clear TPM" under Security → TPM 2.0, HP hides it under Security → Trusted Platform Module, Lenovo puts it in Security → Security Chip.
Reboot immediately after clearing. The firmware needs a cold start to hand the TPM back to Windows in an unowned state.
Re-initialize. Windows should auto-provision the new EK on next sign-in. Verify:
```
Get-Tpm
Initialize-Tpm -AllowClear
```
Re-enable BitLocker once Windows Hello and the TPM report healthy.
```
manage-bde -protectors -enable C:
```

The reason step 3 works is that clearing the TPM drops the old, mismatched EK and the vendor's EK certificate, forcing Windows to re-read the certificate from the TPM's NV storage and pull a fresh one if it's missing. The CMK ticket gets re-signed against the new key on the next boot.

Fix 2: Update TPM firmware

If clearing didn't stick — the error comes back after a day or two — the EK certificate stored in the TPM is genuinely bad, not just stale. Several Intel PTT and Infineon TPM 2.0 chips shipped with broken certificate chains around 2017–2018 (Infineon's ROCA vulnerability, CVE-2017-15361, is the famous one). Check your TPM vendor:

Get-Tpm | Select-Object ManufacturerIdTxt, ManufacturerVersion

Then look for a firmware update from your OEM. Dell, HP, Lenovo, and Microsoft Surface all publish TPM firmware updates as regular BIOS updates now. Install it, clear the TPM again, reboot.

Fix 3: Take ownership manually

If Auto-Provisioning keeps failing, disable it and take ownership by hand:

Disable-TpmAutoProvisioning
Clear-Tpm
# reboot
Initialize-Tpm -AllowClear -AllowPhysicalPresence

On some motherboards the physical presence prompt won't fire unless you confirm it in UEFI on the next boot. Watch the POST screen — you'll usually see a "Press F1 to confirm TPM clear" or similar.

Fix 4: Reset the security processor in Windows

Settings → Privacy & security → Windows Security → Device security → Security processor details → Security processor troubleshooting → Clear TPM. That's the same operation as Clear-Tpm, just wrapped in a wizard that walks you through reboots. Use this if you're not comfortable in a shell.

When the fix doesn't hold

If 0x80280062 returns after every clear, the TPM chip itself is failing. Symptom pattern: the error is intermittent, correlates with warm boots, and Get-Tpm occasionally reports TpmReady: False on a chip that was fine yesterday. On Surface devices this is a known hardware fault that Microsoft replaces under warranty. On DIY boards, pull the CMOS battery for five minutes with the PSU unplugged, then reseat it. If that doesn't help, RMA the board.

One more thing that catches people: if you've cloned a BitLocker drive from an old machine onto new hardware, the CMK ticket was sealed to the old TPM. Clearing the new TPM won't help because the encrypted volume itself is tied to the old EK. In that case you need the recovery password to unlock, then manage-bde -off C: to decrypt, then re-encrypt on the new hardware from scratch.

Prevention

Export your BitLocker recovery key to your Microsoft account and print it. Every time. Before any BIOS update, suspend BitLocker first — most firmware updates touch the TPM's NV space and will invalidate the EK if BitLocker is actively sealed. And if you're buying used enterprise hardware, assume the TPM has a stale EK from the previous owner and plan to clear it during your first boot.

Rule of thumb: any time you change firmware, swap a motherboard, or move a drive, clear the TPM before re-enabling BitLocker. Two minutes of prep saves a recovery-key scavenger hunt.