Fixing BitLocker Recovery Keys Not Backed Up to Entra ID

A device sits at the blue BitLocker recovery screen, someone reads out the key ID, you open the Intune admin center, and there is nothing there. The BitLocker recovery key not backed up problem is one of the more stressful ones in endpoint management because it usually surfaces at exactly the moment you need the key and cannot produce it. This post is about why a key ends up missing from Entra ID, how to escrow it retroactively on devices you can still boot, and how to find the devices at risk before one of them locks a user out for good.

Key Takeaways

• A BitLocker recovery key not backed up to Entra ID almost always means the drive was encrypted before the escrow policy applied, or the device was only Entra registered rather than joined when encryption ran.
• On a device you can still boot, you can escrow the existing recovery password to Entra ID retroactively with BackupToAAD-BitLockerKeyProtector — no re-encryption needed.
• The same recovery password can be backed up to on-premises Active Directory with Backup-BitLockerKeyProtector or manage-bde -protectors -adbackup for hybrid environments.
• You can audit which devices actually have an escrowed key with the Microsoft Graph bitlocker/recoveryKeys endpoint, and fix them at scale with an Intune remediation script.
• None of this recovers a key that was never saved anywhere — the fix is preventive: require recovery-key escrow before encryption enables, which I cover in the deployment post.

Environment

• Microsoft Intune (Plan 1) with Windows 10/11 devices enrolled; the fleet remediation step uses Intune Remediations, which needs Windows Enterprise E3/E5 or an equivalent license.
• Entra ID, with devices Entra joined or Microsoft Entra hybrid joined — a device that is only Entra registered will not escrow to the directory.
• Windows 10/11 Pro, Enterprise, or Education with the BitLocker PowerShell module (built in).
• Microsoft.Graph PowerShell SDK v2.x for the tenant-wide key audit, with an account holding BitLockerKey.Read.All.

The Problem

BitLocker encryption and BitLocker recovery are two separate events, and the gap between them is where keys go missing. A drive can be fully, correctly encrypted while its recovery password sits only on the local volume and nowhere else. The encryption is doing its job — the disk is unreadable if pulled — but the escrow half never happened, and escrow is the half you rely on when a user forgets a PIN, a TPM resets after a firmware update, or hardware changes trip a recovery event.

The usual causes are mundane and they all share a timing problem. The device encrypted itself before the Intune disk encryption policy landed, so no escrow setting was in force. Or the machine was Entra registered (a personal or workplace-join state) rather than Entra joined, and only joined or hybrid-joined devices write their recovery password to the directory. Or someone ran manage-bde by hand during imaging and skipped the backup step. Or the escrow attempt genuinely failed — a network blip during enablement — and the "store recovery information before enabling" setting was left permissive, so BitLocker shrugged and carried on. The result is identical in every case: an encrypted device whose recovery key is not in Entra ID, and no error anywhere that told you at the time.

The Solution

Step 1 — Confirm the key really is missing and find the protector ID

Before touching anything, check both ends. In the Microsoft Intune admin center open Devices → Windows, select the device, and open Recovery keys; the Entra admin center shows the same data under the device's BitLocker keys blade. If either lists a recovery key ID that matches the one on the recovery screen, the key is escrowed and your problem is access rights, not a missing key. If both are empty, the key genuinely never made it up.

The problem in one screen: the device's Recovery keys blade in Intune with no BitLocker key — the drive is encrypted, but nothing was ever escrowed to Entra ID.

On the device itself, list the key protectors. The one that matters for recovery is the RecoveryPassword protector, and you need its ID to escrow it:

# Run elevated on the affected device
manage-bde -protectors -get C:

# Or the PowerShell-native view
(Get-BitLockerVolume -MountPoint C:).KeyProtector |
    Where-Object KeyProtectorType -eq 'RecoveryPassword' |
    Select-Object KeyProtectorId, RecoveryPassword

The protector list from manage-bde: the Numerical Password protector and the ID you hand to BackupToAAD-BitLockerKeyProtector to escrow it.

If there is no RecoveryPassword protector at all, the drive was encrypted with only a TPM protector, and there is no numerical recovery key to escrow — you have to add one first with Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector, then escrow that. That is worth knowing before you promise anyone their device is recoverable.

Step 2 — Escrow the existing key to Entra ID retroactively

This is the fix people are usually looking for: the drive is already encrypted, you do not want to decrypt and re-encrypt it, you just want the key that already exists to land in Entra ID. The BackupToAAD-BitLockerKeyProtector cmdlet does exactly that, using the protector ID from Step 1:

$kp = (Get-BitLockerVolume -MountPoint C:).KeyProtector |
    Where-Object KeyProtectorType -eq 'RecoveryPassword'

BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $kp.KeyProtectorId

Escrowing the existing recovery password to Entra ID retroactively — no re-encryption, just the protector ID from Step 1.

It succeeds silently and the key appears on the device's BitLocker keys blade in Entra within a minute or two. The one hard requirement: the device has to be Entra joined or hybrid joined with an active MDM enrollment. On an Entra-registered device the cmdlet fails, because there is no device object in the directory to attach the key to — which is also the original reason the automatic escrow never happened.

Step 3 — Escrow to on-premises Active Directory for hybrid devices

If the fleet is hybrid and you escrow to AD DS as well as, or instead of, Entra ID, the on-premises equivalent writes the recovery password to the computer object's msFVE-RecoveryInformation attribute. Either the PowerShell cmdlet or the legacy manage-bde switch works:

# PowerShell
Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $kp.KeyProtectorId

# manage-bde equivalent
# manage-bde -protectors -adbackup C: -id "{your-protector-id}"

On a Microsoft Entra hybrid joined device a correctly configured policy backs the recovery password up to both directories, so in a healthy state either path returns the key. When you are cleaning up after the fact, pick the directory your recovery process actually reads from and escrow there first.

Step 4 — Fix it at scale with an Intune remediation

One device is a manual job; a few hundred is not. Intune Remediations (formerly Proactive Remediations) run a detection script on a schedule and a remediation script only where detection reports a problem — the right shape for "find devices whose key is not escrowed and escrow it." The detection script checks for a RecoveryPassword protector and exits non-zero when one exists to be backed up; the remediation script escrows it:

# Remediation script — escrow every RecoveryPassword protector to Entra ID
$vol = Get-BitLockerVolume -MountPoint $env:SystemDrive
foreach ($kp in $vol.KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword') {
    try {
        BackupToAAD-BitLockerKeyProtector -MountPoint $env:SystemDrive -KeyProtectorId $kp.KeyProtectorId
        Write-Output "Escrowed $($kp.KeyProtectorId)"
    } catch {
        Write-Error "Failed to escrow $($kp.KeyProtectorId): $($_.Exception.Message)"
        exit 1
    }
}
exit 0

Run it in the system context. Note the licensing caveat honestly: Remediations needs a Windows Enterprise E3/E5 (or Education/Windows 365) entitlement. If you do not have that, the same script deployed as a plain Win32 or platform script does the escrow — you just lose the built-in reporting on which devices succeeded. This is the same reactive-cleanup pattern I use for other drifted settings, and it pairs naturally with the compliance signals in Intune compliance policies for Conditional Access.

Step 5 — Audit the whole tenant with Microsoft Graph

To know which devices are exposed before they hit a recovery prompt, query the keys Entra actually holds and compare against your device inventory. The bitlocker/recoveryKeys endpoint lists every escrowed key with the device it belongs to. It deliberately does not return the key material in the list call — reading the actual key is a separate, audited action:

Connect-MgGraph -Scopes "BitLockerKey.Read.All","Device.Read.All"

# List escrowed keys (device IDs and key IDs, not the keys themselves)
$keys = Get-MgInformationProtectionBitlockerRecoveryKey -All
$keys | Select-Object Id, DeviceId, CreatedDateTime | Format-Table

# Devices that have NO escrowed key = your exposure list
$withKeys = $keys.DeviceId | Sort-Object -Unique
Get-MgDevice -All -Filter "operatingSystem eq 'Windows'" |
    Where-Object { $_.DeviceId -notin $withKeys } |
    Select-Object DisplayName, DeviceId

The tenant-wide audit: escrowed key IDs and the device IDs they belong to, without exposing the key material itself.

Retrieving the actual recovery key adds $select=key to the single-key call (or the -Property Key equivalent in the SDK), and doing so writes a "read BitLocker key" entry to the Entra audit log — the same accountability that applies to reading a LAPS password. Treat that read as the privileged action it is.

Frequently Asked Questions

Why does Intune say there is no BitLocker recovery key when the device is asking for one?

Because encryption and escrow are separate. The device has a recovery password stored locally — that is what the recovery screen validates against — but that password was never written to Entra ID. It usually means the drive encrypted before the escrow policy applied, or the device was Entra registered rather than joined when encryption ran. If you can still boot the device, escrow it now with BackupToAAD-BitLockerKeyProtector.

Can I back up a BitLocker key to Entra ID without decrypting the drive?

Yes. BackupToAAD-BitLockerKeyProtector escrows the existing recovery password to Entra ID without touching the encryption itself. There is no need to decrypt and re-encrypt — you are only copying a key that already exists up to the directory.

Why does BackupToAAD-BitLockerKeyProtector fail on some devices?

The most common reason is that the device is Entra registered, not Entra joined or hybrid joined. The cmdlet needs a device object in Entra ID to attach the key to, and a registered device does not have one. Confirm the join type with dsregcmd /status — you want AzureAdJoined: YES or a hybrid state, not WorkplaceJoined only.

How do I find every device that is missing a BitLocker key in Entra ID?

Query the bitlocker/recoveryKeys Graph endpoint for the list of escrowed keys and their device IDs, then compare that against your Windows device inventory. Any device not represented in the key list has nothing escrowed. The Graph query in Step 5 does exactly this and returns the exposure list.

Does reading a BitLocker recovery key get logged?

Yes. Retrieving the actual key — whether from the Intune or Entra admin center, or via Graph with $select=key — writes an entry to the Entra audit log identifying who read which device's key and when. Listing key IDs does not expose the key and is not treated as a key read.

Conclusion

A missing BitLocker recovery key is only a crisis if you find out about it at the recovery screen. On any device you can still boot, escrowing the existing key retroactively is a two-line job, and a remediation script turns that into a fleet-wide sweep. The Graph audit in Step 5 is the part worth doing proactively — it converts "we think keys are backed up" into a list of the specific devices where they are not.

The honest caveat is that none of this conjures a key that was never saved. If a drive encrypted with only a TPM protector, was never joined, and the machine is now dead, the data is gone. That is why the real fix lives upstream: require recovery-key escrow before encryption is allowed to finish, so the missing-key state can never occur in the first place. The cleanup here is for the devices that predate that policy — everything after it should escrow on its own.

Related Posts

• Managing BitLocker Encryption with Microsoft Intune — the deployment post that prevents the missing-key state by requiring escrow before enabling.
• Managing Windows LAPS with Microsoft Intune — the other privileged local secret Intune escrows and audits the same way.
• Intune Compliance Policies for Conditional Access — feed encryption state into access decisions once every device is escrowed.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.