Error 80090016 in Teams and Outlook: the TPM keyset does not exist

Fix it now

80090016 is NTE_BAD_KEYSET, “Keyset does not exist”. Windows keeps the key that proves your identity to Entra ID in a protected container, normally sealed by the TPM, and the component that needed it could not open it. Microsoft attributes it to the device TPM, and every Microsoft 365 app on the machine fails the same way.

Get-Tpm
dsregcmd /status
certutil -DeleteHelloContainer

1. Read Get-Tpm. TpmPresent and TpmReady both True means the hardware is fine and the fault is in the container above it.
2. Run Microsoft’s Sign-in troubleshooter for Microsoft 365 before anything manual. It is the documented automatic fix for this family.
3. If one user fails on a device where others are fine, run certutil -DeleteHelloContainer as that user, sign out and back in, and set the PIN up again.
4. If every user on the device fails, run dsregcmd /leave on an Entra joined or hybrid joined device, restart, and let it re-register.
5. Check that your antivirus or firewall is not blocking Microsoft.AAD.BrokerPlugin.exe or backgroundTaskHost.exe, which Microsoft names as required.

certutil -DeleteHelloContainer removes that user’s PIN and biometric sign-in on that device. Make sure they know their password first.

If sign-in completes you can stop here. If not, the next section explains what the container is and why each step is more destructive than the last.

Why it happens

When a device registers with Entra ID it generates a key pair. The private half is written into a protected container, ideally sealed by the TPM so it cannot be copied off the machine, and the public half is recorded against the device object in the directory. Every silent token the Web Account Manager issues afterwards is proved with that private key. If the container cannot be opened, nothing can be proved, and every application that depends on it stops signing in.

The five codes in this article are all cryptography errors from the same header file, and they describe different failures of that machinery rather than five versions of one failure. 80090016 is NTE_BAD_KEYSET, “Keyset does not exist”: the container the caller asked for is not there. 80090011 is NTE_NOT_FOUND, “Object was not found”. 80090030 is NTE_DEVICE_NOT_READY, “The device that is required by this cryptographic provider is not ready for use”. 80090034 is NTE_ENCRYPTION_FAILURE, “Encryption failed”. 80090023 is NTE_TOKEN_KEYSET_STORAGE_FULL: “The security token does not have storage space available for an additional container”.

That last one is worth reading twice, because it points somewhere none of the others do. A TPM has finite storage for key containers, and a device that has accumulated containers – many user profiles, repeated re-registrations, or an application creating containers it never releases – can simply run out of room. The fix for a full token is not the same as the fix for a missing keyset.

Containers become unopenable for mundane reasons: a profile that roams badly, a firmware update that changes the TPM’s storage hierarchy, a TPM in lockout after repeated failures, or a device restored from an image captured after registration so the directory holds a public key whose private half no longer exists. The order you work through this in matters, because each step costs more than the one before.

Clearing a TPM destroys every key it holds. BitLocker will demand the recovery key, Windows Hello enrolments are lost for every user on the device, and anything else sealed to that TPM stops working. Suspend BitLocker and confirm you hold the recovery keys before you go near this.

Full reference

What each code actually says

Microsoft’s Web Account Manager error list shows the same values in decimal, which is how they often appear in application logs: 2148073494 is 0x80090016 and 2148073520 is 0x80090030. If you are reading a log that gives you a ten-digit number rather than a hex code, convert before you search.

Work through the layers in order

A warning about registry workarounds

There is a registry value circulating for this error that moves the account broker’s key protection out of the TPM and into software. It is not documented by Microsoft, and what it does is real: it takes keys that were sealed to hardware and makes them software-protected, on every account on that machine, permanently until someone remembers to reverse it. That is a deliberate reduction in the protection those keys receive, applied to fix a sign-in prompt. Do not do it. If the TPM genuinely cannot hold the key, fix or replace the TPM.

Where to look when the obvious steps fail

• Microsoft’s Sign-in troubleshooter for Microsoft 365 is the documented automatic fix and should be your first move, not your last.
• The Microsoft Entra ID operational log on the device carries the AADSTS detail behind the failure. AADSTS70002 with AADSTS135011 means the device is disabled in the directory; with AADSTS50155 it means the device is not authenticated.
• Non-persistent VDI with single sign-on through a federated identity provider has its own documented failure, 0xc0f10005, which is not a TPM problem at all.
• A device whose object was deleted from Entra ID needs re-registration, not a container rebuild; the container is fine, the directory no longer has the matching public key.
• Check the Windows build. This family has been the subject of several fixes, and a device months behind on updates is worth patching before it is worth rebuilding.

Every code this article covers

Confirm the fix worked

1. Get-Tpm reports the TPM present, ready and not locked out.
2. dsregcmd /status shows the device state and token section as expected for your join type.
3. Teams and Outlook both sign in on the device without a prompt loop.
4. The user can set and use a PIN again, which proves the container rebuilt.
5. Restart and confirm sign-in still succeeds with no manual intervention.

Questions people ask about this