TPM_E_BAD_DELEGATE 0X80280059 Fix — Clear TPM & Re-provision

You're setting up a new Dell Latitude, or you just replaced a motherboard, or you finally ran that BIOS update you'd been putting off. You boot Windows 11, try to enroll Windows Hello face or PIN, and it dies with 0X80280059 — TPM_E_BAD_DELEGATE. Or BitLocker provisioning hangs and the event log fills with the same code. The TPM is physically fine. Windows just can't create the delegation it needs to hand off crypto ops to it.

I had a client last month — a 40-seat dental office — where three brand-new Lenovo T14s Gen 4s all threw this on first boot. Same image, same BIOS version, same everything. Two of them were fine. The third kept failing until I cleared the TPM. That's the pattern: the hardware's healthy, the state is bad.

What TPM_E_BAD_DELEGATE actually means

TPM 2.0 uses delegations — think of them as signed permission slips. Windows (or a service like Windows Hello, BitLocker, or Credential Guard) creates a delegation that says "the OS may perform these specific TPM operations without prompting." When Windows tries to read or use that delegation, the TPM looks at the stored blob and goes "nope, this doesn't match my internal state."

That mismatch happens when:

The TPM was cleared (or auto-cleared by firmware) but Windows still has stale delegation records cached.
A BIOS/firmware update reset the TPM's internal hierarchy state.
The TPM was owned by a previous OS install, or by a corporate provisioning profile, and the ownership didn't transfer cleanly.
Secure Boot state changed (toggled on/off/on) and invalidated PCR-bound delegations.
You cloned a drive from one machine to another — the delegation blob on disk points at a TPM that no longer exists.

The error itself is a Win32/CryptoAPI code. TPM_E_BAD_DELEGATE = the delegate family is wrong, corrupted, or the TPM can't find a matching entry for the handle you passed. Windows doesn't auto-heal this. You have to reset state on both sides.

The fix — clear the TPM and re-provision

Before you start: if BitLocker is on, suspend it first. Clearing the TPM with BitLocker active will lock you out and you'll be typing a 48-digit recovery key at boot. Suspend, don't disable.

manage-bde -protectors -disable C: -rebootcount 2

That suspends protection for two reboots — enough to do the surgery and boot once clean.

Verify the TPM is present and enabled. Open tpm.msc (Win+R). If it says "The TPM is ready for use," good. If it says "not found," you've got a BIOS problem, not this error — go enable the TPM (fTPM on AMD, PTT on Intel) in firmware first.
Check the spec version. Run Get-Tpm in an admin PowerShell. You want TpmPresent : True, TpmReady : True, and you should see SpecVersion 2.0. If it's 1.2, stop — this error behaves differently on 1.2 and you should update firmware.
Clear the TPM. Two ways. GUI: tpm.msc → right pane → Clear TPM. CLI:
```
Clear-Tpm -Verbose
```
You'll get a reboot prompt. Take it. If Windows asks for the TPM owner password and you don't have it, that's fine on modern devices — the OS manages ownership and can clear without it.
Re-provision the TPM. After reboot, open admin PowerShell:
```
Initialize-Tpm -AllowClear -AllowPhysicalPresence
```
This re-creates the storage root key and re-establishes the delegations Windows needs. On some machines you'll see "the TPM is already initialized" — that's fine, it means the clear already handled it.
Re-enable BitLocker protection. If you suspended it earlier:
```
manage-bde -protectors -enable C:
```
Reboot and test. Now try the Windows Hello enrollment or whatever triggered the error originally.

Skip the registry "fixes" you see on random forums that tell you to delete keys under HKLM\SYSTEM\CurrentControlSet\Services\TPM. That's how you brick the TPM service and end up reimaging the machine. The clear-and-reinitialize path is the real fix.

If it still fails after clearing

Work through these in order:

Check BIOS version. Dell, HP, and Lenovo all shipped TPM firmware bugs in 2022-2023 that broke delegation on AMD fTPM. If your BIOS is older than mid-2023, update it. This is the single most common cause when a fresh clear doesn't stick.
Look at the TPM event log. In tpm.msc, the event log viewer on the right pane shows exactly which operation failed and often names the caller. If it's Credential Guard or VBS, you may need to disable VBS temporarily, clear, re-enable.
Disable and re-enable the TPM in BIOS. Yes, actually power down, go into firmware, turn the TPM off, save, boot once, power down, turn it back on. This forces a full hardware reset the OS-level clear can't always reach.
Rule out a cloned image. If this machine was imaged from another device, the TPM state on disk may still reference the old machine's hierarchy. Sysprep with generalize, or do a clean install. Cloning TPM-bound systems is asking for this exact error.
Check group policy. In a domain environment, Computer Configuration → Administrative Templates → System → Trusted Platform Module Services can lock down delegation creation. If your domain pushes a policy that blocks OS-managed TPM, you'll hit this every time. Ask your AD admin.
Last resort: BIOS reset to defaults and re-run the clear. I've seen three machines this year where the only thing that fixed it was loading BIOS defaults — some prior setting had left the TPM in a weird state that neither Windows nor the vendor utility could describe.

If you've done all of the above and it still throws 0X80280059, the TPM itself is suspect. That's rare — maybe one in fifty cases — but it happens. Swap the board or RMA the device. Don't waste a day trying to resurrect a dying TPM chip.