BitLocker Recovery Key Not Backed Up to Entra ID: Why and How to Fix It

Separate encryption from recoverability

Use this guide when a Windows device is encrypted but the current recovery password protector cannot be found in Microsoft Entra ID. Encryption status, a successful policy assignment, and an old local backup event answer different questions. None alone establishes that a usable recovery key is available for the current volume.

If the device is already at the recovery screen, record its recovery key ID and use your authorised recovery process first. Commands inside Windows require a running, unlocked operating system. Do not wipe, decrypt or clear the TPM to diagnose a missing backup.

Scope and assumptions

This is documentation-reviewed guidance for supported Windows devices that are Microsoft Entra joined or hybrid joined. The Intune policy checks apply to Intune-managed devices; the Windows backup cmdlet is not described as an MDM-only transport. Active Directory, Configuration Manager and MBAM recovery stores are separate destinations and must be checked through their own authorised tools when used in your environment.

Use elevated Windows PowerShell with the BitLocker module for device commands. For cloud metadata, use an approved Microsoft Graph PowerShell installation, consented delegated permissions and a supported Entra role or device-owner access. Examples have not been executed as part of this review. Never capture recovery passwords in transcripts, screenshots or tickets.

Step 1: Match identity and protector before changing anything

Run dsregcmd /status locally and record DeviceId and TenantId. AzureAdJoined: YES identifies Entra join; DomainJoined: YES as well identifies hybrid join. Match that device ID to the cloud object instead of choosing the newest object with a similar name. Rebuilds can leave duplicate names. See Microsoft's join-state diagnostic fields.

Inspect the OS volume without printing the recovery password:

$volume = Get-BitLockerVolume -MountPoint $env:SystemDrive -ErrorAction Stop
$volume | Select-Object MountPoint, VolumeStatus, ProtectionStatus, EncryptionPercentage
$volume.KeyProtector | Select-Object KeyProtectorId, KeyProtectorType

Record the RecoveryPassword protector IDs. There may be more than one. If none exists, stop: adding a protector is a separate security change that needs an approved recovery design. Other protector types do not mean that the volume has no recovery mechanism, but they cannot be backed up by the recovery-password cmdlet below.

Step 2: Verify cloud metadata with the right permissions

In the Entra admin centre, open the device with the matching DeviceId and inspect Recovery keys. Match the key ID to the current protector, not just a creation date. A key attached to an old device record does not establish recoverability of the current installation.

The optional Graph example lists metadata without retrieving the 48-digit secret. BitlockerKey.ReadBasic.All is a read permission, not an escrow-write permission to add to the Intune service principal. Delegated access also requires a supported role or ownership; see Microsoft's recovery-key listing permissions.

Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes 'BitlockerKey.ReadBasic.All' -ContextScope Process
try {
    # Replace with the DeviceId read from this endpoint, not its display name.
    $deviceId = [guid]'11111111-1111-1111-1111-111111111111'
    Get-MgInformationProtectionBitlockerRecoveryKey `
        -Filter "deviceId eq '$deviceId'" -All -ErrorAction Stop |
        Select-Object Id, DeviceId, CreatedDateTime, VolumeType
} finally { Disconnect-MgGraph | Out-Null }

An access error is not evidence that there are no keys. Confirm the account, tenant and role before acting on an empty result. Retrieving secret key material requires a different privilege and an audited recovery workflow; it is deliberately absent from this diagnostic example.

Step 3: Check policy ownership and delivery

Review the affected device's per-setting status under Endpoint security > Disk encryption, alongside its effective Group Policy where applicable. Record which service owns encryption, backup and rotation settings. Resolve actual conflicting settings on a pilot; do not remove all BitLocker GPOs or uninstall an existing recovery agent as a blanket fix.

Microsoft's Intune BitLocker configuration guide documents the relevant recovery settings and silent-encryption prerequisites. Check the help text for the profile type in use: backup-before-encryption and recovery-password rotation are distinct controls. A sync requests policy processing; it is not itself key rotation or proof of backup.

Keep existing recoverable keys available while evaluating changes. An Active Directory backup is not an Entra backup, but the presence of one does not prove the other was intercepted or prevented. MBAM does not have a universal “forward to Entra” switch described by this guide.

Step 4: Back up existing recovery-password protectors on one approved device

This operation writes recovery material to Entra. Use it only after confirming identity, policy intent and permission to back up this device. It neither decrypts the disk nor deliberately replaces its current protectors. Save only IDs and error details in the change record.

$drive = $env:SystemDrive
$protectors = @((Get-BitLockerVolume -MountPoint $drive -ErrorAction Stop).KeyProtector |
    Where-Object KeyProtectorType -eq 'RecoveryPassword')
if ($protectors.Count -eq 0) {
    throw 'No recovery-password protector: stop and review the recovery design.'
}
foreach ($protector in $protectors) {
    BackupToAAD-BitLockerKeyProtector -MountPoint $drive `
        -KeyProtectorId $protector.KeyProtectorId -ErrorAction Stop | Out-Null
    Write-Output "Backup requested for protector ID $($protector.KeyProtectorId); verify in Entra."
}

The documented backup cmdlet accepts one protector ID per call. Errors must be preserved; completion is followed by a fresh cloud check. If the cmdlet is unavailable, inspect the supported OS, shell and BitLocker module. BackupRecoveryInformationToActiveDirectory targets on-premises AD and is not a substitute for Entra escrow.

Validate success and investigate failures

Repeat the cloud metadata check and match each current protector ID. Allow for service processing, but record the observation time and escalate persistent absence rather than assuming a fixed delay guarantees success. A local event can help explain an attempted backup, but log retention, old protectors and deleted cloud objects make it unsuitable as the sole detection rule.

For event investigation, keep the log name inside the filter hashtable; do not combine incompatible -LogName and -FilterHashtable parameter sets:

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-BitLocker/BitLocker Management'
    StartTime = (Get-Date).AddHours(-2)
} -ErrorAction Stop | Select-Object TimeCreated, Id, LevelDisplayName, Message

Use the actual event message and timestamp alongside MDM diagnostic events. No events in the interval is different from inability to read the log. Redact device identifiers before sharing diagnostics outside your support boundary.

If backup fails, retain the error and check join health, connectivity and policy status. Do not delete the device object, remove protectors or re-encrypt as a first response. A fleet remediation needs a separately reviewed detection design that reconciles current protector IDs against cloud records; this page does not provide a complete deployable remediation package.

Recovery and rotation after use

Keep the existing protector until a replacement is confirmed backed up through your approved rotation process. Use the Intune BitLocker key rotation action only on eligible devices with the required policy and RBAC permissions. A normal device sync is not that action. Validate the new protector and cloud record after rotation; never undo a backup by deleting the only available recovery information.

Test it in a home lab (encrypt, escrow, one controlled miss)

Use a personal lab VM with a virtual TPM, not a work laptop.

Success on this lab test is two records: a recovery-password protector ID that matches Entra, and one induced miss you can explain.

1. Entra-join the VM first. Encrypting before join is a valid miss to capture, not the success path.
2. Enable BitLocker on the OS volume with a recovery password protector. Do not print the 48-digit password into a transcript.
3. Run Get-BitLockerVolume and record MountPoint, ProtectionStatus, and KeyProtectorId values only.
4. Confirm the same protector ID under the matching Entra device Recovery keys pane. Match DeviceId from dsregcmd /status, not the newest similar name.
5. Induce one miss on a second snapshot or after a controlled policy pause: encrypt with backup disabled, or backup after disconnecting the VM from the network, then capture the error from BackupToAAD-BitLockerKeyProtector.
6. Restore policy and connectivity. Confirm the protector ID is present in Entra before you treat the VM as recoverable.

Related resources

• Secure Boot certificate readiness explains why recovery preparation belongs before firmware work.
• Intune compliance evaluation separates policy reporting from device state.
• Windows LAPS pilot and recovery checks covers a different recovery secret and its permissions.

Correction record

19 September 2026: Added a one-device home-lab test for escrow success and one controlled miss.

10 September 2026 — Reviewed against documentation. Corrected escrow versus rotation, Graph permissions and identity matching; removed unsupported event-only detection, AD fallback, MBAM claims and automatic fleet repair.