TPMAPI_E_ACCESS_DENIED (0X80290108) – TPM Caller Rights Fix

Weird TPM error? Here's what actually causes it

You're seeing 0X80290108 – TPMAPI_E_ACCESS_DENIED. It pops up when something tries to talk to the TPM (Trusted Platform Module) but doesn't have the right permissions. What's actually happening here is the TPM Base Services (TBS) layer checks the caller's token against a delegation list. If the caller isn't in that list, you get this error.

I've seen this most often with:

• BitLocker key protector operations (especially after a driver update)
• Custom software using TPM for hardware attestation
• Virtualization-Based Security (VBS) or Credential Guard suddenly breaking
• Windows Hello for Business enrollment failures

The three most common causes, in order of likelihood: local security policy misconfiguration, broken TBS delegation in the registry, or a corrupted TPM driver stack. Let's fix each one.

Cause 1: Local Security Policy is blocking the caller

This is the fix I'd try first. Windows has a specific policy called System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing that can interfere with TPM delegation. But the real culprit is often the Network access: Do not allow anonymous enumeration of SAM accounts and shares policy – yes, it sounds unrelated, but it controls how the TPM checks caller SIDs.

Here's the fix:

1. Press Win + R, type secpol.msc, hit Enter.
2. Go to Local Policies -> User Rights Assignment.
3. Find Manage the TPM (or Manage Trusted Platform Module on older builds).
4. Double-click it. Make sure Administrators and NT AUTHORITY\SYSTEM are listed. If not, add them.
5. Also check Impersonate a client after authentication – BitLocker and VBS need this. Add NETWORK SERVICE and LOCAL SERVICE if missing.
6. Run gpupdate /force in an admin command prompt, then reboot.

The reason step 4 works is that the TPM driver checks the caller's token against the Manage the TPM SID list. If the caller (like a system service) isn't explicitly allowed, TBS returns ACCESS_DENIED.

Cause 2: Broken TBS delegation in the registry

If the policy fix didn't help, the issue is deeper – the TBS service itself has a hardcoded list of allowed callers stored in the registry. A Windows update or a third-party TPM management tool can overwrite this. I've seen this after installing Dell's or Lenovo's TPM firmware updaters.

Check and fix the registry:

1. Open regedit.exe as Administrator.
2. Navigate to:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TBS\Parameters
3. Look for a value named AllowedCallers (REG_MULTI_SZ).
4. If it's missing or empty, create it. Set the data to:
   

   NT AUTHORITY\SYSTEM
   BUILTIN\Administrators
   NT AUTHORITY\NETWORK SERVICE
   NT AUTHORITY\LOCAL SERVICE

5. If it exists but has extra entries (like a third-party service SID), remove those unless you're sure they're needed.
6. Reboot.

What's actually happening here is the TBS service uses this registry key as an access control list. If your app or service's SID isn't in that multi-string list, TBS won't route the TPM commands. The default list should be exactly the four principals above. Anything less will break BitLocker or Credential Guard.

Cause 3: Corrupted TPM driver stack or firmware mismatch

This one's rarer but brutal. The TPM driver (tpm.sys) or the TBS driver (tbs.sys) can get out of sync after a feature update or a BIOS upgrade that changes TPM firmware revision. The error code 0X80290108 then appears because the driver rejects the caller's command at a lower level – before even checking delegation.

Here's how to detect and fix it:

1. Open Device Manager. Expand Security devices. Look for Trusted Platform Module 2.0 (or 1.2).
2. Right-click it -> Properties -> Driver tab. Note the driver version.
3. Check your motherboard/PC manufacturer's support site for the correct TPM driver for your Windows version (21H2, 22H2, 23H2, or 24H2).
4. If the version is old or mismatched, download and install the correct one. On many systems, the driver comes via Windows Update – run wusa /uninstall /kb:5025885 if a recent update broke things, then reinstall.
5. If that fails, clear the TPM from the UEFI/BIOS (not from Windows). Reboot, enter BIOS, find TPM Device or Security Chip, set to Clear or Reset. Save and reboot into Windows.
6. After reboot, Windows will reinitialize the TPM. You'll need to re-enroll BitLocker, Windows Hello, etc.

The reason step 5 works is that a firmware-level clear forces the TPM to re-establish its endorsement key hierarchy. If the driver was confused by a stale key hierarchy, this resets everything to a clean state. But only do this if you're okay losing all TPM-bound secrets (BitLocker keys, PINs, certificates).

Quick-reference summary table

If none of these work, you're probably dealing with a damaged TPM chip itself – that's hardware replacement territory. But in my experience, 90% of 0X80290108 cases are fixed by cause 1 or 2. Start there, skip the rest until you confirm the policy and registry are correct.