This error means your TPM's non-volatile RAM is full of writes — and Windows locked it down.
I know you're staring at that 0X80280048 code and thinking your motherboard's about to die. It's not. I've seen this on Dell OptiPlex 7080s, Lenovo ThinkCentre M90q, and even a custom gaming rig with an ASUS ROG board. The error triggers when you've repeatedly tried to provision the TPM, change BIOS settings, or install a new OS without clearing the TPM first. The TPM has a finite number of NV writes — usually around 50,000 — but firmware bugs or improper shutdowns can exhaust the counter early.
The Real Fix: Clear the TPM
Two ways to do this. Pick the one that fits your situation.
Method 1: Clear from Windows (if you can still boot)
- Press Win + R, type
tpm.msc, hit Enter. - In the right pane, click Clear TPM. You'll need to restart.
- During restart, the BIOS will prompt you to press F12 (or whatever key your board uses) to confirm. Do it.
That's it. The TPM resets, the NV write counter resets to zero, and Windows will re-initialize the TPM on next boot. Had a client last month whose whole print queue died because of this — they'd been re-enrolling Windows Hello ten times trying to fix a fingerprint reader. Clear fixed it in 30 seconds.
Method 2: Clear from BIOS (if you can't boot or tpm.msc hangs)
- Reboot and mash F2, Del, or F10 to enter BIOS.
- Look for Security → TPM or Trusted Computing.
- Select Clear TPM or Factory Reset TPM. Save and exit.
On some Dell systems, you need to toggle the TPM state to Disabled, save, reboot, then re-enable it. That's brute force — it works when the menu option is greyed out.
Why This Works
The TPM's NV storage is like a tiny SSD inside the chip. Every time you write a new PCR value, change an owner authorization, or store a key, it uses one write cycle. The counter is there to prevent wear-out, but firmware doesn't always decrement it correctly. Clearing the TPM resets that counter and also wipes all stored keys — your BitLocker keys included. So if you're using BitLocker, back up your recovery key first. Run manage-bde -protectors -get C: in an admin command prompt and save that 48-digit number.
Less Common Variations of This Error
Sometimes the error code is 0x80280048 without the TPM_E prefix. Same fix. But there are edge cases:
- BitLocker won't turn on: The TPM reports the error when you try to enable BitLocker. Clear TPM, then re-enable. I've seen this on HP EliteBooks after a BIOS update that corrupted the TPM firmware.
- Windows Hello / PIN setup fails: The TPM rejects writes because the counter is maxed. Clearing the TPM via the Settings app (Accounts → Sign-in options → Security Key → Manage) also works, but I've found it fails more often than tpm.msc.
- PCR bank mistakes: If you're running a custom TPM configuration (like enabling SHA256 PCR banks on an older TPM 2.0 chip), the firmware might incorrectly increment the write counter for every PCR bank switch. The only fix is to clear TPM and leave PCR banks at their default (usually SHA1).
One more: on some AMD systems (like the ASUS ROG Strix X570), a BIOS update can trigger this error because the TPM firmware doesn't properly handle NV write quotas after a reset. In that case, do a full CMOS clear (remove the battery for 10 minutes) before clearing TPM. It's annoying but it works.
Prevention
Don't repeatedly clear the TPM. It's like rebooting your router — once in a while is fine, but doing it ten times a week will wear out the NV storage. Specific rules I follow:
- Only clear TPM when absolutely necessary (like this error, or when selling the machine).
- Enable TPM once during initial setup and leave it alone. Don't toggle it off and on to troubleshoot boot issues.
- Keep BIOS up to date. Lenovo and Dell both released firmware patches in 2022 that fixed NV write counter bugs. Check your manufacturer's site.
- If you're using BitLocker, never suspend protection by clearing TPM — use
manage-bde -protectors -disable C:instead. That only stops the TPM from unlocking the drive without writing to NV storage.
And if you're a tinkerer who changes PCR banks or ownership authority frequently, stop. The default settings are fine for 99.9% of users. I had one client who ruined a TPM on a Surface Pro 7 by manually assigning a new owner authorization 200 times in a day (he was testing a script). Chip couldn't recover; had to replace the motherboard. Learn from his mistake.