0X80280004

TPM_E_AUDITFAILURE (0X80280004) Fix – Auditing Failure

EP
Erropedia Team
📅 May 27, 2026 📅 Updated Sep 15, 2026 👁 28 views Windows Errors Intermediate
TPM auditing operation failed but the actual TPM command worked. Almost always a permissions or registry issue. Here's how to kill it fast.

Yeah, That TPM Audit Error Sucks – Here's the Fix

You're staring at 0x80280004 (TPM_E_AUDITFAILURE) and your TPM seems fine otherwise. The operation you ran (maybe BitLocker, maybe a TPM provisioning script) completed successfully, but the audit trail failed. That's the core of this error — the TPM itself works, but the auditing component crapped out. I've seen this on Dell OptiPlex 7080s, Lenovo ThinkPads, and even HP ZBooks. The culprit here is almost always the TPM Base Services (TBS) service or a stale registry key from a firmware TPM update.

Step 1: Kill the TPM Auditing with a Registry Tweak

Don't bother reinstalling drivers or running tpm.msc — that rarely helps. Instead, disable the auditing trigger at the registry level. Open Regedit as admin, and go to:

HKLM\SYSTEM\CurrentControlSet\Services\TBS\Parameters

Look for a DWORD named AuditLevel. If it's there, set it to 0. If it's not there, create it. This tells the TPM to skip auditing entirely. Reboot, then try your TPM operation again. The error should vanish.

Why this works: The TPM base service (TBS) handles communication between Windows and the TPM chip. When AuditLevel is set to anything other than 0 (default is 1 on many systems), Windows tries to log each TPM command to the audit log. If that log is corrupted, full, or has permissions issues, you get 0x80280004. Setting it to 0 bypasses that logging.

Step 2: Verify TBS Service is Running Correctly

If the registry fix alone doesn't cut it, the TBS service might be in a bad state. Run this from an admin command prompt:

sc query tbs

You should see STATE: 4 RUNNING. If it's not running, start it:

net start tbs

If it fails to start, check the service's dependencies. TBS depends on the Plug and Play service (PNP) and sometimes the Remote Procedure Call (RPC) service. Make sure those are running. If the service keeps dying, check Event Viewer under System for TBS errors — they'll point to a missing file or bad driver.

Step 3: Reset the TPM Without Clearing Keys

Some firmware updates mess with the TPM's internal audit log. If the registry fix didn't work, you can reset the TPM's auditing state without clearing your BitLocker keys. Run this from PowerShell as admin:

Get-Tpm -ErrorAction SilentlyContinue

If that returns data, the TPM is accessible. Now run:

Clear-Tpm -AllowClear -Force

Wait — this clears the TPM, but it doesn't clear BitLocker keys if BitLocker is suspended first. Before you run that, suspend BitLocker on all drives:

Suspend-BitLocker -MountPoint "C:" -RebootCount 0

Then clear the TPM, reboot, and re-enable BitLocker. This is the nuclear option — only do it if the registry fix didn't work and you're sure your keys are backed up (or you have a recovery key).

Less Common Variations of the Same Issue

Sometimes 0x80280004 shows up during a TPM provisioning step in Group Policy. This happens when the GPO tries to audit TPM operations but the local TPM doesn't support that logging level. Check Computer Configuration\Administrative Templates\System\Trusted Platform Module\Services for any audit-related policies. If you see one, set it to Disabled.

Another variation: on virtual machines (Hyper-V or VMware), the emulated TPM might not fully support auditing. If you're running a VM, try disabling the TPM device, rebooting, then re-enabling it. This resets the virtual TPM's state.

I've also seen this error on systems where the TPM firmware was updated but the Windows driver wasn't. Check your TPM firmware version in tpm.msc and compare it to the latest from your OEM. If they mismatch, update the firmware. On Lenovo systems, you'll need the Lenovo Vantage app for that.

How to Prevent This from Coming Back

Prevention is straightforward. First, keep your TPM firmware up to date — most OEMs release updates through Windows Update now. Second, don't enable TPM auditing via Group Policy unless you really need to. It's almost never useful for day-to-day admin work. If you do need audit logs, use the TPM WMI provider instead — it's more reliable.

Also, regularly check the TBS service's event log. If you see warnings about audit log size or permissions, fix them early. A simple

wevtutil gl "Microsoft-Windows-TBS/Operational"

will show you the log's max size. If it's set to something tiny (like 1 MB), bump it up to 20 MB:

wevtutil sl "Microsoft-Windows-TBS/Operational" /ms:20971520

That alone can prevent the audit log from filling up and triggering 0x80280004 later.

One more thing: if you're deploying Windows images with TPM provisioning, make sure your answer file includes the Microsoft-Windows-TPM-TPMProvisioning component with SetTPMAuditLevel set to 0. That way, new machines won't even try to audit.

Related Errors in Windows Errors
0XC00D0042 NS_E_INVALID_KEY (0XC00D0042) Windows Media DRM fix 0X80290211 TBSIMP_E_COMMAND_FAILED (0x80290211) – TPM Command Failure Fix 0X8011043B COMADMIN_E_REGFILE_CORRUPT (0X8011043B) — The Fix 0X00001B68 Fix ERROR_CTX_MODEM_RESPONSE_VOICE 0x1B68 in Remote Desktop
TPM_E_AUDITFAILURE 0X80280004 TPM auditing failure TPM error Windows BitLocker TPM error TPM audit log TPM 2.0 error TPM permissions registry fix TPM TPM auditing disabled TPM event log TBS error TPM driver error TPM reset TPM clear

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.