You're running a TPM provisioning script or a tool like Get-Tpm in PowerShell, and suddenly it throws TBSIMP_E_PPI_NOT_SUPPORTED (0x80290219). The exact scenario: you've just enabled TPM 2.0 in the UEFI firmware on a desktop motherboard (often an ASUS or MSI board), Windows boots fine, but any command that touches the TPM's Physical Presence Interface fails with this code. It also appears when you try to clear TPM keys using Clear-Tpm or attempt to set the owner authorization via the Windows Security app.
What's actually happening here is that the TPM Base Services (TBS) layer is trying to call GetPhysicallyPresent or similar, and the TPM firmware returns a status saying the Physical Presence Interface (PPI) isn't supported. PPI was designed for laptops with embedded TPMs, where the OS can trigger a firmware operation (like clearing the TPM) by writing to an ACPI method. Desktop boards with discrete TPM modules often don't implement that ACPI method, so the TPM returns PPI_NOT_SUPPORTED. The TBS library just passes that through as 0x80290219.
The reason this error is so frustrating is that it's not a sign your TPM is broken. The TPM itself works fine for normal operations like BitLocker or storing keys. It's only the PPI-specific calls that fail. So if you're hitting this, you're trying to do something that requires physical presence confirmation, and your motherboard doesn't give the OS a way to do that.
What you can do about it
First, check if you actually need PPI. For most tasks, you don't. BitLocker, Windows Hello, and standard key attestation don't rely on PPI. You only need PPI if you're trying to clear the TPM or change its ownership from within Windows. If that's your case, here's the workaround.
Step 1: Try the UEFI/BIOS approach
For clearing the TPM, the cleanest fix is to do it from the firmware. Reboot, enter UEFI setup (usually by pressing Del or F2 during POST), find the TPM settings (often under Advanced → Trusted Computing or Security). Look for an option like "Clear TPM" or "Factory Reset." Select it, save and exit. The firmware will clear the TPM without needing any OS-level PPI call. This works on basically every board with a discrete TPM header.
If your firmware doesn't have a clear option, you can do a CMOS reset. Power off, unplug the power cord, remove the CMOS battery for a minute, then put it back. That wipes TPM state on most boards (though on some, it might also reset your boot order).
Step 2: If you must use Windows, use the TPM MMC
Open tpm.msc (press Win+R, type tpm.msc, hit Enter). In the right pane, look for "Actions" and see if "Clear TPM..." is available. If it is, click it. The screen will prompt you to restart and confirm with a keypress during boot. That bypasses the PPI call because it uses a different path—the TBS library can still initiate a clear if the firmware supports a separate method. If that option is grayed out, you're stuck with the firmware route.
Step 3: For scripts, handle the error gracefully
If you're writing a PowerShell script that provisions a TPM and you're hitting 0x80290219 when running Initialize-Tpm, you can catch it and continue:
try {
Initialize-Tpm -AllowClear -ErrorAction Stop
} catch [Microsoft.Tpm.Commands.TpmCommandException] {
if ($_.Exception.Message -match "0x80290219") {
Write-Warning "PPI not supported – skipping TPM init; do it from firmware if needed."
} else {
throw
}
}
The reason this works is that the TPM can still be initialized later by BitLocker or Windows AutoProvisioning, which don't require PPI. So you don't need to fail the whole script.
Step 4: Check your TPM driver version
Occasionally, a buggy TPM driver can cause the TBS to misreport PPI support. Go to Device Manager, expand "Security devices," right-click "Trusted Platform Module 2.0," and select "Update driver." Let Windows search automatically. If you're on a Dell or Lenovo, check their support site for a chipset driver update. But honestly, this is a long shot—most of the time it's a firmware limitation, not a driver issue.
What to check if it still fails
If you've tried the firmware clear and the error persists, you might have a TPM module that doesn't fully comply with the spec. Check your motherboard manual to see if it uses a discrete TPM header (like TPM 2.0 SPI or LPC). Some older boards have a firmware TPM (fTPM) that emulates PPI but only in certain configurations—if you have an AMD system, it's worth updating your chipset drivers and AMD AGESA firmware. On Intel, make sure you're not in a strange hybrid mode where the OS sees both a firmware TPM and a discrete one.
Also, verify that the TPM is actually enabled and visible in Windows. Run Get-Tpm and note the ManufacturerId and ManufacturerVersion. If the manufacturer ID shows 0 (unknown), the TPM might be in a bad state—try reseating the TPM module if it's discrete. And if you're on a laptop, check if there's a BIOS setting for "PPI Policy"—some business laptops let you set it to "Skip" or "Always allow," which might make the OS think PPI is supported.
If none of that helps, you can safely ignore the error as long as BitLocker works. The TPM's core functionality isn't affected. The error only shows up in tools that explicitly query PPI, and there's no real harm in leaving it. Just remember, for any TPM administrative task, do it from the UEFI firmware—that's the reliable path.