BitLocker recovery keys: make sure you can unlock a restored or replaced Windows machine

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

If a Windows drive is protected by BitLocker, you will usually unlock it after a hardware change or a restore with its 48-digit recovery password. That password is useful only if a usable copy is available independently of the locked drive, the save succeeded, the key still matches the drive, and someone on the recovery team has permission to read it.

Each of those conditions can fail without anyone noticing. The time to find out is before a server or laptop is sitting at the blue recovery screen.

This article draws on Microsoft's BitLocker, Entra ID and Intune documentation. The commands are quoted from that documentation and were not run in a lab for this article.

Why it matters

BitLocker encrypts the whole volume. On a machine with a Trusted Platform Module (TPM), the TPM normally releases the key without any prompt, so users and administrators may never see a recovery password in the machine's working life. The first time they need one is often the worst possible moment: a laptop has a new motherboard, a physical server has been restored to replacement hardware, or a firmware update has run while protection was active.

Microsoft is blunt about what the recovery password grants. Anyone holding it can unlock the volume and access all of its data, so it must be stored securely and separately from the device it protects. This creates the familiar tension in recovery planning. The key has to be easy for the right people to reach on a bad day and hard for everyone else to reach on every other day.

For a business, a missing key turns a hardware repair into data loss. If the only copy of a file existed on that drive and nobody can produce the key, the data is gone. A readable file backup can help. An encrypted image can also be recoverable when the necessary key material is available and the backup product supports that restore path.

What sends a machine into recovery

Microsoft's BitLocker recovery overview lists the common triggers. Several of them are routine events in a recovery or repair:

• moving a BitLocker-protected drive into a new computer
• replacing the motherboard with one that has a new TPM
• turning off, disabling, deactivating or clearing the TPM
• upgrading early startup components such as BIOS or UEFI firmware
• changes to the boot manager or to the disk's partition table
• using PXE boot, or putting a CD or DVD drive ahead of the hard drive in the boot order
• changing the Platform Configuration Registers (PCRs) the TPM checks.

PCRs are TPM registers that record measurements of the firmware and boot components. BitLocker seals the key to a set of those measurements. If the measurements change, the TPM does not release the key and Windows asks for a recovery method instead.

Microsoft's BitLocker FAQ adds a point that matters for spare parts. Drives can be swapped on the same computer only if they were BitLocker-protected on that computer, because the keys are unique to the TPM and the operating system drive. A spare drive prepared on a different machine will not unlock silently.

Planned changes: suspend first

For a known hardware or firmware change, the overview says recovery can be avoided by temporarily suspending BitLocker protection. Suspension leaves the drive encrypted. When protection resumes, the key is resealed to the new measurements without anyone typing a recovery password.

There is a catch worth knowing. If protection is suspended without a reboot count, BitLocker automatically resumes at the next restart. In our reading, a firmware update that needs two restarts can therefore trip recovery on the second one. The BitLocker operations guide documents suspending with Suspend-BitLocker or manage-bde -protectors -disable, and the overview notes that a reboot count can be set through PowerShell or manage-bde.

The FAQ also records that when a policy requires the key to be backed up, Windows waits up to 60 seconds for a network connection on resume, and protection won't resume if the backup fails. On a machine without network access during maintenance, a drive can stay in a suspended state. Our reading is that this belongs on any post-maintenance check: confirm the protection status is back to "on".

Unplanned changes: the restore case

A restore is rarely planned around BitLocker. A physical server fails, the image is restored to a replacement chassis, and the new TPM does not hold the old key. Whether you see a recovery screen at all depends on how the backup captured the data.

Our reading, which depends on the backup product rather than on Windows, is this:

• A backup that reads the volume through Windows, while it is unlocked, captures readable data. The destination encryption state depends on the target volume and restore product; readable backup content does not itself preserve the original BitLocker protection. BitLocker then needs to be turned on again and a new key escrowed.
• A backup that copies the raw encrypted disk blocks captures encrypted data. The restored volume is still locked by the original volume key and needs its recovery password or another protector.

Ask your backup vendor which of these applies, and test it. Both outcomes create a recovery task. The first leaves a restored machine unprotected until someone notices. The second leaves it unreadable until someone finds the key.

Where recovery information can live

BitLocker supports several kinds of recovery information. The recovery overview describes them:

Microsoft's recommendation is to store recovery information centrally and automatically: in Entra ID for Entra-joined devices, and in AD DS for Active Directory-joined devices.

Active Directory

In AD DS, each recovery password lives in a child object of the computer object, of class ms-FVE-RecoveryInformation. The overview says AD keeps a history of all recovery passwords for a computer object, and old recovery keys are not removed automatically unless the computer object is deleted. The FAQ repeats this: entries are not overwritten, so several passwords might appear for one drive and the object date identifies the latest.

Two consequences follow. First, the recovery screen shows a recovery key ID, and you should match that ID rather than taking the newest entry on trust. The recovery process describes finding the password by the first eight characters of the password ID with the BitLocker Recovery Password Viewer, an extension to Active Directory Users and Computers that ships with the Remote Server Administration Tools. Second, deleting a computer object deletes its recovery history. A stale-object clean-up script is therefore a recovery risk, not only a tidiness job.

By default, only Domain Administrators can read BitLocker recovery information in AD DS, though access can be delegated. Delegation matters during a recovery. If the only people who can read keys are the people who are rebuilding domain controllers, the laptop queue waits.

The key package is not saved by default. To store it in AD DS, the policy that sets the recovery method must select the option to back up the recovery password and key package. Microsoft also documents exporting one from a working volume with manage-bde -KeyPackage, which requires local administrator access to the volume before it is damaged.

Entra ID and Intune

For Entra-joined and hybrid-joined devices, the recovery password is stored as a bitlockerRecoveryKey resource on the device object. Microsoft documents retrieving it from the Entra admin center, the Intune admin center, PowerShell or Microsoft Graph.

Three Entra and Intune details matter for recovery planning:

• Deleting the device deletes the keys. Microsoft's guidance on stale devices states that deleting a stale device also deletes the BitLocker keys stored on it, and there is no way to recover them afterwards. An automated stale-device policy can remove the only key for a laptop that has spent three months in a drawer.
• There is a per-device limit. Intune's documentation says Entra ID supports a maximum of 200 BitLocker recovery keys per device, and silent encryption fails once that limit is reached because the key backup fails first.
• Viewing a key is audited. Selecting Show Recovery Key creates an audit log entry under KeyManagement. Reading keys is restricted to the device owner and to roles such as Cloud Device Administrator, Helpdesk Administrator and Intune Administrator, and administrators can block owners from reading their own keys.

Entra-joined and hybrid-joined devices can also rotate the recovery password automatically after it has been used to unlock the drive. Rotation is good security, but it means the password a technician wrote on a ticket last month is no longer valid. Match the recovery key identifier to the volume being recovered. An older encrypted image can require its historical protector, not the newest password stored for the live device.

Note that Microsoft says Windows Server doesn't support configuring BitLocker with a configuration service provider or Configuration Manager, and Group Policy is used instead. BitLocker is also an optional component on Windows Server and has to be added before it can be used. Server escrow is therefore normally an AD DS design, even in organisations that manage laptops through Intune.

The failure modes that catch teams

The backup to AD DS never happened

This is a gap that an enabled-encryption indicator does not reveal. The FAQ states that if BitLocker was enabled before policy required a backup, the recovery information is not backed up automatically when the computer later joins the domain or the policy arrives. It also states that if the backup initially fails, for example because a domain controller is unreachable, BitLocker doesn't try again.

The protection against both is a policy option. In each of the three "Choose how BitLocker-protected … drives can be recovered" settings, the option Do not enable BitLocker until recovery information is stored in AD DS stops encryption from starting unless the backup succeeds. Microsoft's Important note in the FAQ adds that joining a new computer to the domain should be the first step, before BitLocker is turned on.

For machines encrypted before that policy existed, the operations guide documents backing up an existing protector. With the protector ID from manage-bde -protectors -get C: -Type RecoveryPassword, the commands are:

manage-bde.exe -protectors -adbackup C: -id {ID}
manage-bde.exe -protectors -aadbackup C: -id {ID}

The PowerShell equivalents are Backup-BitLockerKeyProtector for AD DS and BackuptoAAD-BitLockerKeyProtector for Entra ID. Microsoft notes that the braces must be included in the ID.

The event log said success

A client writes an event when a backup succeeds or fails. Microsoft warns that even a success event is not proof. The information could have been removed from AD DS later, BitLocker could have been reconfigured so the stored information no longer unlocks the drive, or the entry could be spoofed. The FAQ's answer is to query AD DS itself.

The key in the directory belongs to a removed protector

The operations guide recommends invalidating a recovery password after it has been used. Its example removes the recovery password protectors, adds a new one and backs it up. If the last step is skipped, the directory holds only passwords for protectors that no longer exist, and the machine has a password nobody has recorded.

The key went with the device record

A laptop that is reimaged, re-enrolled or cleaned up as stale can lose its Entra device object, and with it the keys. In AD DS, deleting a computer object removes its recovery objects. A drive that was removed from that machine and kept as evidence or as a data copy may now be unreadable.

The only key holder is unavailable

Recovery passwords for servers are often readable only by domain administrators. In an incident affecting the identity systems, those accounts may be locked down, being rotated or unusable. If the directory itself is unavailable, the keys stored in it are unavailable too. This is a design question, not a technical fault. For a small number of critical physical servers, our recommendation is to hold an encrypted, access-controlled offline copy of their recovery passwords, so that rebuilding the directory does not depend on first reading the directory.

How to prove the keys exist

A key check is a reconciliation between three lists: what each device has, what the directory holds, and who can read it.

1. On the device, list the protectors and their IDs. Get-BitLockerVolume C: | fl shows the protection status and protector types, and manage-bde -protectors -get C: lists each protector with its ID. Both are documented in the operations guide.
2. In the directory, confirm that a recovery password exists for every recovery password protector ID found on the device. In AD DS this means the ms-FVE-RecoveryInformation child objects. In Entra ID it means the bitlockerRecoveryKey entries, which Microsoft's recovery process shows retrieving with the Graph PowerShell cmdlet Get-MgInformationProtectionBitlockerRecoveryKey.
3. For people, confirm that the recovery team's accounts, and a backup account, can read keys without relying on a single person.

Run the comparison for the whole estate and keep the exceptions list. A device with a recovery password protector but no matching directory entry is your risk list. Reading a key creates an audit entry in Entra, so check that your audit review expects these reads.

For a physical server, add a desk exercise that changes nothing on the machine. Take the server's recovery password ID from your records, look it up as the recovery team would, and confirm that the named people can read it with the accounts they would actually use on the day. Do not trigger real recovery on a production server to test this. If you want to rehearse the recovery screen itself, use a non-production machine.

Decisions for physical servers

Physical servers bring a few questions that laptops do not.

Protector choice. A TPM-plus-PIN protector adds a startup PIN requirement, which needs an unattended-restart plan in a data centre. Microsoft documents BitLocker Network Unlock, which lets domain-joined machines on a trusted wired network unlock at boot without the PIN. It has its own software and hardware requirements for the clients, Windows Deployment Services and the domain controllers. If Network Unlock is part of the design, remember that it is itself a recovery dependency.

Hardware replacement. Before a motherboard or TPM replacement, suspend protection with a reboot count that covers the work. After a replacement that was not planned, expect recovery and have the key ready. Microsoft notes that if you move an operating system volume with a TPM protector to a different device and unlock it with a recovery protector, BitLocker binds to the new TPM, and returning it to the original device prompts for recovery again.

Data recovery agents. A Data Recovery Agent (DRA) is a certificate that acts as a master key for drives configured with its public key. Microsoft describes it as a way to recover any volume protected by the policy without finding a specific password per volume. The catch is that an operating system drive must be mounted as a data drive on another machine before a DRA can unlock it. A DRA's private key is also a very high-value secret, and losing it, or having it stolen, affects every drive at once.

Damaged drives. If the drive itself is damaged, the BitLocker Repair tool (repair-bde) can decrypt at block level using the key package and the recovery password. Microsoft lists limits: it can't repair a drive that failed during encryption or decryption, and it assumes a drive with any encryption is fully encrypted. Microsoft also recommends trying other diagnosis first, since the damage may not be related to BitLocker. The key package is not saved by default. Establish whether the required package can be retrieved from escrow or obtained from surviving recovery information; do not assume a damaged drive can still provide it.

Risks and limits

• This article does not cover third-party disk encryption or self-encrypting drives managed outside BitLocker.
• How a backup product handles a BitLocker volume, whether it reads plaintext through Windows or copies encrypted blocks, is a product question. Confirm it with the vendor and test it on a non-production machine.
• Microsoft's documentation describes product behaviour and limits at the date shown. Limits such as the 200-key ceiling can change.
• Commands that remove protectors or disable BitLocker change the security state of a machine. The operations guide says decryption should happen when protection is no longer required, and not as a troubleshooting step. None of the commands here was run for this article.
• An offline copy of recovery passwords is itself sensitive data. Who holds it, how it is encrypted and how access is logged are decisions for your security policy.

Sources

Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.

• Microsoft Learn: BitLocker recovery overview, last updated 2025-07-29.
• Microsoft Learn: BitLocker recovery process, last updated 2025-07-29.
• Microsoft Learn: BitLocker operations guide, last updated 2025-07-29.
• Microsoft Learn: BitLocker FAQ, dated 2026-06-01.
• Microsoft Learn: Configure BitLocker, last updated 2025-07-29.
• Microsoft Learn: Manage device identities in the Microsoft Entra admin center.
• Microsoft Learn: How to manage stale devices in Microsoft Entra ID.
• Microsoft Learn: Encrypt Windows devices with BitLocker in Intune, dated 2025-11-26.
• Microsoft Learn: manage-bde protectors.

This article was originally published on 13 November 2026.