Quick answer: Clear the TPM from tpm.msc or PowerShell, reboot, and let Windows re-provision it — the chip itself is almost never the problem.
I've seen this error probably 60 times over the years, and only twice was it actually hardware. The rest were firmware state that got out of sync with what Windows expects. TPM_E_WRONG_ENTITYTYPE means exactly what it says: the TPM received a command referencing an entity type (a key, a nonce, an NV index, an auth session) that it doesn't consider valid in its current state. Translated from TPM-speak: Windows asked the chip for something the chip no longer has, or has under a different type.
You'll typically hit this in three scenarios. First, right after a firmware update where Secure Boot keys got re-enrolled but the TPM still holds stale entries. Second, when you clone a drive from one machine to another — Windows Hello, BitLocker, and device encryption keys reference a TPM that no longer exists. Third, after a Windows feature update (22H2 to 23H2, or 23H2 to 24H2) when the TPM owner auth got out of sync. Dell OptiPlex 7090s and Lenovo ThinkPad T14 Gen 2 units seem to pop this most often in my ticket queue, but I've seen it on custom builds too.
Before you do anything, back up your BitLocker recovery key. If the drive is encrypted, clearing the TPM will lock you out until you enter the recovery key at boot. Get that key from account.microsoft.com/devices/recoverykey or your AD/Entra ID console first. This is not optional.
Fix 1: Clear the TPM and let Windows re-provision it
This resolves the error about 80% of the time. You're telling the TPM to wipe its internal hierarchy and start over — Windows will reinitialize it on next boot.
- Press
Win + R, typetpm.msc, hit Enter. - In the right pane, click Clear TPM.
- You'll get a prompt about restarting. Save your work, then reboot.
- On the next boot, Windows shows a TPM initialization screen. Press F12 (or whatever your firmware says) when prompted, then let it finish.
- Sign in and check
tpm.mscagain — status should read "The TPM is ready for use."
If Clear TPM is grayed out, the chip is already owned or disabled by policy. Jump to Fix 2.
Doing it in PowerShell instead
Same result, sometimes more reliable when the GUI hangs:
# Run PowerShell as Administrator
$tpm = Get-Tpm
$tpm | Select-Object TpmReady, TpmPresent, TpmEnabled, TpmOwned
# Clear it
Clear-Tpm
# Reboot
Restart-Computer
If Clear-Tpm throws an access denied error, your TPM has an owner auth you don't have. You'll need to reset it from firmware — see Fix 4.
Fix 2: Check Secure Boot and firmware TPM settings
I know this error is infuriating because it looks like a hardware failure. It usually isn't. Half the calls I take end with "oh, Secure Boot got toggled off during that BIOS update."
- Reboot and enter firmware setup (
F2,F10,Del, orEscdepending on vendor). - Find the Security section. On Dell it's Security > TPM 2.0 Security. On HP it's Security > TPM Embedded Security. On Lenovo it's Security > Security Chip.
- Verify TPM is Enabled and Active (not just Enabled).
- Verify Secure Boot is On and in Standard or User mode, not Setup mode.
- Save and exit. Boot Windows, re-run
tpm.msc.
If Secure Boot is stuck in Setup mode, the Platform Key was cleared. You'll need to restore factory keys from the same menu — usually labeled Restore Factory Keys or Reset to Setup Mode then Enroll PK.
Fix 3: Rebuild the Windows Hello / BitLocker binding
If clearing the TPM didn't take, the leftover credential is the problem. Windows Hello and device encryption both store a key handle that points to an entity type the TPM no longer recognizes. Nuke it and rebuild.
- Go to Settings > Accounts > Sign-in options.
- Under Windows Hello, remove PIN, then remove face/fingerprint.
- Reboot.
- Set them up again from scratch.
For BitLocker, if the drive is still encrypted and you're getting this on unlock, suspend BitLocker, clear the TPM, reboot, then resume protection:
Suspend-BitLocker -MountPoint "C:" -RebootCount 2
# Reboot, clear TPM, reboot again
Resume-BitLocker -MountPoint "C:"
Fix 4: Reset the TPM from firmware when nothing else works
Sometimes the TPM has an owner auth from a domain, a management tool, or a previous OS install, and Windows can't clear it. You have to reset it at the hardware level.
- Enter firmware setup.
- Find the TPM section.
- Choose Clear TPM — not the same as disabling. It wipes ownership.
- If that's grayed out too, disable TPM, save, reboot, enter setup again, re-enable, save, reboot.
- Boot Windows and check
tpm.msc.
On some older motherboards (pre-2018), you'll see a physical Clear CMOS jumper or, on some Gigabyte boards, a dedicated TPM reset pad. Check your manual. The clear instructions I've seen for MSI B450 boards, for example, require shorting the TPM header for 5 seconds with power disconnected.
Fix 5: Check for firmware and chipset driver updates
I'll be opinionated here: if you're on a Dell Latitude 7420 or an HP EliteBook 840 G8 with this error, just update firmware first. Both vendors shipped TPM firmware fixes in 2022 and 2023 that resolve entity-type mismatches after BIOS updates. Dell Command Update and HP Image Assistant will find them. For everyone else, download the latest BIOS and chipset driver from your motherboard vendor — don't trust Windows Update for this.
After flashing, boot back in, run tpm.msc, and confirm the spec version reads 2.0 with a manufacturer listed. If it still says "Compatible TPM cannot be found," you've got a real hardware issue and it's RMA time.
Prevention
Two things. First, export your BitLocker recovery key to a place you can actually reach from a phone — a lot of people only save it to the encrypted drive, which is useless. Second, before any BIOS update, suspend BitLocker and note your TPM ownership state. Firmware updates are by far the most common trigger for this error, and doing those two steps takes 90 seconds. I've watched people lose a whole afternoon because they skipped it.
One more thing: if this is a corporate machine under Intune or Group Policy, don't clear the TPM without checking with IT. Clearing it wipes the attestation identity, and your device may lose conditional access until it re-enrolls.