Helpdesk has a locked laptop and a recovery prompt. You open Intune admin center > Devices > [device] > Recovery keys (or Entra admin center > Devices > [device] > BitLocker keys) and the blade is empty. The disk is clearly encrypted. Someone already ran a sync. Someone else wants to suspend BitLocker and "start over."
Missing recovery keys are usually an escrow problem, not an encryption problem. The volume can be protected locally while the numerical password protector never reached Entra ID (or reached a different device object). This post is a read-first order for that ticket. Every step only reads until you decide a change is justified.
TL;DR
- Confirm where your tenant is supposed to store keys: Intune/Entra for cloud-joined devices, or Active Directory for classic domain GPO escrow. Looking in the wrong directory is the most common false miss.
- On the device: does
manage-bde -protectors -get C:show a Numerical Password protector at all? No protector means nothing to upload. - Read Event Viewer channels for BitLocker / MDM escrow failures before you rotate protectors.
- Match the device object:
dsregcmdDeviceId vs the portal device you opened. Duplicate or stale objects hide keys that already escrowed elsewhere. - Do not delete protectors or decrypt until BitLocker recovery material you can reach is documented, and prefer a controlled key rotation only after escrow path is healthy.
What "key missing" usually means
Three different tickets share the same empty blade:
| What the admin sees | What it often is | First read |
|---|---|---|
| Encrypted volume, empty Intune/Entra key blade | Never escrowed, wrong backup target, or wrong device object |
manage-bde protectors + device ID match |
| Key present in AD, empty in Entra | Domain GPO escrow only; cloud policy never configured | Where escrow was designed to land |
| Key was there last month, gone now | Looking at a re-enrolled duplicate device, or key rotated and UI lag | Device Created / Enrollment dates; search by key ID if known |
| Compliance says BitLocker OK, recovery blade empty | Compliance can pass on encryption state without proving cloud escrow | Separate escrow events from compliance setting status |
This is adjacent to, but not the same as, BitLocker still encrypting / grace periods. That article is about compliance timing. This one is about whether the recovery material ever landed in the cloud.
Step 1: Confirm the escrow design for this device
Ask one design question before you touch the laptop:
| Join / management path | Typical recovery store | Where you look first |
|---|---|---|
| Entra joined + Intune | Entra ID / Intune recovery keys blade | Entra or Intune device BitLocker keys |
| Hybrid joined + Intune disk encryption / BitLocker profile | Often Entra ID (if cloud escrow is configured) | Entra/Intune first; AD only if GPO still owns escrow |
| Domain joined, GPO BitLocker only, no Intune encryption policy | Active Directory computer object | AD Users and Computers / BitLocker recovery password attribute |
| Personal / Workplace joined only | Usually no org escrow | Local protectors only — do not expect Entra keys |
If the device is hybrid and your BitLocker baseline is still a domain GPO that stores keys in AD, an empty Entra blade is expected. Fix the runbook (or migrate escrow), not the empty cloud UI.
In Intune, open the endpoint security / BitLocker / disk encryption policy that should apply and note:
- Is Store recovery information in Entra ID / Azure AD (wording varies) enabled?
- Is the profile assigned to a group that actually includes this device?
- Is there a conflict with an older GPO that also manages BitLocker?
Step 2: On the device — protectors and encryption state
On the locked-out machine you may only have WinRE. If you have a signed-in admin session or another admin path, run:
manage-bde -status C:
manage-bde -protectors -get C:
What you need from the protector list:
| Protector | Why it matters |
|---|---|
| Numerical Password | This is the 48-digit recovery password that Entra/Intune is supposed to hold |
| TPM / TPM+PIN / startup key | Unlock methods; they do not replace cloud escrow of the numerical password |
| External key (.bek) | Offline recovery material; still not a substitute for org escrow |
If there is no Numerical Password protector, cloud escrow cannot invent one. Encryption may still show as on (TPM-only protector). That is a policy gap: your Intune/GPO baseline should require a numerical password protector and escrow.
Also capture:
$dsreg = dsregcmd /status
$dsreg | Select-String 'AzureAdJoined|DomainJoined|WorkplaceJoined|DeviceId|TenantId|MDMUrl'
Copy DeviceId. You will compare it to the portal object in step 4.
Step 3: Event Viewer — did escrow even try?
On a working admin session (or after unlock with a known key from another store), open:
Event Viewer > Applications and Services Logs > Microsoft > Windows > BitLocker-API > Management
and, when present:
Microsoft > Windows > BitLocker-DrivePreparationService / related MDM / DeviceManagement-Enterprise-Diagnostics-Provider channels for policy application.
Useful themes (IDs and wording vary by build):
| Theme | Meaning | Next read |
|---|---|---|
| Recovery password backed up / escrowed to Azure AD | Client believes upload succeeded | Wrong portal device object, or UI delay |
| Backup failed / access denied / directory | Cloud write failed | Join state, network to login.microsoftonline.com, policy |
| Policy applied but protector missing | Profile settings did not create numerical password | BitLocker policy require-recovery-password setting |
| No BitLocker events after enrollment | Policy never reached the device | Assignment, sync, filters (Company Portal / sync triage) |
Do not treat a green BitLocker compliance row as proof of escrow. Compliance often checks protection status; escrow is a separate backup action.
Step 4: Match the portal device object
In Entra admin center > Devices (and the Intune device twin), search by:
- Device name (unreliable if renamed)
-
Device ID from
dsregcmd - Approximate enrollment / join time
| Portal finding | Likely meaning |
|---|---|
| One object, DeviceId matches, keys empty | Escrow never succeeded — stay on event + policy path |
| Two objects for the same laptop | Key may sit on the other object (old Autopilot / re-enroll) |
| DeviceId matches a deleted/restored object history | Re-enrollment broke the link helpdesk is using |
| Hybrid: AD has the key, Entra does not | GPO escrow only — use AD recovery, or enable cloud escrow going forward |
For Autopilot fleets, reimaging without a clean device-object story is a frequent cause of "we had a key last quarter." Search by hardware / Autopilot serial if your process keeps that map.
Step 5: When a controlled change is justified
Only after the reads above:
| Situation | Prefer | Avoid |
|---|---|---|
| Numerical password exists locally, escrow events failing | Fix join/network/policy, then trigger a supported key backup / rotation | Deleting the only numerical protector you have |
| No numerical password protector | Apply policy that requires recovery password + escrow; verify events | Decrypting the whole disk "to start clean" on a production laptop |
| Key in AD, empty Entra, GPO design | Recover from AD; schedule cloud-escrow migration | Telling helpdesk Entra is broken |
| Duplicate Entra objects | Recover from the object that has the key; retire the stale twin per offboarding hygiene | Wiping both objects blindly |
If you must rotate protectors so a new numerical password is generated and escrowed, treat it as a change: confirm you can unlock today, document the old key ID if known, then use the supported Intune/BitLocker rotation path your tenant standardized on. Prefer verifying a successful escrow event before you close the ticket.
FAQ
Is the recovery key in Intune or in Entra?
For cloud escrow, Intune and Entra are showing the same Entra-backed BitLocker recovery information on the device object. If one blade is empty, the other usually is too — unless you opened different device objects.
Can compliance be green with no recoverable key in the portal?
Yes. Protection status and escrow success are related but not identical. Always confirm a Numerical Password protector and an escrow event (or a visible portal key).
Hybrid joined — why did AD have the key but Entra did not?
Classic BitLocker GPOs escrow to Active Directory. Intune/Entra escrow is a separate setting. Many hybrid tenants still run the GPO path until someone migrates it.
Will Sync in Company Portal upload the key?
Sync can help the device pull policy and retry escrow. It does not create a numerical password protector by itself, and it will not move a key from an old duplicate device object onto the one you are viewing.
What if the laptop is already at the BitLocker recovery screen and the portal is empty?
Check AD (if hybrid/domain), any printed/USB escrow from imaging, and other device objects for the same serial. If no org copy exists, you are in a data-recovery / rebuild decision — not a "click Sync harder" situation.
Related posts
- BitLocker still encrypting: why Intune marks you noncompliant and how grace periods save Monday
- Company Portal can't connect / device not syncing: a 10-minute triage order for Intune admins
- Compliance before Conditional Access: an Intune enrollment + compliance runway that won't lock out Outlook
- An offboarding checklist for M365 / Intune admins: disable vs delete, license reclaim, and the device decision
Free checklist
BitLocker escrow belongs next to compliance and Conditional Access in every enrollment runway. If you are about to require compliant devices, the free Conditional Access pre-enforcement checklist keeps pilot groups, report-only review, and device readiness on one page before you enforce:
If you collect enrollment and device hygiene notes for the team, the Intune & M365 Admin Starter Pack includes enrollment hygiene and break/fix cards that pair with BitLocker escrow checks: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=bitlocker-recovery-key-missing
Admin Pack Studio; not affiliated with Microsoft. The commands above only read. Test BitLocker protector and escrow policy changes in a pilot group first. Never paste full recovery passwords into tickets, chat, or screenshots.
Top comments (0)