STATUS_AUTH_TAG_MISMATCH 0xC000A002: What Actually Breaks

You're seeing STATUS_AUTH_TAG_MISMATCH (0xC000A002) and whatever you were doing — mounting a VHDX, restoring a backup, reading an EFS file, booting a BitLocker volume — just stopped dead. That's the honest reaction. Let's fix it.

The fix, in order

Don't jump to reinstalling Windows. This error almost always means data got mangled somewhere, and the fix is to find out where.

1. Confirm the source of the ciphertext

Fire up an elevated PowerShell and figure out which volume or file is producing the error. The tag mismatch itself doesn't tell you — the caller does. If it's a mounted VHDX or a backup catalog, detach and remount:

Dismount-VHD -Path C:\vms\prod.vhdx
Mount-VHD -Path C:\vms\prod.vhdx -ReadOnly

Read-only mount matters. If the header is corrupt, a writable mount can overwrite the recovery metadata before you get a chance to look at it.

2. For BitLocker volumes: run a metadata repair

If the volume is BitLocker-protected and you can still unlock it with the recovery key but the OS won't boot or chkdsk fails with 0xC000A002, the metadata block's authentication tag has drifted. Use repair-bde against a copy first:

repair-bde D: E:\recovered -rk 111111-222222-333333-444444-555555-666666-777777-888888 -f

Note the -f flag — without it, repair-bde refuses to write to an existing directory. The recovery key here is the 48-digit one from your Microsoft account or the printed sheet, not the numerical password you typed at boot.

3. For EFS and DPAPI blobs: restore from a shadow copy

EFS-encrypted files carry a per-file authentication tag in the $EFS attribute. If that got truncated during a bad copy — say, a USB drive yanked mid-write, or a network share that dropped — the tag won't verify. Check for a shadow copy:

vssadmin list shadows /for=C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4\Users\you\secret.docx C:\recovered\

If no shadow exists, you're pulling from backup. There's no in-place repair for EFS tag corruption that preserves the plaintext — the crypto is doing exactly what it's designed to do.

4. For Windows Hello / TPM operations

If the error shows up in the event log under Microsoft-Windows-Hello or during a PIN change, the TPM-stored key blob has failed its integrity check. Clear the TPM and re-enroll:

tpm.msc
# Or, from elevated PowerShell:
Clear-Tpm

You'll re-enroll Hello and lose any keys sealed to that TPM — BitLocker will demand its recovery key on next boot, so have it ready.

Why this works — what's actually going on

AEAD ciphers — AES-GCM, ChaCha20-Poly1305, AES-CCM — don't just encrypt your data. They compute a MAC over the ciphertext and the associated data, and they hand you that MAC as a tag. On decrypt, the cipher recomputes the tag and compares. If even one bit differs, the whole operation aborts. That's a feature, not a bug. There's no "close enough" mode in AEAD. You either get a verified plaintext or you get STATUS_AUTH_TAG_MISMATCH. Nothing in between.

The reason step 2 works is that repair-bde regenerates the BitLocker metadata block from the volume's data area rather than trusting the existing (corrupt) metadata. It reads the FVEK, rebuilds the header, and recomputes the tag over the new header. It works when the data area is intact and only the metadata got clobbered — usually by a power loss mid-write, or a firmware bug in cheap NVMe controllers that lie about flush support.

The reason step 3 works is subtler. Shadow copies preserve the file at a point in time when the tag was still valid. You're not repairing anything — you're walking backwards to a copy that never got corrupted. If you can't find one, the data is gone in the cryptographic sense. That's the price of authenticated encryption.

Less common variations

Backup software that lies about completion

Third-party backup tools sometimes write the header last. If the job gets killed — laptop lid closed, battery critical, network drop to the NAS — you get a valid-looking .bkf or .vbk with a truncated payload and a tag that was computed over data that no longer exists. No tool recovers this. Verify your backups by doing a test restore, not by checking the log for "Success".

Hyper-V checkpoint chains

AVHDX differencing disks inherit the authentication context of the parent VHDX. If you manually edited the parent's metadata (or a storage migration left it half-written), every child disk fails to open with 0xC000A002. Merge the chain from the read-only parent forward:

Merge-VHD -Path C:\vms\child.avhdx -DestinationPath C:\vms\merged.vhdx

Roaming profile and Folder Redirection

In domain environments with EFS-encrypted roaming profiles, a botched GPO refresh can leave the CSC (client-side cache) holding a tag from one DC and ciphertext from another. Force a re-sync:

rd /s /q %SystemRoot%\CSC
gpupdate /force

You'll lose any offline edits. Sync before you do this if you have connectivity.

Windows Subsystem for Android / WSA

WSA's virtual disk uses a similar authenticated container. If 0xC000A002 appears when launching WSA on Windows 11 22H2, unregister and reinstall — there's no partial repair path:

Get-AppxPackage *WindowsSubsystemForAndroid* | Remove-AppxPackage

Prevention — the parts that actually matter

• Never yank USB drives. Eject them. Every EFS tag corruption I've seen traced back to a hot-unplug during a write.
• Buy SSDs with power-loss protection (PLP). Consumer drives without it will happily acknowledge a flush they didn't complete. Samsung's 980 Pro and WD's SN850X don't have PLP. Enterprise drives like the Kioxia CD8 or Samsung PM9A3 do. If your data matters, this is the upgrade that matters.
• Export your BitLocker recovery keys somewhere that isn't the encrypted drive. Sounds obvious. You'd be surprised.
• Test restores quarterly. A backup you haven't restored isn't a backup — it's a hope.
• Don't disable TPM auto-provisioning to "fix" Hello quirks. It comes back to bite you at the worst time, usually during a firmware update.

One last thing. If the error shows up after a Windows Update — particularly the cumulative updates that touch the CNG/KSP stack — check the Known Issues list before you do anything destructive. Microsoft has shipped two of them in the last three years that caused spurious tag mismatches on BitLocker volumes. Rolling back the update is faster than rebuilding the volume.