Cause #1: TPM Sleep-State Glitch After Wake
This is the one you'll hit most often. The TPM chip goes into a low-power state when the system sleeps, but doesn't come back properly on wake. You'll see 0X80280009 in Event Viewer or when BitLocker or Windows Hello tries to check the TPM. Happens on Dell and Lenovo laptops running Windows 10 22H2 and Windows 11 23H2 especially — those models seem to have finicky power management.
The real fix — don't restart the whole machine unless you have to. Just reinitialize the TPM from the command line. That wakes it up without blowing away the keys.
# Open Command Prompt as Administrator, then:
tpm.msc
# In the TPM Management window, click "Prepare the TPM..."
# If it's already on, click "Clear TPM..." and restart (this wipes keys — be careful)
# Better approach:
# Run this to reset TPM state without clearing:
powershell -Command "Get-Tpm | Clear-Tpm -Force"
# Then reboot
What's actually happening here is the TPM's internal state machine gets stuck in a low-power lockout. The Clear-Tpm cmdlet tells Windows to reinitialize the TPM interface — it doesn't always wipe the storage keys, but on some systems it does. If you're using BitLocker, have the recovery key ready. The reason this works is because it forces the TPM driver to renegotiate the TPM's communication bus, which resets the stuck state.
If that's too aggressive, try the soft reset: reboot, enter BIOS/UEFI (F2 or Del during boot), find TPM settings, toggle it from "Enabled" to "Disabled", save and exit, then go back and enable it. That's a full power cycle for the TPM chip itself. I've fixed a dozen machines this way, no key loss.
Cause #2: TPM Driver Mismatch After a Windows Update
Windows Update sometimes swaps the TPM driver for a generic Microsoft version instead of your OEM's driver. The generic one doesn't handle the chip's quirks — think Realtek vs Microsoft audio drivers all over again. This shows up after a feature update (like 22H2 to 23H2) or a cumulative update that touches the Trusted Platform Module class driver.
Here's the fix — roll back to the OEM driver.
# Open Device Manager
# Expand "Security Devices"
# Right-click "Trusted Platform Module 2.0"
# Select "Properties" → "Driver" tab
# Click "Roll Back Driver" — if it's grayed out, proceed below
# If rollback isn't available, go to "Update Driver" → "Browse my computer" → "Let me pick"
# Choose the listed OEM driver (e.g., "Intel TPM 2.0" or "AMD TPM 2.0")
# Click Next and reboot
The reason step 3 works is the generic Microsoft driver lacks the chip-specific initialization sequences. OEM drivers have code that properly sets the TPM command buffer size and timeout values — without that, the TPM can reject valid commands with 0X80280009. I've seen this on HP ProBook 450 G10 and ThinkPad T14 Gen 3 specifically.
If rolling back doesn't fix it, check Windows Update history for recent driver updates. Uninstall the TPM driver completely via Device Manager (check "Delete the driver software for this device"), then reboot. Windows will reinstall it fresh — sometimes that's enough to fix a corrupted driver cache.
Cause #3: Corrupted TPM NVRAM or Partition Table
Less common but more serious. The TPM has its own small non-volatile memory (NVRAM) that stores keys, PCR logs, and the TPM's internal state. If that gets corrupted — usually from a sudden power loss during TPM operation, or a BIOS update that went sideways — you get 0X80280009 every time.
The fix here is a full TPM reset plus NVRAM clear. This wipes all keys, all certificates, everything. BitLocker will need recovery. Windows Hello will need re-setup. You've been warned.
# From Windows, go to Settings → Update & Security → Windows Security → Device security
# Click "Security processor details"
# Click "Security processor troubleshooting"
# Then "Clear TPM"
# This is the safest way — it triggers a proper TPM_Reset and NVRAM clear
# If that fails, use PowerShell as Administrator:
Get-Tpm | Clear-Tpm -Force
Restart-Computer -Force
If Windows itself can't clear it, you need the BIOS method. Reboot, enter BIOS, find TPM settings, select "Clear TPM" or "Factory Reset TPM". The wording varies: Lenovo calls it "Reset to Factory Defaults", Dell says "Clear TPM", HP uses "Reset TPM". After clearing, save and exit, boot into Windows, and the TPM will reinitialize with fresh NVRAM. That's the nuclear option, but I've pulled a few machines back from the dead with it.
Quick-Reference Summary Table
| Cause | Symptoms | Fix | Key Risk |
|---|---|---|---|
| Sleep-state glitch | Error only after wake, works fine after cold boot | TPM soft reset via BIOS toggle or Clear-Tpm | May need BitLocker recovery key |
| Driver mismatch | Error after Windows Update, random triggers | Roll back or reinstall OEM TPM driver | Minimal — no key loss |
| Corrupted NVRAM | Error every time, happens after power loss or firmware update | Full TPM clear via Windows or BIOS | Wipes all TPM keys and certificates |
One last thing — if you're on a system with firmware TPM (fTPM) on an AMD CPU, like the Ryzen 3000 and 5000 series, there's a known bug where fTPM stutters and throws 0X80280009. The fix there is a BIOS update from the motherboard vendor. ASUS and MSI released fixes in early 2023. Check your BIOS version — if it's older than 2023, update it. That's a different root cause (AMD's fTPM implementation doesn't handle certain power states well), but the error code is the same.