BitLocker recovery key not in Microsoft Entra ID (event 846): escrow failures and fixes

A device reports as encrypted, yet its recovery keys page in the Microsoft Intune admin center is empty, which tends to surface when someone is already at the BitLocker recovery screen. Windows only escrows the recovery password to Microsoft Entra ID when the device is joined, the policy asks for it and the upload succeeds. In this post I'll show where escrowed keys should appear, how to read the events that record each backup attempt, and how to re-escrow keys on devices that missed out.

Symptoms#

• In the Intune admin center, Devices › All devices › the device › Monitor › Recovery keys shows No BitLocker key found for this device.
• The key ID on the recovery screen doesn't match any key listed for the device in Intune or on its device object in the Microsoft Entra admin center.
• manage-bde -status C: reports Protection On, so encryption itself worked.
• The log Applications and Services Logs › Microsoft › Windows › BitLocker-API › Management contains event 846, for example:

Event ID 846
Failed to backup BitLocker Drive Encryption recovery information for volume C: to your Azure AD.
TraceId: {...}
Error: Unknown HResult Error code: 0x80072f8f

The error line differs from device to device; the example above is the form admins commonly report. Microsoft's documented example of the same event reads Failed to backup BitLocker Drive Encryption recovery information for volume C: to your Microsoft Entra ID. with Error: Unknown HResult Error code: 0x80072f9a, followed by event 778, The BitLocker volume C: was reverted to an unprotected state., and event 851 (silent encryption failed). A healthy device logs event 845 instead:

BitLocker Drive Encryption recovery information for volume C: was backed up successfully to your Azure AD.

Devices commonly log "Azure AD" in these messages, while Microsoft's documentation now prints "Microsoft Entra ID", so search event text for both; the target is Microsoft Entra ID either way.

Why it happens#

Windows' own BitLocker components do the upload, not the Intune agent. With silent encryption the backup happens before encryption starts, so a problem at that moment leaves an unencrypted device, or an encrypted one without an escrowed key:

How to fix it#

1. Confirm the key really is missing#

On the device, in an elevated prompt, note the ID of the Numerical Password protector:

manage-bde -protectors -get C:

In Intune, open the device's Recovery keys page and select Show Recovery Key (the access is audited). If a key with that ID is listed, escrow worked and the problem is access: reading keys needs the microsoft.directory/bitlockerKeys/key/read permission, which roles such as Cloud Device Administrator and Helpdesk Administrator include.

2. Check the join state#

dsregcmd /status

You want AzureAdJoined : YES (Microsoft Entra joined), or DomainJoined : YES together with AzureAdJoined : YES (hybrid joined). A device that only shows WorkplaceJoined : YES is Microsoft Entra registered, which doesn't meet Microsoft's documented prerequisite; join it properly rather than patching the key. For hybrid devices, wait until the hybrid join has completed.

3. Read the backup events#

Get-WinEvent -LogName 'Microsoft-Windows-BitLocker/BitLocker Management' |
    Where-Object Id -in 845, 846, 778, 851 |
    Select-Object -First 20 TimeCreated, Id, Message |
    Format-List

Event 778 after 846 means BitLocker reverted the volume to unprotected because the backup failed, the safe outcome; 851 means silent encryption itself failed. Translate the code in event 846 with certutil -error 0x80072f8f. Connection and security errors point at the network path to Microsoft Entra ID: check proxy, firewall and TLS inspection rules.

4. Fix the policy#

For an Endpoint protection template (Windows Encryption), Microsoft documents these settings as the basis for escrow and key rotation:

• Save BitLocker recovery information to Microsoft Entra ID = Enabled
• Store recovery information in Microsoft Entra ID before enabling BitLocker = Required
• Client-driven recovery password rotation = Enable rotation on Microsoft Entra joined devices, or on Microsoft Entra ID and hybrid joined devices

In an Endpoint security › Disk encryption BitLocker profile, configure the matching operating system drive recovery options and Configure Recovery Password Rotation. Give each device a single BitLocker profile so settings can't conflict.

5. Re-escrow the existing key#

Once the device is joined and can reach Microsoft Entra ID, upload the existing recovery password; there's no need to decrypt. Run this elevated, or deploy it as an Intune platform script or Remediation:

$mount = $env:SystemDrive
$recovery = (Get-BitLockerVolume -MountPoint $mount).KeyProtector |
    Where-Object KeyProtectorType -eq 'RecoveryPassword'
if (-not $recovery) {
    # TPM-only volume: add a recovery password protector first
    Add-BitLockerKeyProtector -MountPoint $mount -RecoveryPasswordProtector | Out-Null
    $recovery = (Get-BitLockerVolume -MountPoint $mount).KeyProtector |
        Where-Object KeyProtectorType -eq 'RecoveryPassword'
}
foreach ($kp in $recovery) {
    BackupToAAD-BitLockerKeyProtector -MountPoint $mount -KeyProtectorId $kp.KeyProtectorId
    Write-Output "Backup requested for $($kp.KeyProtectorId)"
}

Don't trust the script's exit code alone; verify as shown below. Per device, the BitLocker key rotation remote action (under ... if it isn't visible) is an alternative: it creates and escrows a new recovery password, but only with the step 4 settings in place on Windows 10 version 1909 or later, or Windows 11. Hybrid devices that also need a copy in Active Directory can use Backup-BitLockerKeyProtector with the same parameters.

Verify the fix#

• The BitLocker-API › Management log shows a new event 845 for the volume.
• Intune's Recovery keys page lists a key whose ID matches the Numerical Password protector from manage-bde -protectors -get C:.
• To check without the portal, or across many devices, query Microsoft Graph with an account allowed to read BitLocker key metadata:

Connect-MgGraph -Scopes 'BitlockerKey.ReadBasic.All'
# deviceId = the Microsoft Entra device ID ("DeviceId" in dsregcmd /status)
Get-MgInformationProtectionBitlockerRecoveryKey -Filter "deviceId eq '<device-id>'" |
    Select-Object Id, CreatedDateTime, VolumeType

Good looks like a key whose Id matches the protector ID on the device, created around the time of your fix. Each reveal of a key is logged in the Microsoft Entra audit log as Read BitLocker key.

Prevent it next time#

• Keep Store recovery information in Microsoft Entra ID before enabling BitLocker on Required, so a failed upload stops encryption instead of creating an unrecoverable device.
• Check refurbished or re-imaged devices for existing encryption, including third-party tools, before enrolling them.
• Use the encryption report (Devices › Monitor › Encryption report) and a Remediation that flags devices whose latest backup event is 846 rather than 845.
• Don't delete Intune or Entra objects of devices still in use: deleting the Intune object of a Microsoft Entra joined device removes the OS volume's key protectors and leaves BitLocker suspended.
• Enable client-driven rotation so a recovery password that has been used is replaced and the new one escrowed.

If devices aren't encrypting at all, start with BitLocker silent encryption not starting. For keys managed by Configuration Manager, see BitLocker management in Configuration Manager.

References#

• Encrypt Windows devices with BitLocker using Intune (Microsoft Learn)
• BackupToAAD-BitLockerKeyProtector (Microsoft Learn)
• Enforcing BitLocker policies by using Intune: known issues (Microsoft Learn)