A fresh Windows 11 24H2 install can already be encrypted with BitLocker and still be wide open. On our test machine, manage-bde reported the system drive as 100% encrypted with XTS-AES 128, protection off and no key protectors at all. The key that decrypts the drive sat on the disk in the clear, and nobody had a recovery key because none existed yet.
This guide closes that gap. You turn protection on with the TPM, back up the BitLocker recovery key on Windows 11 to a file and to Active Directory, then trigger the recovery screen on purpose and get back in. We also unlock a data drive with the 48-digit password and suspend protection for a firmware update. The Windows outputs below come from Windows 11 Enterprise 24H2 (build 26100) with a TPM 2.0 and Secure Boot, run in October 2026.
Check What BitLocker Is Already Doing
Start with the status, because since 24H2 Windows turns on device encryption on far more hardware than before. Microsoft dropped the Modern Standby, HSTI and DMA prerequisites for automatic device encryption in 24H2, so a desktop or VM that never encrypted itself on 23H2 now does it during a clean Windows 11 install. Open an elevated PowerShell or Command Prompt and ask for the status of the system drive.
manage-bde -status C:Our untouched 24H2 install reported the following. Read the last three lines together, because each one alone looks fine.
BitLocker Drive Encryption: Configuration Tool version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. All rights reserved.
Volume C: [Windows]
[OS Volume]
Size: 62.71 GB
BitLocker Version: 2.0
Conversion Status: Used Space Only Encrypted
Percentage Encrypted: 100.0%
Encryption Method: XTS-AES 128
Protection Status: Protection Off
Lock Status: Unlocked
Identification Field: Unknown
Key Protectors: None FoundEncrypted, but “Protection Off” with “None Found” means BitLocker is running on a clear key. The data is scrambled on disk, yet the key to unscramble it is stored unprotected next to it, so anyone who pulls the drive can read it. Device encryption stays in this state until a recovery key gets backed up to a Microsoft account, Entra ID or AD DS, and a machine set up with a local account never reaches that step. Control Panel shows the same state as “BitLocker waiting for activation”, which most people read as “nothing to do”.
You also need to confirm the hardware side. These checks come from Microsoft’s BitLocker requirements and are what our lab VM passed:
- TPM 1.2 or later, present and ready (
Get-Tpm) - UEFI firmware in native mode, CSM off, Secure Boot on (
Confirm-SecureBootUEFI) - Windows 11 Pro, Enterprise or Education for full BitLocker
- Windows 11 Home: device encryption only, no
manage-bdepolicy control
One elevated PowerShell line answers the first two.
Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled; Confirm-SecureBootUEFIAll three TPM values must read True and Secure Boot must print True. If Secure Boot is off, BitLocker cannot bind to PCR 7 and falls back to a profile that measures the boot path more broadly, which triggers recovery far more often. Our VM passed both.
TpmPresent TpmReady TpmEnabled
---------- -------- ----------
True True True
TrueWith both checks passing, the drive is ready for real protectors. If either one fails, fix it in the firmware setup first. Changing Secure Boot after BitLocker is on is one of the documented recovery triggers, so if you must change it later, suspend BitLocker before you do.
Enable BitLocker with the TPM and a Recovery Password
Add the recovery password first, then the TPM protector, and only then switch protection on. In that order you can never end up with a TPM-only drive that has no way back in. If your status already shows “Protection On” with TPM and Numerical Password listed, device encryption already finished the job. Skip to the backup sections, because a second recovery password is one you will later confuse with the first. The recovery password is the 48-digit number people call the BitLocker recovery key.
manage-bde -protectors -add C: -RecoveryPasswordWindows prints the new protector’s ID and the password itself. Both matter, because the ID is what the recovery screen shows you later and the password is what you type.
Key Protectors Added:
Numerical Password:
ID: {CA480C40-000C-42F2-9D9E-06958BA8F1DB}
Password:
044044-710864-349426-144870-177023-555830-396165-205799
ACTIONS REQUIRED:
1. Save this numerical recovery password in a secure location away from
your computer:
044044-710864-349426-144870-177023-555830-396165-205799
To prevent data loss, save this password immediately. This password helps
ensure that you can unlock the encrypted volume.That password belonged to a lab VM we destroyed afterwards. Never paste your own into a ticket, chat or screenshot. Next, seal the drive to the TPM.
manage-bde -protectors -add C: -tpmThe PCR validation profile line tells you what the TPM will check at every boot. On a UEFI machine with Secure Boot it is PCR 7, which records the Secure Boot policy and certificates, and PCR 11, which BitLocker uses for its own boot-manager handoff.
Key Protectors Added:
TPM:
ID: {71033D4A-D75C-4106-A063-AD66487ACD9B}
PCR Validation Profile:
7, 11
(Uses Secure Boot for integrity validation)Status still says “Protection Off” at this point, which surprised us. Adding protectors to a clear-key volume does not arm it. manage-bde -on does, and on an already encrypted drive it skips the encryption pass and the hardware-test reboot.
manage-bde -on C:The output confirms it reused the protectors you just added and only flipped protection on.
Volume C: [Windows]
[OS Volume]
NOTE: This command did not create any new key protectors. Type
"manage-bde -protectors -add -?" for information on adding more key protectors.
NOTE: Encryption is already complete.
Turned on BitLocker protection by enabling key protectors.Run manage-bde -status C: again and you should now see “Protection On” with “Numerical Password” and “TPM” listed under Key Protectors. We rebooted at this point and the machine came up with no prompt, which is the whole point of the TPM: it releases the key silently as long as PCR 7 and 11 match. On a drive that was never encrypted, the same manage-bde -on C: starts a full encryption pass and asks for a reboot first to run its hardware test, unless you add -SkipHardwareTest.
If you prefer the GUI, Control Panel, System and Security, BitLocker Drive Encryption shows the same state and the same actions. The links you need are easy to miss because they only appear once you expand the drive.
- 1Back up your recovery key
- 2Suspend protection
- 3Waiting for activation
- Back up your recovery key saves the 48-digit key to a file, a USB drive or a Microsoft account, or prints it.
- Suspend protection is the switch for firmware and BIOS updates, covered below.
- Waiting for activation marks a drive device encryption grabbed on its own, with no protector yet.
That third line is a disk we had formatted a minute earlier. More on that in the errors section, because it bit us.
Save the Recovery Key to a File
Keep at least one copy of the recovery key off the machine it protects, because a key stored only on the encrypted drive is useless the day you need it. On a personal machine signed in with a Microsoft account, Windows offers to save the key to that account; on a domain machine, AD (next section) is the copy that counts. A file on a USB stick or a password manager entry is the copy you control. Start by printing the key.
manage-bde -protectors -get C: -Type RecoveryPasswordOnly the numerical password protector comes back, with its ID. On a drive that has had its keys rotated you may see several, and the ID is how you tell them apart.
Volume C: [Windows]
Key Protectors of Type Numerical Password
Numerical Password:
ID: {CA480C40-000C-42F2-9D9E-06958BA8F1DB}
Password:
044044-710864-349426-144870-177023-555830-396165-205799To write it straight to removable media, use the BitLocker PowerShell module. Change K: to your stick’s drive letter. The file name carries the computer name, so a stick that holds keys for several machines stays readable.
$kp = (Get-BitLockerVolume -MountPoint C:).KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword'
$kp | Select-Object KeyProtectorId, RecoveryPassword | Format-List | Out-File "K:\$env:COMPUTERNAME-bitlocker-recovery.txt"
Get-Content "K:\$env:COMPUTERNAME-bitlocker-recovery.txt"The file holds both values you will need at the recovery screen.
KeyProtectorId : {CA480C40-000C-42F2-9D9E-06958BA8F1DB}
RecoveryPassword : 044044-710864-349426-144870-177023-555830-396165-205799You can also put a recovery key file on the stick, which is a different protector from the password. BitLocker writes a small binary .BEK file, and the boot manager reads it automatically when the stick is plugged in at boot, so nobody has to type 48 digits. The boot manager can only read it from an unencrypted volume, and on 24H2 a disk that Windows sees as fixed may already be encrypted (see the errors section), so run manage-bde -status K: first and manage-bde -off K: if it reports any encryption.
manage-bde -protectors -add C: -RecoveryKey K:\The file is named after the protector ID and created hidden and read-only, 180 bytes on our stick.
Key Protectors Added:
Saved to directory K:\
External Key:
ID: {FF254201-79A2-4139-B154-2F47047FD664}
External Key File Name:
FF254201-79A2-4139-B154-2F47047FD664.BEKTreat that stick like the key to the building. Anyone holding it can unlock the drive without knowing a single digit, so store it apart from the laptop.
Back Up the BitLocker Key to Active Directory
On domain-joined machines, AD DS is where the help desk looks first, and the recovery screen literally tells the user to contact the help desk. BitLocker stores each recovery password as an msFVE-RecoveryInformation object under the computer account, and only Domain Admins can read it by default. Our lab domain ran on a Samba 4.23 AD DC at the 2008 R2 functional level. Its schema carries the same class a Windows Server DC uses, and nothing changes on the client side.
The Group Policy setting lives under Computer Configuration, Administrative Templates, Windows Components, BitLocker Drive Encryption, Operating System Drives, and is called “Choose how BitLocker-protected operating system drives can be recovered”. Enable it, then set three options inside it.
- Save BitLocker recovery information to AD DS for operating system drives: on
- Configure storage of BitLocker recovery information to AD DS: recovery passwords and key packages
- Do not enable BitLocker until recovery information is stored to AD DS: on
Link the GPO to the OU that holds the computer accounts, then run gpupdate /force on a client or reboot it. The third option blocks BitLocker from turning on while no DC is reachable, so a laptop being set up off the network waits until it can reach one. To confirm the GPO landed on a client, look under HKLM\SOFTWARE\Policies\Microsoft\FVE, where OSActiveDirectoryBackup should read 1. The policy only acts when BitLocker gets enabled, though. A drive where BitLocker was already turned on before the policy arrived never uploads its key by itself, and that includes the drive you just protected by hand. Push the key once by hand with the protector ID from earlier.
manage-bde -protectors -adbackup C: -id {CA480C40-000C-42F2-9D9E-06958BA8F1DB}Run it from Command Prompt as written. In PowerShell, wrap the ID in single quotes, because PowerShell treats bare curly braces as a script block. A successful upload prints one line.
Recovery information was successfully backed up to Active Directory.The PowerShell equivalent looks the ID up for you, which is the better choice in a script you push to many machines, since every machine has a different protector ID. It loops because -KeyProtectorId takes one ID, and a drive whose keys were rotated can hold more than one recovery password.
(Get-BitLockerVolume -MountPoint C:).KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword' | ForEach-Object { Backup-BitLockerKeyProtector -MountPoint 'C:' -KeyProtectorId $_.KeyProtectorId }Windows logs the result in Event Viewer under Applications and Services Logs, Microsoft, Windows, BitLocker-API, Management. Event 784 is a successful upload. Event 783 means AD already holds that protector, which is what our second run produced. After the upload, manage-bde -protectors -get C: also shows a “Backup type: AD backup” line under the numerical password.
Do not take the client’s word for it. Read the key back from the directory. On the Samba DC, ldbsearch shows the object BitLocker created.
sudo ldbsearch -H /var/lib/samba/private/sam.ldb "(objectClass=msFVE-RecoveryInformation)" msFVE-RecoveryPasswordThe object’s name is a timestamp plus the protector ID, and it sits directly under the computer account. The line break in the password is how LDIF wraps long values, not part of the key.
dn: CN=2026-10-30T23:08:29\+03:00{CA480C40-000C-42F2-9D9E-06958BA8F1DB},CN=WIN11-01,CN=Computers,DC=corp,DC=example,DC=com
msFVE-RecoveryPassword: 044044-710864-349426-144870-177023-555830-396165-20579
9From any Windows machine in the domain, a plain LDAP query does the same job against Samba or a Windows DC. We used it instead of the RSAT Active Directory module because that module talks to AD Web Services, which Samba does not run. The query looks up the local computer, so put another name in place of $env:COMPUTERNAME to check a different machine. Enter Domain Admin credentials at the prompt.
$cred = Get-Credential CORP\Administrator
$computer = ([adsisearcher]"(&(objectClass=computer)(name=$env:COMPUTERNAME))").FindOne().Path
$entry = New-Object DirectoryServices.DirectoryEntry($computer, $cred.UserName, $cred.GetNetworkCredential().Password)
$search = New-Object DirectoryServices.DirectorySearcher($entry, '(objectClass=msFVE-RecoveryInformation)', @('name','msFVE-RecoveryPassword'))
$search.FindAll() | ForEach-Object { [pscustomobject]@{ Name = $_.Properties['name'][0]; RecoveryPassword = $_.Properties['msfve-recoverypassword'][0] } } | Format-ListIt returns the same password the client printed, so the AD copy is good.
Name : 2026-10-30T23:08:29+03:00{CA480C40-000C-42F2-9D9E-06958BA8F1DB}
RecoveryPassword : 044044-710864-349426-144870-177023-555830-396165-205799We ran the same query as the computer’s own account and it returned nothing, because the machine can create its recovery object but cannot read it back. That is the protection you want, and it is why help desk staff need Domain Admin rights or delegated read access to the attribute. On a Windows Server DC, the RSAT BitLocker Recovery Password Viewer adds a BitLocker Recovery tab to Active Directory Users and Computers for the same lookup; our Active Directory Domain Services guide covers building that DC.
Test the BitLocker Recovery Screen and Get Back In
You don’t know a backup works until you’ve recovered from it, so force the recovery screen on purpose before a firmware update or a dead motherboard does it for you. Real triggers include a TPM clear, a Secure Boot change, a firmware update that changes PCR 7, moving the drive to another machine, or a boot manager that isn’t Windows. -forcerecovery gives the same result without touching the firmware. Before you run it, read the recovery password from a copy that does not live on this PC, either the AD lookup above or the file opened on another machine, because afterwards the password or the .BEK is the only way in. On a VM, take a snapshot first, as we did.
manage-bde -forcerecovery C:It is not a flag for the next boot. It deletes every TPM protector, so the drive stays in recovery until you add one back.
TPM:
ID: {71033D4A-D75C-4106-A063-AD66487ACD9B}
PCR Validation Profile:
7, 11
(Uses Secure Boot for integrity validation)
Key protector with ID "{71033D4A-D75C-4106-A063-AD66487ACD9B}" deleted.
Only a recovery password or recovery key can unlock volume C:.We pulled the key stick and rebooted. Because the drive had a .BEK protector, the boot manager asked for the USB drive before anything else. Esc leads to the 48-digit prompt.
With the stick plugged back in and the machine restarted, Windows booted straight through without a single prompt, because the boot manager found the .BEK file and used it. A machine without a key file shows the classic recovery screen instead. We removed the external key protector, forced recovery again, and got the screen most users will see.
- 148-digit recovery key
- 2Recovery key ID
- The 48-digit recovery key field takes digits only; number keys or F1 to F10 (F10 for 0).
- The Recovery key ID tells you which saved key to use.
Match the ID on the screen against the ID in your backup before you type anything. Ours read CA480C40-000C-42F2-9D9E-06958BA8F1DB, the same ID as the file on the stick and the AD object name. That matters on any machine that has been re-encrypted or had keys rotated, because AD keeps every old recovery object until the computer account is deleted, and only one of them opens this drive. Each six-digit group carries a checksum, so the recovery console catches most typos as you go.
Once you’re back in Windows, the drive still has no TPM protector, so it will stop at recovery on every boot until you reseal it. Microsoft’s forcerecovery reference does not spell out this step. Add the protector back from an elevated prompt.
manage-bde -protectors -add C: -tpmA new TPM protector appears with a new ID and the same 7, 11 profile, and the next reboot is silent again.
Key Protectors Added:
TPM:
ID: {CB1DED08-A7A6-4492-B12E-0FB404ABCB29}
PCR Validation Profile:
7, 11
(Uses Secure Boot for integrity validation)After a real recovery event, rotate the password you just typed. A key that has been read aloud over the phone or typed in front of someone is no longer secret. Add a new recovery password and back it up to AD, then delete the old protector by its ID with manage-bde -protectors -delete C: -id.
Use the 48-Digit Key to Unlock a Data Drive
Fixed data drives and external disks use the same recovery password, and this is where you will type it most often, on a disk moved to another PC or a second drive that was encrypted without auto-unlock. We encrypted an 8 GB second disk as F: with only a recovery password and rebooted. It came back locked, and PowerShell could not even find a drive named F:. The status shows why.
Volume F: [Label Unknown]
[Data Volume]
Size: Unknown GB
BitLocker Version: 2.0
Conversion Status: Unknown
Percentage Encrypted: Unknown%
Encryption Method: XTS-AES 256
Protection Status: Unknown
Lock Status: Locked
Identification Field: Unknown
Automatic Unlock: Disabled
Key Protectors:
Numerical PasswordSize, conversion state and protection all read Unknown because Windows cannot read the volume metadata until it has the key. Unlock it with the password, dashes included.
manage-bde -unlock F: -RecoveryPassword 401137-429517-367642-365871-566852-629453-495253-453024A correct password gives a one-line confirmation, and the volume mounts under its old letter.
The password successfully unlocked volume F:.So the drive does not lock again at the next boot, let Windows unlock it automatically whenever the protected OS drive is unlocked. Auto-unlock adds an external key protector that Windows keeps on the protected C: drive, which is why C: has to be under BitLocker first.
manage-bde -autounlock -enable F:The status now lists the extra protector and shows “Automatic Unlock: Enabled”.
Conversion Status: Fully Encrypted
Percentage Encrypted: 100.0%
Encryption Method: XTS-AES 256
Protection Status: Protection On
Lock Status: Unlocked
Identification Field: Unknown
Automatic Unlock: Enabled
Key Protectors:
Numerical Password
External Key (Required for automatic unlock)That drive uses XTS-AES 256 because we chose it when encrypting, which the next errors section shows has to happen before Windows encrypts the disk itself. Existing drives keep the algorithm they were encrypted with, and changing it means manage-bde -off and a full re-encryption. The C: drive on our machine stayed on XTS-AES 128 for that reason, which is still a sound choice.
Suspend BitLocker Before a Firmware Update
A BIOS or UEFI update can change the measurements in PCR 7, and then the next boot lands on the recovery screen. Suspending protection first stores the key in the clear for a set number of reboots, then BitLocker reseals to the new measurements and turns itself back on. Microsoft’s Suspend-BitLocker reference allows 0 to 15 reboots, and 0 means suspended until you resume it by hand.
Suspend-BitLocker -MountPoint 'C:' -RebootCount 1 | Format-List MountPoint, VolumeStatus, ProtectionStatus, EncryptionPercentageThe drive stays fully encrypted, and only the protection check is off.
MountPoint : C:
VolumeStatus : FullyEncrypted
ProtectionStatus : Off
EncryptionPercentage : 100manage-bde -status C: spells out the countdown as “Protection Off (1 reboots left)”. Firmware tools that flash during the restart sometimes reboot more than once, so give a vendor BIOS update a count of 2 or 3 rather than 1. On our machine one plain restart used up the count, and manage-bde -status C: read “Protection On” again as soon as Windows was back, with no prompt and no command from us. If you suspended with 0, nothing re-arms it, so run Resume-BitLocker -MountPoint 'C:' once the update is done.
Errors We Hit Along the Way
None of these came from a broken setup. They are what 24H2’s automatic device encryption and BitLocker’s own checks do on a clean install, and each one has a quick fix.
“ERROR: An error occurred (code 0x80070057): The parameter is incorrect.”
We added a new 8 GB disk and partitioned and formatted it as F:. Within seconds Windows had started encrypting it with XTS-AES 128 on a clear key, logged as event 4146, “Device Encryption initialized automatically for volume F:”. Our manage-bde -on F: -RecoveryPassword -EncryptionMethod xts_aes256 then failed with 0x80070057, because the volume was already mid-conversion with another algorithm. Decrypt it first, which took seconds on an empty disk, then encrypt it the way you want.
manage-bde -off F:
manage-bde -on F: -EncryptionMethod xts_aes256 -RecoveryPasswordA full pass, not used-space-only, on the 8 GB disk finished in about four minutes. On a large, new disk -UsedSpaceOnly is much faster and new writes get encrypted anyway. Skip it on a disk that held data before, because the free space is left as it was and deleted files can still be recovered from it.
The recovery key stick was encrypted too
The 1 GB FAT32 disk we used as a key stick was also encrypted automatically within seconds of formatting, and Control Panel listed it as “BitLocker waiting for activation”. A .BEK file on an encrypted volume is useless, because the boot manager cannot read it before Windows starts. Device encryption only grabs fixed disks, so a real USB stick stays plain, but a second internal disk or a USB enclosure that reports itself as fixed can get encrypted. Check with manage-bde -status K: and run manage-bde -off K: before you rely on it.
“ERROR: The password failed to unlock volume F:.”
We changed the last digit of the recovery password on purpose. manage-bde -unlock returned exit code 0x80310035 with that message and nothing else. It does not say whether the password is wrong or belongs to another protector. Before you assume a typo, check that the backup you are reading belongs to this drive, which is why the file and the AD object both keep the protector ID next to the password.
If you dual boot, the Fedora and Windows 11 dual boot guide covers why GRUB triggers this same recovery screen. The Secure Boot certificate update is the next PCR 7 change most fleets will see, so suspend BitLocker before you apply it. Linux machines get the same TPM-sealed unlock through LUKS and systemd-cryptenroll.
