Fix “Key not valid for use in specified state” (WinError -2146893813) on Windows

A practical guide for Azure CLI, MSAL token cache, and DPAPI decryption failures

Summary

If you see this error on Windows:

Decryption failed: [WinError -2146893813] Key not valid for use in specified state

…it usually means your app (often Azure CLI) is trying to decrypt saved credentials/tokens using Windows DPAPI, but the current Windows user context can’t access the encryption key anymore. The most common fix is to clear the cached tokens and re-login.

This guide explains what causes it, how to fix it quickly, and how to prevent it.

Where this error shows up

You’ll typically see it when using:

  • Azure CLI (az login, az account show, etc.)
  • Tools that use MSAL (Microsoft Authentication Library)
  • Python packages like microsoft-authentication-extensions-for-python
  • Apps storing tokens in an encrypted local cache

Example Azure CLI output:

Decryption failed: [WinError -2146893813] Key not valid for use in specified state.
... PersistenceDecryptionError ...

Why it happens (the real reason)

On Windows, many auth libraries store tokens encrypted using DPAPI (Data Protection API). DPAPI encryption is tied to a specific Windows user and security context. The cache becomes undecryptable when:

Common root causes

  1. Switching Windows user contexts
    • You logged in previously as a different Windows user
    • You ran PowerShell as Administrator (different context) and then later as normal user (or vice versa)
  2. Windows profile changes
    • Password reset, Windows Hello changes
    • Domain re-join, profile repair/migration
    • Roaming profile / VDI snapshots restoring old cache blobs
  3. Corrupted cache
    • Token cache files become inconsistent or partially written

Result: your tool reads the cache file, tries to decrypt it, and Windows says: nope.

Quick Fix (recommended): clear Azure CLI token cache

This is the most reliable and least risky solution.

Step 1 — Use the same context consistently

Before doing anything:

  • Close all terminals
  • Re-open normal PowerShell (not “Run as Administrator”), unless you always use Admin

Step 2 — Clear Azure CLI account state

az account clear

Step 3 — Remove the encrypted token cache files

$azureDir = Join-Path $env:USERPROFILE ".azure"

Remove-Item (Join-Path $azureDir "msal_token_cache.bin*") -Force -ErrorAction SilentlyContinue
Remove-Item (Join-Path $azureDir "service_principal_entries.bin*") -Force -ErrorAction SilentlyContinue
Remove-Item (Join-Path $azureDir "azureProfile.json") -Force -ErrorAction SilentlyContinue
Remove-Item (Join-Path $azureDir "TokenCache.dat*") -Force -ErrorAction SilentlyContinue

Step 4 — Login again

az login --use-device-code

If you were using tenant + scope:

az login --tenant $TENANT --use-device-code --scope "6dae42f8-4368-4678-94ff-3960e28e3630/.default"

✅ In most cases, this fixes it immediately.

Alternative Fix: run Azure CLI with a clean config directory

If you don’t want to touch the existing cache (or you suspect a corporate profile issue), force CLI to use a fresh location:

$env:AZURE_CONFIG_DIR = "$env:TEMP\azurecli-clean"
Remove-Item $env:AZURE_CONFIG_DIR -Recurse -Force -ErrorAction SilentlyContinue
mkdir $env:AZURE_CONFIG_DIR | Out-Null

az login --use-device-code

If this works, your original %USERPROFILE%\.azure cache is definitely the issue.

“Nuke it from orbit” (safe reset)

This renames the .azure folder so Azure CLI creates a brand-new one:

$azureDir = Join-Path $env:USERPROFILE ".azure"
Rename-Item $azureDir "$azureDir.bak_$(Get-Date -Format yyyyMMdd_HHmmss)"
az login --use-device-code

Prevention tips

To stop this coming back:

1) Don’t mix admin and non-admin sessions

Pick one and stick to it:

  • If you run az as Admin sometimes and normal other times, you’re inviting DPAPI cache mismatch.

2) Avoid roaming profile cache reuse

If you’re on VDI/roaming profile, consider using:

  • AZURE_CONFIG_DIR pointing to a stable local path (not roaming)

3) Keep Azure CLI updated

A newer CLI can reduce edge-case cache issues:

az version

Update method depends on how you installed it (MSI, winget, choco).

FAQ

Does deleting .azure break anything?

No permanent damage. It just removes local login state. You’ll need to login again.

Is this an Azure outage?

Almost never. This is almost always a local Windows profile/cache issue.

Will this affect Service Principal logins?

If you use az login --service-principal, it may also rely on local cache. Clearing the cache is still safe.

Can Windows Credential Manager be involved?

Sometimes (especially for other tools), but Azure CLI’s common culprit is the .azure MSAL cache files.

Copy-ready troubleshooting checklist

  • Are you running PowerShell as Admin sometimes? Stop mixing contexts
  • Run az account clear
  • Delete ~\.azure\msal_token_cache.bin*
  • Re-run az login --use-device-code
  • If still failing, set AZURE_CONFIG_DIR to a clean folder and retry
  • If on VDI/roaming profiles, use a stable non-roaming config directory