Checklist
BitLocker recovery key escrow checklist
Based on the article: BitLocker recovery key not in Microsoft Entra ID (event 846): escrow failures and fixes · 6 min read
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 to confirm
- 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: 0x80072f8fThe error line differs from device to device; the example above is the form admins commonly report.
BitLocker Drive Encryption recovery information for volume C: was backed up successfully to your Azure AD.Likely causes
Windows' own BitLocker components do the upload, not the Intune agent.
| Cause | How to recognise it |
|---|---|
| Device isn't Microsoft Entra joined or hybrid joined (only registered, or hybrid join hadn't finished when encryption ran) | dsregcmd /status shows AzureAdJoined : NO; 846 events around the encryption time |
| Drive encrypted before the device was joined or managed (imaging, a previous encryption tool, device encryption under a personal Microsoft account) | No 845 event for the current recovery password; the key lives wherever the old process stored it |
| Policy doesn't require the backup first | Encryption completed even though 846 was logged |
| Proxy, firewall or TLS inspection interfering with the upload | 846 with connection or security codes such as 0x80072f8f or 0x80072efe (reported by admins) |
| Windows 10 version 1809 without its fix: Microsoft documents that the signed-in user couldn't read the private key of the certificate created at enrollment | 846, 778 and 851 with 0x80072f9a; Microsoft's fix is a cumulative update for that release |
| The device object already holds 200 keys, the documented maximum | 846 on a device whose key has been rotated many times |
| The device object was deleted and recreated | Keys were stored on the old object and went with it |
Checklist
- 1
Confirm the key really is missing
On the device, in an elevated prompt, note the ID of the Numerical Password protector:
cmdmanage-bde -protectors -get C: - 2
Check the join state
cmddsregcmd /statusYou want
AzureAdJoined : YES(Microsoft Entra joined), orDomainJoined : YEStogether withAzureAdJoined : YES(hybrid joined). A device that only showsWorkplaceJoined : YESis Microsoft Entra registered, which doesn't meet Microsoft's documented prerequisite; join it properly rather than patching the key. - 3
Read the backup events
powershellGet-WinEvent -LogName 'Microsoft-Windows-BitLocker/BitLocker Management' | Where-Object Id -in 845, 846, 778, 851 | Select-Object -First 20 TimeCreated, Id, Message | Format-ListEvent 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. - 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
- 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:
See the full script in the source article.
Verify
- 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, VolumeTypeGood looks like a key whose Id matches the protector ID on the device, created around the time of your fix.
Prevent it next time
If devices aren't encrypting at all, start with BitLocker silent encryption not starting.
- 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.