BitLocker FVE_E_POLICY_PASSWORD_REQUIRED (0x8031002C) fix

Yeah, this one's a pain. You're sitting there, ready to encrypt a drive with BitLocker, and boom — error 0x8031002C with that lovely FVE_E_POLICY_PASSWORD_REQUIRED message. It's not hardware, not a drive failure. It's group policy throwing a fit because you haven't set up a recovery password. Let's kill this thing.

The fix — change the group policy

The culprit here is almost always a single GPO setting that insists on a recovery password before BitLocker can start. On a domain-joined machine, that policy is pushed from your domain controller. On a standalone PC, it's in the local group policy editor. Here's the exact path:

1. Open gpedit.msc (or wait — if you're on Windows 10/11 Home, you'll need the registry fix below).
2. Go to: Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives.
3. Find "Require additional authentication at startup" — double-click it.
4. Set it to Enabled, then under "Allow BitLocker without a compatible TPM", check the box.
5. Under "Configure TPM startup PIN", select "Allow startup PIN with TPM" or "Do not allow startup PIN" — your call.
6. Click OK, then run gpupdate /force in an admin command prompt.

If you're still getting the error, also check:

Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption

Look for "Choose drive encryption method and cipher strength" — make sure it's set to Enabled and choose XTS-AES 128-bit (or whatever your org uses). Then re-run gpupdate /force.

No gpedit.msc? Use the registry

Windows Home users don't have the Local Group Policy Editor. Don't bother installing it — the registry tweak is faster.

reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v "UseTPM" /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v "UseTPMPIN" /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v "UseTPMKey" /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v "UseTPMKeyPIN" /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v "OSRecovery" /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v "RecoveryPassword" /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v "RecoveryKey" /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v "OSManageDRA" /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v "OSRecoveryPasswordUsageCounter" /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v "OSRecoveryKeyUsageCounter" /t REG_DWORD /d 0 /f

Then reboot. After that, BitLocker should let you encrypt without demanding a recovery password. If you want to set a recovery password anyway (smart), use manage-bde -protectors -add C: -RecoveryPassword after encryption starts.

Why this happens

BitLocker follows a specific order of protectors: TPM, PIN, startup key, recovery password. The policy FVE_E_POLICY_PASSWORD_REQUIRED means the GPO says "you must have a recovery password defined as a protector before encryption can begin." It's a safety net so you don't get locked out. But sometimes the policy is misconfigured — either it's set to "Require recovery password" without giving you the option to skip it, or the TPM startup settings conflict. The fix basically tells Windows "hey, it's okay to start without a recovery password — just use the TPM."

Less common variations

I've seen this error pop up in a few weird scenarios:

• BitLocker Network Unlock — If your org uses Network Unlock (BitLocker unlocks via a DHCP challenge), the policy might block local recovery passwords. You'll need to configure the Network Unlock certificate properly. Check HKLM\SOFTWARE\Policies\Microsoft\FVE\FVE_OS_NETWORK_UNLOCK.
• Windows 11 22H2+ — Microsoft changed the default encryption method to XTS-AES 256. If your GPO forces XTS-AES 128, you'll get this error. Check "Choose drive encryption method and cipher strength" — set it to "Enabled" and pick XTS-AES 128.
• Third-party encryption software — Old versions of McAfee or Symantec endpoint encryption sometimes leave behind registry keys that block BitLocker. Look for HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE\FVE_OS_NONREPAIRABLE — if it's set to 1, delete it.
• Corrupted TPM — Rare, but if you've cleared the TPM recently, the policy can get confused. Run tpm.msc and check if the TPM is ready. If not, clear it via the BIOS and re-initialize.

Prevention — don't let this happen again

For domain environments: audit your BitLocker GPOs before deploying. Use the BitLocker Group Policy Settings report in Group Policy Management Console. Ensure you have a baseline that includes:

• Operating System Drives → Require additional authentication at startup → Enabled, with Allow BitLocker without a compatible TPM unchecked (if all machines have TPM).
• Operating System Drives → Configure recovery password rotation → Enabled for 30-day rotation.
• Fixed Data Drives and Removable Data Drives — set Deny write access to unencrypted drives if needed.

For standalone machines: after fixing it once, export the registry keys under HKLM\SOFTWARE\Policies\Microsoft\FVE as a .reg file. That way, if a reimage or Windows update resets the policy, you just double-click the file. I keep one on a USB stick labeled "BitLocker rescue" — saved my ass more than once during imaging cycles.

One more thing: don't bother with chkdsk or sfc /scannow here. This isn't a corrupted system file or bad sectors. It's purely a policy conflict. Stick to the GPO or registry fix and you'll be encrypted in ten minutes.