Windows Hello Survives a Password Change - Your Saved…

Here is a fact that feels wrong the first time you hear it: changing a user's password does not break Windows Hello for Business (WHfB) sign-in. Hello uses a key, not the password, so the PIN keeps working. And yet, right after a password reset, users report that saved Wi-Fi drops, Credential Manager throws 0x80090345, and cached app passwords vanish. Both things are true at once, and the bridge between them is a Windows subsystem almost nobody thinks about until it breaks: the Data Protection API (DPAPI).

The problem: Hello is fine, but the user's secrets are gone

The symptom set is specific. After an administrator resets a user's password (or certain hybrid/password-reset flows), the user signs in fine with their PIN, but:

Saved credentials in Credential Manager fail, often with error 0x80090345 ("the requested operation cannot be completed... key set does not exist" family).
Saved Wi-Fi profiles that used stored credentials stop connecting.
Applications that cached a password (some VPN clients, older line-of-business apps) prompt again or fail.

Because Hello itself still works, the natural conclusion - "Hello is broken" - is wrong, and chasing it wastes hours. The actual victim is DPAPI-protected data.

Why it happens: DPAPI is chained to the password, Hello is not

DPAPI is the Windows service that encrypts "secrets at rest" for a user - Credential Manager entries, saved Wi-Fi keys, many apps' stored passwords. Every user has a DPAPI master key, and that master key is protected by a key derived from the user's password. When the user changes their password the normal way, Windows re-protects the master key with the new password in the same operation - so nothing is lost.

A password reset is different. When an admin resets a password (or a self-service reset happens without the old password), Windows cannot decrypt the old master key with the new credential, because it never had the old one to perform the re-wrap. The master key is effectively orphaned, and everything it protected becomes unreadable. This is where the DPAPI recovery path matters: on a domain-joined device with line of sight to a domain controller (DC), Windows can use a domain backup of the master key to recover. Without that path - a reset performed while off the corporate network, or a cloud-only flow - there is no fallback, and the secrets are gone for good.

Note: This is why WHfB and DPAPI are so easy to confuse. They are independent. WHfB authenticates you (key + PIN, password-independent). DPAPI protects your stored secrets (chained to the password). A password reset leaves the first untouched and can destroy the second. Keeping those two mental models separate is most of the battle.

How to verify it is DPAPI, not Hello

Three quick checks confirm the diagnosis. First, Hello sign-in works and dsregcmd /status shows a healthy credential (NgcSet : YES) - so authentication is not the issue. Second, the failures are all in Credential Manager / stored-secret territory, not sign-in. Third, the error code points at the cryptographic key store:

⚠ Credential Manager error

Error: 0x80090345
Meaning: DPAPI cannot decrypt the master key that protected this credential
Tells you: the master key was orphaned - almost always after a password reset

The DPAPI master keys themselves live in the user profile. You do not decrypt them by hand, but their presence (or a recent change) is a useful signal:

Windows PowerShell (user context)

# DPAPI master keys are stored per-user under the SID here: Get-ChildItem "$env:APPDATA\Microsoft\Protect" -Recurse -Force -ErrorAction SilentlyContinue | Select-Object FullName, LastWriteTime # A master key file whose LastWriteTime jumps to "just after the reset" is the # newly created one; the old protected secrets were tied to the previous key.

The surface that breaks is Credential Manager - list what is stored so you know what the user will need to re-enter after an orphaning event:

Command Prompt (user context)

C:\> cmdkey /list Target: Domain:target=fileserver.contoso.com Type: Domain Password User: CONTOSO\jdoe # these are DPAPI-protected; orphaned by a reset Target: LegacyGeneric:target=https://app.contoso.com Type: Generic

The fix: prevention beats recovery

Once DPAPI-protected secrets are orphaned with no domain backup, they are generally not recoverable - so the real fix is avoiding the orphaning in the first place:

Prefer user-driven password change over admin reset. When the user changes their own password via Ctrl+Alt+Del, DPAPI re-wraps the master key in the same step and nothing is lost. Reserve admin resets for genuine lockouts.
Do resets on the corporate network. A domain-joined device with DC line of sight can use the domain master-key backup to recover, so the blast radius is far smaller than a reset performed off-network.
Lean on passwordless recovery. The more you move users to WHfB, FIDO2 and self-service that does not orphan DPAPI, the fewer hard password resets you perform - and the fewer DPAPI casualties you create.
Set expectations. Tell the service desk that after a hard reset, the user may need to re-enter saved credentials and reconnect Wi-Fi. That is not a second incident - it is the expected DPAPI consequence.

Watch out: A hybrid known issue amplifies this. Some devices hit Credential Manager 0x80090345 after certain Windows 24H2 updates in hybrid environments, because the DPAPI master key that legacy apps and Credential Manager depend on is seeded during an initial line-of-sight domain logon - and a device that has only ever signed in with Hello off-network may never have seeded it. If a fleet of hybrid devices starts failing Credential Manager together after an update, this - not WHfB - is where to look.

Gotcha: Do not "fix" DPAPI errors by deleting the Windows Hello container. Hello and DPAPI are separate subsystems - deleting the Hello container removes a working credential and does nothing for the orphaned DPAPI master key. You will have created a second problem and solved neither.

Proof it worked

Prevention looks like the absence of a symptom: after you move the team to user-driven password changes and on-network resets, the "saved Wi-Fi dropped after my password changed" tickets stop arriving. On an individual device, success after a necessary reset is Credential Manager re-populating cleanly (the user re-enters what was lost, and it persists), no recurring 0x80090345, and Hello continuing to work throughout - because it was never the problem.

Tip: The strategic answer is to reduce how often you touch passwords at all. Every hard reset is a DPAPI risk; every credential you move to WHfB or a FIDO2 key is one fewer password to reset. If your service desk resets passwords daily, DPAPI casualties are inevitable - the durable fix is passwordless, not a better reset runbook.

References

    
    PowerShell Scripts — DPAPI Health Snapshot
  
Script for this post is in Daily-Tasks.

      ●
      Get-DpapiHealthSnapshot.ps1
      — read-only: lists DPAPI master keys and timestamps, counts Credential Manager entries, and confirms Hello is healthy so you can tell DPAPI apart from a WHfB fault
    
      View all scripts on GitHub

Windows Hello Survives a Password Change - Your Saved Credentials Might Not (DPAPI)