Finding a BitLocker Recovery Key in Entra ID (Azure AD) — Every Place to Look

If you support Windows endpoints at any scale, you have already had this ticket: a user reboots, hits the blue BitLocker recovery screen, reads you an eight-digit key ID, and asks for the 48-digit recovery password. You open the Entra (Azure AD) portal and the recovery key is not where you expect it to be. This post walks through every place the key can actually live and a PowerShell script to query them all at once.

The four possible locations

A BitLocker recovery key for an enrolled Windows device can be escrowed to one (or several) of:

1. Entra ID device object — for cloud-native Entra-joined devices
2. On-prem Active Directory computer object — for hybrid-joined devices with the legacy GPO set
3. MBAM / Microsoft BitLocker Administration and Monitoring — if you still run it on Configuration Manager
4. The user's BitLocker keys tab in their Entra profile — only populated when the user who enabled encryption is signed in at escrow time

Most "missing key" tickets are actually a mismatch between where the admin is looking and where Windows wrote the key.

Path 1: Entra admin center (the obvious one)

In the Microsoft Entra admin center:

Devices > All devices > [select device] > BitLocker keys

Or from the user side:

Users > [select user] > Devices > BitLocker keys

If the device is Entra-joined (not hybrid) and Intune escrow is configured, the key will be here. If the tab is empty, do not assume the key was never escrowed — check the join type first.

From an elevated PowerShell on the device:

dsregcmd /status | Select-String -Pattern "AzureAdJoined|DomainJoined|EnterpriseJoined"

• AzureAdJoined: YES + DomainJoined: NO = cloud-native, key should be in Entra
• AzureAdJoined: YES + DomainJoined: YES = hybrid, key probably went to on-prem AD

Path 2: On-prem Active Directory (the silent default for hybrid)

Open Active Directory Users and Computers, enable Advanced Features in the View menu, find the computer object, right-click, and look for the BitLocker Recovery tab. The keys are stored as msFVE-RecoveryInformation child objects.

From PowerShell:

Get-ADObject -Filter {objectClass -eq 'msFVE-RecoveryInformation'} `
  -SearchBase "CN=DESKTOP-ABC123,OU=Workstations,DC=corp,DC=local" `
  -Properties msFVE-RecoveryPassword `
  | Select-Object Name, msFVE-RecoveryPassword

The Name attribute starts with the key ID timestamp, so you can match it against the partial ID Windows shows on the recovery screen.

Path 3: Query both sources at once

This is what I actually run when a ticket comes in and I do not yet know the join type. Replace $KeyId with the first 8 characters from the recovery screen:

param([string]$KeyId)

# Entra side via Microsoft Graph
Connect-MgGraph -Scopes "BitlockerKey.Read.All" -NoWelcome
$entra = Get-MgInformationProtectionBitlockerRecoveryKey -All |
  Where-Object { $_.Id -like "$KeyId*" }

if ($entra) {
  $key = Get-MgInformationProtectionBitlockerRecoveryKey `
    -BitlockerRecoveryKeyId $entra.Id -Property "key"
  Write-Host "Found in Entra: $($key.Key)" -ForegroundColor Green
  return
}

# On-prem fallback
$adKey = Get-ADObject -Filter "objectClass -eq 'msFVE-RecoveryInformation' -and Name -like '*$KeyId*'" `
  -Properties msFVE-RecoveryPassword

if ($adKey) {
  Write-Host "Found in on-prem AD: $($adKey.'msFVE-RecoveryPassword')" -ForegroundColor Yellow
} else {
  Write-Host "Not found in either store. Check MBAM or user profile." -ForegroundColor Red
}

The required Graph scope is BitlockerKey.Read.All — note this is sensitive and audited; assign it to a PIM-eligible role, not a standing admin.

Why the key is sometimes simply not there

Three cases I see weekly:

• Encryption ran before enrollment. Autopilot devices that finished OOBE on a flaky network can encrypt locally and never escrow. Fix by running BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId <guid> from PowerShell once connectivity is back.
• Standard user enabled encryption. Without "Allow standard users to enable encryption during Autopilot" set, the key escrow API call fails silently for non-admins.
• Hybrid-join with no AAD escrow policy. The Intune BitLocker baseline only writes to Entra if the device is Entra-joined; for hybrid-joined endpoints you need the GPO Choose how BitLocker-protected operating system drives can be recovered with Save BitLocker recovery information to AD DS enabled, or you get nothing in either place.

Full version

The full article on Help Desk Hero includes screenshots of each location, the exact Intune policy paths for Windows 11 24H2, a decision tree for which store to check first based on dsregcmd output, and timing benchmarks (Graph queries average ~1.2s, AD queries ~80ms over a healthy DC). If your shop is still on MBAM there is a sidebar on the SQL query to pull keys from the RecoveryAndHardwareCore_Keys table.