Windows 11 Device TPM Problem

Why this happens (short)​

• The error 0x8029040E / “Device TPM Problem” normally means the device-attestation data stored in the TPM looks invalid or the OS/Office cannot use it to prove device identity. That breaks the token/attestation step Office uses for school/work (Azure AD / work/school) accounts and stops sign‑in/activation.
• Office sign-in errors (0xCAA82EE2, 657rx, etc.) commonly occur together when local AAD/credential broker caches or device registration tokens are corrupt.

Quick, safe checklist (test on 1 machine first)​

1. Close all Office apps.
2. Clear the AAD broker cache:
   • Open File Explorer, paste:
     %localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
   • Delete all files/folders inside, then reboot. This often fixes sign-in token problems.
3. Sign out of Office (File → Account → Sign out), then open Word and try signing in again. If you still see “Device TPM Problem”, continue below.
4. Check TPM status: Run Windows+R → tpm.msc and note the TPM status and version (ready, not ready, owner auth needed). If the TPM shows errors or “Not found,” that indicates a TPM issue.
5. If BitLocker is enabled: do NOT clear the TPM before you back up BitLocker recovery keys. Clearing TPM removes TPM‑stored keys and can force BitLocker recovery. Back up all recovery keys first.
6. If you recently changed motherboard/CPU or deployed an image from a different machine, TPM data is a likely root cause. In that case you can either:
   • Re‑register the device with your school’s Azure/Entra/MDM (Settings → Accounts → Access work or school → Disconnect then Re‑connect), or
   • If you accept the consequences and have BitLocker recovery keys, clear the TPM (Settings → Privacy & security → Device security → Security processor → Security processor troubleshooting → Clear TPM) and then re‑provision Windows Hello / re-register the device. Clearing is destructive to TPM keys so only do it after recovery keys are secured.

Office activation / token steps to try if sign-in still fails​

• Run Microsoft Support and Recovery Assistant (SaRA) for Office to reset activation tokens and repair sign-in. Also try the Office activation cleanup/diagnostic steps recommended by Microsoft if SaRA doesn’t fix it.
• If devices are Azure AD / Entra joined, consider removing and re‑joining the device to Entra/Azure AD — that has resolved cases where device registration/attestation is broken.

Longer-term / lab-scale options​

• If lab PCs are using the same school Microsoft accounts on many local accounts, consider one of these:
  • Make the PCs properly managed (Azure AD / Intune or AD join + GPO) so devices and credentials are centrally enrolled (prevents repeated device-attestation/token problems).
  • If students must share accounts, use Microsoft 365 Shared Computer Activation for lab‑style deployments (reduces per‑device activation problems) — consider moving to centrally managed licensing rather than signing in per‑user on unmanaged local profiles. (If you want I can add the SCA setup steps.)

Recommended immediate plan​

1. Pick 1-2 representative machines (one that works and one that fails).
2. Run the Quick checklist above (clear AAD broker cache, SaRA, check tpm.msc). Reboot and test Office sign-in.
3. If still blocked and BitLocker is not a concern (or keys backed up), clear TPM on that test machine and re-register the device. Test again.
4. If that fixes it, you have a repeatable sequence for the rest of the lab; if it doesn’t, collect the exact error codes & Office logs and we’ll dig deeper.

What I need from you to proceed​

• Exact error text (screenshot is helpful) and any error code (e.g., 0x8029040E).
• Are these PCs Azure AD / Entra joined, domain-joined, or just workgroup/local only?
• Were the machines imaged/cloned recently or had hardware changes (motherboard/CPU)?
• Is BitLocker enabled on the drives?

• Open Settings → Accounts → Your info (or Email & accounts). If the user signed in with a Microsoft account you’ll see their email (e.g. user@outlook.com) and “Sign in with a local account instead” option.
• Also check Settings → System → Activation — if a digital license is linked to an MS account you’ll see “Windows is activated with a digital license linked to your Microsoft account.”

• This script looks for stored Microsoft identities in each user hive and prints any MSA addresses it finds. Run PowerShell as Administrator:

# Run locally as Admin
$found = @()
Get-ChildItem Registry::HKEY_USERS | Where-Object { $_.Name -notmatch 'S-1-5-18|S-1-5-19|S-1-5-20' } | ForEach-Object {
  $sid = $_.PSChildName
  $key = "Registry::HKEY_USERS\$sid\Software\Microsoft\IdentityCRL\StoredIdentities"
  if (Test-Path $key) {
    Get-ChildItem $key | ForEach-Object {
      $found += [PSCustomObject]@{ SID=$sid; Identity=$_.PSChildName }
    }
  }
}
if ($found) { $found | Format-Table -AutoSize } else { 'No stored MSA identities found in user hives.' }

$computers = 'PC1','PC2'   # replace with hostnames
$script = { <# paste the script block above without the leading comments #> }
Invoke-Command -ComputerName $computers -ScriptBlock $script -ErrorAction SilentlyContinue

• If machines are Azure AD / Intune managed, check the Azure AD portal (Users → Devices or Sign‑ins) for which accounts have registered those devices.
• If you want, paste the PowerShell output here and I’ll help interpret it (which account, which user SID → map to C:\Users\ folder).