Scenarios for this code
The same code shows up in multiple contexts. Pick the surface where you saw it to jump straight to the matching fix.
Teams Error 80090016: The Trusted Platform Module Has Malfunctioned (2026 Fix Guide)
Quick answer
Error 80090016 in Microsoft Teams says your computer’s Trusted Platform Module has malfunctioned. In about 9 out of 10 cases, it hasn’t. The actual cause is a corrupted Web Account Manager (WAM) plugin folder that handles Microsoft 365 sign-in. The fix that works first — and the one most guides bury — is renaming the Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy folder and signing back in.
Before you start
A few hard rules before you touch anything:
- Don’t clear or reset the TPM in BIOS. Most online guides reach for this early. It’s almost never the right move and it has real consequences: any data protected by TPM-bound keys (BitLocker, Windows Hello PIN, certificate-based VPN credentials) needs recovery. Save TPM-clearing for genuine hardware issues, which 80090016 almost never is.
- Don’t disable BitLocker unless your admin asks you to. On a managed device, suspending BitLocker can trigger a security alert with your IT team and may require a recovery key on next boot.
- Don’t reinstall Office as the first move either. It’s a 30-minute fix for a problem that’s usually a 2-minute fix.
If you’re seeing this error on a corporate laptop and you’re not on the IT team, your admin probably has a documented runbook for this. It’s worth a Slack message before you start renaming things.
What error 80090016 actually means
Microsoft’s exact message is: “Your computer’s Trusted Platform Module has malfunctioned. If this error persists, contact your system administrator with the error code 80090016.” The link in the dialog points to microsoft.com/wamerrors, which is where Microsoft puts errors related to the Web Account Manager — the Windows component that holds tokens for Microsoft 365 accounts.
That URL is the giveaway. The error message blames the TPM, but Microsoft’s own diagnostic page categorizes 80090016 as a WAM error. The TPM is involved only because the WAM plugin uses TPM-protected keys to encrypt account tokens. When the WAM plugin’s local data gets corrupted — and it does, regularly, especially after Windows feature updates and account changes — the broker can’t decrypt the tokens. Windows surfaces that as “TPM has malfunctioned.”
The TPM is fine. Your account broker isn’t.
Where this error appears
| Surface | Behaviour |
|---|---|
| Teams desktop (new, 2.x) | Sign-in fails immediately with the error dialog; web Teams may still work |
| Teams desktop (classic, retired) | Same dialog, but classic Teams is being phased out — most users have been migrated |
| Outlook desktop | Same error during sign-in or when adding a new account |
| Microsoft 365 apps (Word, Excel, PowerPoint) | “Something went wrong” with 80090016 in the details when activating |
| OneDrive sync client | Sync stops; 80090016 appears in the activity log |
Teams web (teams.microsoft.com) | Usually works. This is a useful diagnostic — if web Teams signs in fine but the desktop doesn’t, the problem is local to the WAM plugin, not your account |
The pattern matters. If only one app shows the error, you can fix it without touching shared system state. If every Microsoft 365 app shows the error simultaneously, the WAM plugin folder is the cause and the fix is once for everything.
Common causes
In rough order of frequency:
- Corrupted WAM plugin data after a Windows feature update or a forced account re-authentication. This is the dominant cause.
- Account state mismatch after disconnecting and reconnecting a work or school account from Settings > Accounts > Access work or school.
- Windows Hello PIN corruption. The Ngc folder under your user profile holds PIN credentials; if it’s damaged, sign-in fails with TPM-flavoured errors.
- Genuine TPM driver problem after a Windows Update or after a motherboard or BIOS change. Rare but real.
- System board replacement — a laptop with a swapped motherboard literally has a different TPM, and the keys generated by the old one can’t be decrypted by the new one. Genuinely a TPM problem; needs different handling.
- BitLocker key conflicts after suspending and resuming BitLocker.
- Group Policy or Intune policy restricting cloud account sign-in on a managed device.
Fixes to try first
These are ordered by effectiveness and risk. Start at the top.
1. Rename the WAM plugin folder. This is the fix that works first about 70% of the time and the one most guides bury under cache-clearing. Quit Teams completely (Task Manager → end any Teams.exe or ms-teams.exe processes). Open File Explorer, paste this path into the address bar, and press Enter:
C:\Users\%username%\AppData\Local\Packages
Find the folder named Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy. Rename it to Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy.old. If Windows tells you the folder is in use, sign out of Windows and back in (full sign-out, not just lock), then try again before reaching for a reboot.
Restart Teams. Sign in. Windows recreates the folder cleanly.
2. Disconnect and reconnect your work or school account. If renaming the broker folder didn’t help, the next-most-effective fix is forcing Windows to re-establish the account binding. Go to Settings > Accounts > Access work or school. Click your work account. Click Disconnect. Confirm. Restart the machine.
After the restart, open Teams. It will prompt you to sign in. Sign in with the same account. Windows will offer to add the account back to Access work or school — accept that. This rebuilds the WAM tokens cleanly.
On a managed device with conditional access, you may need to re-register the device with Microsoft Entra ID after this. That happens automatically the next time you sign in to a Microsoft 365 service; just allow it to complete.
3. Clear the new Teams cache. This is the fix the older guides describe — but the paths are wrong for new Teams. Classic Teams used %appdata%\Microsoft\teams. New Teams (the version everyone is now on, 2.x) uses a Microsoft Store-style location:
%LOCALAPPDATA%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams
Quit Teams entirely. Delete everything inside that folder (not the folder itself). Restart Teams. If you’ve copied the old %appdata%\Microsoft\teams instructions from somewhere and the folder doesn’t exist, that’s why — you’re on new Teams.
4. Run the Microsoft 365 sign-in troubleshooter. Microsoft maintains a sign-in/activation troubleshooter that handles 80090016 specifically. It’s at Microsoft Support — Microsoft 365 sign-in troubleshooter. Download and run it. It does the broker-folder reset and credential cleanup automatically. If you’d rather click a button than rename a folder, this is a fine alternative to step 1.
Advanced fixes
If steps 1–4 didn’t resolve it, the problem is deeper than WAM plugin corruption. Work through these in order.
Reset the Windows Hello PIN. Go to Settings > Accounts > Sign-in options > PIN (Windows Hello) > I forgot my PIN. Confirm your password, set a new PIN. This rewrites the Ngc folder. If the PIN reset itself fails with an error referencing TPM, your Ngc folder is corrupted; in that case:
- Quit Teams and other Microsoft 365 apps.
- Open File Explorer as administrator and navigate to
C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc. - Take ownership of the folder (right-click > Properties > Security > Advanced > Owner > Change → set to Administrators), then delete its contents.
- Restart. Set up a new PIN.
This is more invasive than it sounds — you’ll need to re-enable Windows Hello and may need to reset BitLocker recovery keys on a managed device. Don’t do it lightly.
Check Credential Manager for stale Office credentials. Open Control Panel > User Accounts > Credential Manager > Windows Credentials. Look for entries starting with MicrosoftAccount:, MicrosoftOffice16_Data:, or OneDrive Cached Credential. Delete each one. Restart Teams; it will prompt for fresh credentials.
Update or reinstall the TPM driver. This is the only fix that’s actually about the TPM. Open Device Manager > Security devices > Trusted Platform Module 2.0. Right-click → Update driver > Search automatically. If that finds nothing, right-click → Uninstall device (don’t tick “Delete driver software”). Restart. Windows reinstalls the TPM driver on boot.
Repair Office. Open Settings > Apps > Installed apps, find Microsoft 365, click the three-dot menu → Modify > Online Repair. Allow 15–30 minutes. This rebuilds the entire Office install and is what eventually works for the small percentage of cases where the WAM plugin recovery alone doesn’t resolve it.
Last-resort Teams reinstall. Uninstall Teams from Settings > Apps. If it’s the new Teams (Store version), uninstalling and reinstalling from the Microsoft Store is sufficient. For classic Teams (rare in 2026), also delete %appdata%\Microsoft\teams and %localappdata%\Microsoft\TeamsMeetingAddin after uninstall. Reinstall fresh.
The compatibility-mode workaround. Several Microsoft Q&A threads document users solving 80090016 by setting Teams to run in Windows 8 compatibility mode. It works for some people. It’s a hack, not a fix — what it actually does is route Teams through a different sign-in flow that bypasses the broken broker plugin. Use it as a last resort if reinstalling Teams doesn’t help, and document it for whoever has to maintain the machine later.
If you are on a work or school device
Renaming the WAM plugin folder is safe on most managed devices, but disconnecting the work or school account isn’t always. On a hybrid-joined or Entra-joined device with conditional access policies, disconnecting forces a re-registration that may need to happen via your admin’s specific procedure. If the error first appeared after your IT team applied a new conditional access policy, the fix is admin-side — see our admin-side breakdown of CAA50021 and the hub article on CAA50021, which often appears alongside 80090016 when conditional access is the underlying cause.
If the error appears across many users at the same time in the same tenant, it’s a tenant-side configuration change, not a local problem. Stop troubleshooting locally and tell your admin.
When to stop
Stop and escalate when any of these are true:
- You’ve renamed the WAM folder, disconnected/reconnected the account, run Online Repair, and the error persists.
- 80090016 appears immediately after a motherboard or system-board replacement. This is one of the rare cases where the TPM really is the problem; the user fix is to re-register the device with Entra ID after re-establishing trust, which usually needs admin help.
- Multiple users in your organization are seeing the error at once. This is a conditional access or tenant policy issue.
- BitLocker is asking for a recovery key after you tried these fixes. Don’t keep going — get the recovery key from your admin first.
Don’t try to “fix” the TPM by clearing it in BIOS unless the manufacturer’s hardware diagnostics report a TPM hardware failure. Don’t run third-party “Windows credential repair” tools — none of them do anything the steps above don’t do, and several install browser hijackers. Microsoft’s wamerrors page is the only diagnostic resource you need.
Related errors
- CAA50021 in Teams — often appears alongside 80090016 when conditional access is involved.
- Microsoft 365 Error CAA50021 — the parent code hub if 80090016 is happening across multiple Microsoft 365 apps.
- Teams Stuck on Loading — when 80090016 has been “fixed” but Teams now hangs at the loading screen.
Official references
- Microsoft Q&A — Error 80090016
- Microsoft — WAM error reference
- Microsoft Support — Microsoft 365 sign-in troubleshooter
FAQ
Is my TPM actually broken?
Almost certainly not. Error 80090016 is categorized by Microsoft as a Web Account Manager error, not a hardware error. The dialog is misleading. Genuine TPM hardware failures show up differently — usually as BitLocker prompting for a recovery key on every boot, or tpm.msc reporting “Cannot find a compatible TPM.”
Will renaming the WAM plugin folder break anything? No. Windows rebuilds it automatically the next time you sign in to a Microsoft account. You’ll need to sign back in to Teams, Outlook, and any other Microsoft 365 apps that use single sign-on, but you won’t lose mail, files, or settings.
Why does Teams web work but the desktop app fails? Because Teams web doesn’t use the local Web Account Manager. It does a fresh OAuth sign-in in the browser. If web works and desktop doesn’t, the broker plugin is your problem — not your account, your network, or your tenant configuration.
Does this happen more after Windows Updates? Yes. Windows feature updates (the twice-yearly major releases like 24H2, 25H2) and some monthly cumulative updates touch the account broker components. The most reliable trigger is a Windows feature update applied while Teams was running. The fix is the same regardless.
I just replaced my motherboard. Will renaming the WAM folder fix this? Probably not. A new motherboard means a new TPM with new keys. The keys that signed your old account tokens are gone forever. The cleanest fix is: disconnect the work or school account from Settings, restart, sign in fresh. You may need your admin to deregister the old device record from Entra ID first.
Is this related to error CAA50021? They often appear together. CAA50021 is the conditional-access flavour of the same underlying problem (the WAM plugin can’t authenticate against your tenant). If you see both codes, work through the CAA50021 fixes after the WAM rename — they cover the policy-side causes that 80090016 alone doesn’t.
Can I just keep using Teams on the web? You can, and many users do as a workaround. The trade-offs: no notifications when Teams isn’t focused in the browser, no system-tray presence, no native screen-sharing for some scenarios, and slower sign-in. Worth it for a few hours; not worth it long-term.