Fix TPM_E_DELEGATE_ADMIN (0X8028004D) Error in Windows

What triggers this error

You'll see TPM_E_DELEGATE_ADMIN (0X8028004D) mostly on business laptops from Dell, HP, and Lenovo — the ones with TPM 2.0 chips running firmware from Infineon, Nuvoton, or STMicro. It pops up when Windows tries to write to the TPM's delegation table and the chip says no. A common real-world scenario: you're enrolling a device in Autopilot or Intune, and the provisioning step that sets up Windows Hello for Business fails with this exact code. Another one: you run Clear-Tpm in PowerShell and it bombs out with 0X8028004D instead of clearing.

The error also shows up after a BIOS update that silently flipped a TPM setting, or after a motherboard replacement where the TPM is a discrete chip that came fresh from the factory with delegation disabled.

What the error actually means

TPM chips have a concept called a "delegation table." Think of it as an access control list for admin tasks. Windows uses it so that specific OS components can perform privileged TPM operations — like clearing, taking ownership, or managing keys — without every process needing full admin rights on the chip itself.

When that delegation table isn't enabled, or when the TPM's owner auth is already set and Windows can't write the delegation rows, you get 0X8028004D. Plain English: Windows has the keys to the building but the door to the admin office is deadbolted from the inside.

Two root causes cover 95% of cases:

The TPM's delegation table feature is turned off in firmware (BIOS/UEFI) or was never provisioned.
The TPM already has an owner and the current Windows install doesn't know the owner auth — usually after a disk swap, reimage, or OS reload without clearing the TPM first.

Fix it — step by step

Do these in order. Don't skip ahead, because step 3 won't work if step 1 fails.

Step 1: Confirm the TPM state

Open PowerShell as Administrator. Run:

Get-Tpm

You should see output with TpmPresent: True, TpmReady: True, and TpmEnabled: True. Look at TpmOwned too — if it says True and you didn't set the owner auth, that's your problem.

Also run:

Get-TpmSupportedFeature -FeatureName "Delegation"

If it returns False or throws, the firmware has delegation disabled. Skip to step 2. If it returns True, jump to step 4.

Step 2: Check BIOS/UEFI for TPM settings

Reboot and hit F2 (Dell/Lenovo) or F10 (HP) at the splash screen. Where the setting lives depends on the vendor:

Dell: Security > TPM 2.0 Security > look for "TPM Clear" and "Attestation Enable." Set Attestation Enable to On, and enable "TPM 2.0" if it's off.
HP: Security > TPM Embedded Security > make sure "TPM Device" is set to "Available" and "TPM State" is enabled.
Lenovo: Security > Security Chip > set to "Active" and enable "Physical Presence for Clear" temporarily.

Save and exit. On the next boot, Windows should re-detect the TPM. Re-run Get-Tpm. The delegation table gets provisioned automatically on first Windows login after the firmware change — you might need to wait 30-60 seconds after you see the desktop.

Step 3: Clear the TPM (this destroys keys — read first)

If BitLocker is on, suspend it first: Suspend-BitLocker -MountPoint "C:" -RebootCount 1. Clearing the TPM wipes the protector and you'll be typing your recovery key otherwise.

In elevated PowerShell:

Clear-Tpm

If that returns 0X8028004D again, the delegation table is genuinely locked at the firmware level. Go back to BIOS, enable "Physical Presence for Clear" (Lenovo) or "TPM Clear" (Dell), save, reboot, then run Clear-Tpm again while physically present at the keyboard. Some vendors require you to confirm the clear on the next POST screen.

After a clean clear, you should see:

TpmReady : True
TpmOwned : False

Step 4: Reinitialize and take ownership

Run these in order:

Initialize-Tpm -AllowClear -AllowPhysicalPresence

You should get a prompt asking for owner authorization. Leave it blank on a fresh setup, or enter your org's owner auth if you manage TPMs centrally. Windows then writes the delegation table. Give it 20-30 seconds.

Verify with:

Get-TpmSupportedFeature -FeatureName "Delegation"

You want True back. If you're at True, re-run whatever action failed originally (Intune enrollment, Hello setup, BitLocker enable). The 0X8028004D should be gone.

If it still fails

Here's what to check in order:

Firmware version. Infineon TPMs had a nasty bug (CVE-2017-15361, the ROCA issue) where older firmware mishandled certain admin ops. Check your vendor's support page. Dell shipped a fix in BIOS 1.2.x and later for many Latitude models.
Group Policy. If you're on a domain, someone might have pushed a TPM restriction. Check Computer Configuration > Administrative Templates > System > Trusted Platform Module Services. "Turn on TPM backup to Active Directory Domain Services" being enabled can interfere with delegation initialization in some builds.
Wrong architecture. Running 32-bit PowerShell on 64-bit Windows can trigger this on some builds — the TPM cmdlets talk to the WMI provider differently. Use the standard x64 PowerShell.
Discrete vs. firmware TPM. Firmware TPMs (Intel PTT, AMD fTPM) handle delegation slightly differently from discrete chips. If you're on a Skylake-or-newer Intel box, try switching from discrete TPM to PTT in BIOS, or vice versa. Pick one — don't leave both enabled.
Windows build. This error was reported heavily on Windows 10 1809 and 1903 during Autopilot provisioning. If you're on those, patch to 21H2 or Windows 11 22H2+ before chasing TPM ghosts.

If all of that checks out and you still get 0X8028004D, the TPM chip itself is likely faulty. Get-Tpm will usually still report Present: True even when the chip is dying. RMA the device or swap the motherboard — no amount of PowerShell will convince a dead TPM to accept a delegation table.