How BitLocker encryption works, from the sector key to the recovery key. The parts, in plain terms, so the recovery makes sense.

BitLocker uses three layers of key, and the reason is worth understanding because it explains almost everything about recovery.

At the bottom is the Full Volume Encryption Key, the FVEK. This is the key that actually encrypts every sector of the drive, and it is set when BitLocker is first switched on and never changes for the life of the volume. You never see it and never type it. If you had it, you could decrypt the whole disk; so BitLocker never stores it in the open.

Above it is the Volume Master Key, the VMK. Its only job is to encrypt the FVEK. The encrypted FVEK is stored on the disk, and the VMK is what unlocks it. Why add a layer? Because it means the thing protected by your PIN or password is the small VMK, not the whole-disk FVEK, so you can change a PIN, add a fingerprint, or escrow a recovery key without re-encrypting the entire drive. Only the little VMK is re-wrapped each time.

At the top are the protectors. Each protector you set up, the TPM, a PIN, a password, a startup key on USB, the 48-digit recovery key, holds its own copy of the VMK, encrypted in its own way. Any one of them can release the VMK, which releases the FVEK, which decrypts the disk. This is the key fact for recovery: the recovery key is simply another protector holding the VMK, which is why it opens the drive when the TPM has changed or the PIN is forgotten. A different protector, the same VMK underneath.

Step two: the algorithm.

The actual encryption is AES, the same standard that protects banking and government data. Older BitLocker drives, from Windows 7 and early Windows 8, used AES in CBC mode, optionally with an extra scrambling step called the Elephant diffuser, which Windows 8 then removed. From Windows 10 version 1511 onward, BitLocker added AES-XTS, a mode designed specifically for disk encryption, in 128-bit and 256-bit strengths, and XTS-AES-128 is the modern default. For recovery, the mode and strength matter because they confirm what every honest account must: at these strengths, AES cannot be brute-forced, so the encryption itself is never the way in. The way in is always a protector or the key in memory.

Step three: why the key sits in memory.

Here is the single most important fact for recovering a drive whose password is lost. While a BitLocker volume is mounted and in use, the VMK sits in the computer's RAM, because the computer needs it to read and write the encrypted disk on the fly. That means if a machine is still running with the drive unlocked, or it hibernated while the volume was open (writing memory, including the VMK, to a hibernation file on disk), or a crash dump captured memory, the VMK can sometimes be extracted and the drive decrypted, regardless of the protector. This is the route forensic tools such as Passware use, and it is why every page here warns against shutting down a still-running locked-out machine: powering off at the recovery screen, with the volume locked, closes this door.

Step four: imaging, and why never in place.

When a BitLocker drive is recovered, nothing is done to the original until it has been copied. The drive is connected through a write blocker, read-only, and imaged sector by sector onto clean storage, weak areas worked last, with a map kept of anything unreadable; a failing drive is imaged in short passes, a mechanically failed disk repaired and read on the bench, a dead SSD controller read at the chip level. Everything after that is done on the image. The reason is absolute: decrypting a drive rewrites every sector, and doing that to a drive that is already failing can finish it off, potentially leaving neither a readable encrypted original nor a complete decrypted copy. Imaging first removes that risk entirely.

Step five: decryption, on the clone.

With a clean image and a way to a protector, the decryption itself is the straightforward part. The protector, your recovery key, password or PIN, releases the VMK; the VMK releases the FVEK; the FVEK decrypts the image into an ordinary readable volume. Where the key is lost but a memory image or hibernation file is available, the VMK is extracted from it instead, with forensic tools, and used the same way. Where a weak password must be recovered first, it is attacked on the image before decryption. The decrypted result is then an ordinary NTFS or exFAT file system, and any damage in it is repaired as on any drive.

Step six: repairing damaged metadata.

Sometimes the volume's metadata, which holds the encrypted key material and identifies the volume, is damaged, and the drive shows as RAW or reports no valid metadata. BitLocker anticipates this by keeping more than one copy of its metadata on the volume, and Microsoft's repair-bde tool uses them: given your recovery key or a key package, it finds an intact copy, reconstructs what it needs, and decrypts the volume at the block level onto a separate clean drive. It cannot repair a drive that failed mid-encryption, the partly-encrypted case, which needs bespoke work, but for ordinary damaged metadata with the key in hand, it is the right tool, run on the image.

What this means for your drive.

Put together, the design explains the whole honest picture. With a protector you can open, the recovery key above all, your data is recoverable even from a failed drive, because the encryption is just a final step once a clean image exists. With the key lost, your hope is a weak password or the VMK still in memory. And with a strong, modern, TPM-sealed drive, a genuinely lost key and no memory capture, there is no protector to open and no key to find, and the data cannot be recovered, because the FVEK stays sealed and AES cannot be forced. That is not our limitation; it is the design working as intended, and it is why we tell you honestly, at the free look, which of these your drive is.