FVE_E_RECOVERY_KEY_REQUIRED (0x80310022): BitLocker Fix

You hit Enable-BitLocker or clicked Turn on BitLocker and Windows shoved 0x80310022 in your face — annoying, but it's actually BitLocker doing its job.

The fix

The error means you're trying to encrypt a volume without a recovery protector in place. BitLocker flat-out refuses to encrypt a drive that only has a TPM protector, because if the TPM chokes or the motherboard dies, your data is gone. The fix is to add a recovery password before you enable encryption.

Open an elevated PowerShell and run:

$vol = "C:"
Add-BitLockerKeyProtector -MountPoint $vol -RecoveryPasswordProtector

# confirm the protector landed
Get-BitLockerVolume -MountPoint $vol | Select-Object -ExpandProperty KeyProtector

# now turn on encryption
Enable-BitLocker -MountPoint $vol -EncryptionMethod XtsAes256 -UsedSpaceOnly -SkipHardwareTest

If you're on the legacy CLI instead, the equivalent is:

manage-bde -protectors -add C: -RecoveryPassword
manage-bde -on C: -used

That second command is the one that matters. The first one is what 0x80310022 is asking for. Order is non-negotiable — protectors first, encryption second.

Once the recovery password is set, grab the 48-digit key and stash it somewhere real:

(Get-BitLockerVolume -MountPoint "C:").KeyProtector |
  Where-Object KeyProtectorType -eq 'RecoveryPassword' |
  Select-Object -ExpandProperty RecoveryPassword

Write it down, print it, save it to your password manager. Don't text it to yourself. Don't leave it on the same machine you just encrypted.

Why this works

BitLocker's threat model assumes the TPM alone is a single point of failure. TPMs die. Firmware updates brick them. Secure Boot config changes invalidate the PCR measurements the TPM sealed the key against, and then you're staring at a recovery prompt with no recovery key. Microsoft decided years ago that a TPM-only configuration is too fragile for production, so the FVE (Full Volume Encryption) API checks for a recovery protector before it'll even start the encryption job. Error 0x80310022 is that check firing.

You're not going to disable the check by fighting it. Some forum posts suggest tweaking HKLM\SOFTWARE\Policies\Microsoft\FVE to skip recovery. Don't. Those policies exist for OOBE scenarios where the recovery key is escrowed to Azure AD or a management server automatically, not to let you encrypt a laptop with no way back in.

When it happens automatically

You'll usually see this in a few specific scenarios:

• Fresh Windows 11 23H2/24H2 installs where you've disabled the automatic BitLocker provisioning via PreventDeviceEncryption in the registry or via GPO, then try to enable BitLocker manually without a recovery protector.
• Intune or ConfigMgr deployments where the BitLocker CSP policy is set to RequireDeviceEncryption but the recovery key escrow policy hasn't applied yet. The device tries to encrypt, finds no recovery protector, and logs 0x80310022 in the BitLocker-API event log.
• Servers being encrypted with a TPM only because someone read a blog post about TPM-only being "more secure."
• SCCM task sequences where the "Enable BitLocker" step runs before the "Configure key protectors" step. Reorder them.

In Intune specifically, check that you've got both the BitLocker base settings profile and the OS drive recovery profile assigned to the same group. If only the base profile applies, encryption starts and dies with 0x80310022.

The less common variations

Sometimes you'll add a recovery password and still get the error. Here's what to check:

1. Group Policy is stripping the protector

If Choose how BitLocker-protected operating system drives can be recovered is set to require AD backup and the machine can't reach a DC, the protector gets rejected. Check the BitLocker event log under Applications and Services Logs > Microsoft > Windows > BitLocker-API > Management. You'll see a rejection reason.

gpresult /h C:\temp\rsop.html

Look for the FVE policy under Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption. If it's locked down and you can't change it, talk to whoever owns the GPO — fighting it locally is a waste of time.

2. You're encrypting a data volume, not the OS drive

Fixed data drives need a recovery protector too, but they use a different one by default on some builds. Run:

Add-BitLockerKeyProtector -MountPoint "D:" -RecoveryPasswordProtector
Enable-BitLocker -MountPoint "D:" -UsedSpaceOnly

3. The TPM isn't owned or initialized

If Get-Tpm shows TpmReady: False or TpmPresent: False, BitLocker can't even get to the recovery-protector check. Fix the TPM first. On most Dells and HPs, that's a BIOS setting — PTT on Intel boards, fTPM on AMD. Clear it, reinitialize, reboot, then try again.

4. You're using a virtual machine

Hyper-V Gen 2 VMs need the TPM enabled in VM settings and a key protector added the same way. VMware added vTPM support in vSphere 6.7 — make sure the VM hardware version supports it. If you're just testing, skip the TPM entirely:

Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -RecoveryPasswordProtector -UsedSpaceOnly

No -TpmProtector, no problem. BitLocker is happy with just a recovery password on a test box.

Prevention

Build the recovery protector into your deployment instead of hitting this later. For standalone machines, script it:

Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector | Out-Null
Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -UsedSpaceOnly -SkipHardwareTest

For managed fleets, the order in Intune/ConfigMgr matters more than anything else. Recovery key escrow policy must apply before the encryption policy. Test it in a ring — you'll catch 0x80310022 in the pilot group instead of on 400 laptops at once.

For AD-joined machines, make sure the BitLocker recovery information backup GPO is enabled and that gpupdate /force actually ran before your encryption step. If the DC is unreachable, either fix that or switch to a script that adds the protector locally and escrows to Azure AD via BackupToAAD-BitLockerKeyProtector.

And store those 48-digit keys somewhere you can actually get to. A recovery key you can't find is the same as no recovery key — except you also lose all your data.