Escrowing BitLocker Recovery Keys via Intune and Entra ID
Learn how to configure Intune BitLocker key escrow to Entra ID correctly, avoid silent failures, and verify recovery keys before a device becomes unrecoverable.
Elliot WardIn this lesson
Table of Contents
Table of contents
Before you begin
- Intune configuration profile basics
- Entra ID hybrid join fundamentals
- PowerShell for Windows device administration
Track this tutorial
Choose your current status and tick each safety check as you complete it. Sign in to sync progress between devices.
Current status
Before you apply the change
Confirm these production-safety controls during the tutorial.
#Operational requirement
A laptop with an encrypted volume and no recovery key anywhere except the user’s own head is not a secured device. It is a support ticket waiting to happen, and on a bad day it is a data-loss incident. If BitLocker protector keys are not escrowed to Entra ID (or on-premises AD for hybrid-joined machines still running legacy Group Policy
You will typically get this assigned once you’ve proven you can enrol devices and push a compliance policy. The brief sounds simple: “make sure BitLocker keys are backed up properly.” It is not simple, because there are three places a key can end up (Entra ID device object, on-prem AD, or nowhere), two enrolment states that affect which one applies (Entra-joined vs hybrid-joined), and a legacy Group Policy object that half your estate might still be running from before the Intune migration. Getting the profile wrong doesn’t throw an obvious error. It silently encrypts the drive and silently fails to escrow the key, and you find out three months later when someone’s motherboard dies.
#Implementation
This walkthrough assumes Windows 10/11 devices already enrolled in Intune, either Entra-joined or Entra hybrid-joined, with encryption not yet enforced through Intune (silent BitLocker via OEM or manual GPO doesn’t count — you need Intune driving it end to end).
-
Confirm the device join type first. Escrow destination depends on it. Run on a test machine:
1dsregcmd /statusLook for
AzureAdJoinedorDomainJoinedplusAzureAdJoined(hybrid). Pure Entra-joined devices escrow to the Entra ID device object. Hybrid-joined devices escrow to on-prem AD by default unless you explicitly redirect to Entra ID — this is the single most common misconfiguration on estates migrating off ConfigMgr. -
Build the Endpoint Protection configuration profile. In the Intune admin centre: Devices > Configuration profiles > Create profile > Windows 10 and later > Templates > Endpoint protection. Under BitLocker settings, set:
1Encrypt devices: Enable 2Require storage card encryption (mobile only): Not configured 3OS drive - BitLocker system drive policy: Configure 4 Startup authentication required: Yes (TPM only unless you have a PIN requirement) 5 Require encryption for OS drive: Enable 6Fixed drive recovery: Configure 7 Save BitLocker recovery information to Azure AD: Enable 8 Store recovery information in Azure Active Directory before enabling BitLocker: Enable 9 Recovery key file creation: Block (unless you have an offline retrieval workflow) 10 Enable BitLocker after recovery information to AD: YesThe two lines that matter most are Save recovery information to Azure AD and Store recovery information before enabling BitLocker. The second one is what stops a race condition where the drive encrypts before the key has actually landed in Entra ID — without it, a device rebooted mid-provisioning can lock itself out with an unescrowed key.
-
Assign to a pilot group, not the whole estate. Use an Entra ID dynamic device group scoped to a small cohort:
1(device.deviceOSType -eq "Windows") and (device.displayName -startsWith "PILOT-")Roll this to production only after verification (below) passes on at least 20–30 devices across your hardware mix — different OEM firmware and TPM versions surface different escrow timing bugs.
-
For hybrid-joined devices, redirect explicitly. If your on-prem AD schema already has the BitLocker recovery attributes extended (most estates migrated from GPO-managed BitLocker will), you have a choice: keep escrowing there, or move to Entra ID and retire the old GPO. If moving, disable the legacy GPO first — do not run both simultaneously, because conflicting policy can put the client in an error state where MBAM/GPO settings and Intune CSP settings fight over the same registry keys under
HKLMSOFTWAREPoliciesMicrosoftFVE. -
Set the companion compliance policy. Under Devices > Compliance policies, add “Require BitLocker” as a system security check. This is what actually gates Conditional Access — the configuration profile enforces encryption, the compliance policy reports and enforces the consequence of non-compliance.
#Verification
Do not trust the Intune console alone; it reports policy application, not escrow success. Verify on three levels.
On the device, confirm the volume is protected and note the recovery ID:
1manage-bde -status C:
2Get-BitLockerVolume -MountPoint "C:" | Select-Object MountPoint, ProtectionStatus, KeyProtectorYou need a RecoveryPassword key protector present, with a GUID you can cross-check against Entra ID.
In Entra ID, go to Devices > [device name] > BitLocker keys in the admin centre, or query via Graph:
1GET https://graph.microsoft.com/v1.0/informationProtection/bitlocker/recoveryKeys?$filter=deviceId eq '{device-object-id}'Match the recovery key ID returned here against the GUID from manage-bde -status. If Graph returns an empty array for a device that shows encrypted locally, escrow failed silently — this is the exact failure mode the whole exercise exists to prevent.
At scale, script a weekly audit rather than checking devices individually:
1Connect-MgGraph -Scopes "Device.Read.All", "BitLockerKey.Read.All"
2Get-MgDevice -All | ForEach-Object {
3 $keys = Get-MgInformationProtectionBitlockerRecoveryKey -Filter "deviceId eq '$($_.Id)'"
4 [PSCustomObject]@{ Device = $_.DisplayName; KeyCount = $keys.Count }
5} | Where-Object { $_.KeyCount -eq 0 } | Export-Csv unescrowed-devices.csv -NoTypeInformationRun this against your full estate monthly, not just the pilot. Devices that drop off Wi-Fi mid-encryption or get re-imaged without re-enrolling reliably fall out of escrow, and nobody notices until a recovery is needed.
#Failure Modes and Common Traps
| Symptom | Likely cause | Fix |
|---|---|---|
| Device encrypted, no key in Entra ID or AD | “Store recovery information before enabling BitLocker” left disabled or not configured | Set to Enable in the profile, force a policy sync, then decrypt/re-encrypt the volume — existing keys won’t retroactively appear |
| Hybrid-joined device escrows to neither location | Device object hasn’t completed Entra Connect sync, or on-prem AD schema not extended for BitLocker attributes | Check sync status with dsregcmd /status, confirm schema extension with Get-ADObject against the msFVE-RecoveryInformation class |
| Conflicting policy error, encryption stalls | Legacy BitLocker GPO still linked alongside the new Intune CSP profile | Unlink or disable the old GPO for the target OU, run gpupdate /force, re-trigger the Intune sync |
| Compliance policy shows non-compliant despite encrypted drive | Compliance evaluation ran before escrow completed (timing gap, common on first sync after enrolment) | Wait one evaluation cycle (default 8 hours) or manually sync via Settings > Accounts > Access work or school > Info > Sync |
| Recovery key present locally but Graph query returns nothing | Device object ID mismatch — querying by Intune device ID instead of Entra ID object ID | Resolve the correct Entra object ID first via Get-MgDevice -Filter "displayName eq '{name}'" |
The GPO conflict is the one that catches out most junior engineers, because it doesn’t produce a clean error — it produces inconsistent behaviour that looks like flaky hardware. Check for competing policy sources before you assume the device itself is faulty.
#Rollback
If the profile causes unexpected encryption on devices not ready for it (shared kiosk machines, lab equipment, anything without a documented owner for recovery), do not simply delete the configuration profile — that leaves already-encrypted drives locked with no policy managing the key going forward.
- Remove the pilot device group assignment from the Endpoint Protection profile first, so no new devices pick it up.
- For devices already encrypted that need to be reverted, decrypt explicitly and deliberately:
1manage-bde -off C:then confirm with
manage-bde -status C:until it reports “Fully Decrypted”. - Only after decryption is confirmed, remove the profile assignment or delete the profile in Intune.
- If you disabled a legacy BitLocker GPO as part of the change and need to fall back to it, re-link it to the OU and run
gpupdate /force— but do this only after confirming no Intune CSP profile is still targeting the same device group, or you recreate the exact conflict from the failure table above. - Document the rollback in your change record with the device count affected and the recovery key IDs retired, in case an audit later asks why keys exist for drives no longer encrypted.
#Operational Summary
Key escrow is a policy setting, but the actual objective is a recovery path that works at 2am when someone’s laptop won’t boot. Confirm join type before you build anything, because it decides where the key lands. Enforce the “store before enable” ordering so encryption never gets ahead of escrow. Pilot on a small, hardware-diverse group before touching production, and build a recurring audit script rather than trusting the console dashboard — it tells you policy state, not escrow success. Retire legacy GPOs deliberately and never in parallel with the Intune profile. Handled properly, this becomes a policy nobody thinks about again; handled carelessly, it becomes the incident where a director’s device gets wiped because nobody could produce the recovery key.
#Learning Objectives
By the end of this exercise an engineer should be able to distinguish escrow destinations by join type, configure the Endpoint Protection profile fields that control escrow timing, and independently verify escrow success rather than relying on Intune's reported policy state. The objective is not just to enable BitLocker but to prove, with evidence pulled from both the client and Entra ID, that a recovery key actually exists somewhere retrievable before a device is allowed into production rings.
A secondary objective is recognising the failure signatures covered in the reference material quickly enough to distinguish a genuine escrow fault from unrelated hardware flakiness, particularly the GPO-conflict symptom that mimics faulty TPM behaviour.
- Identify join type (Entra-joined, hybrid-joined, on-prem only) before building any profile
- Explain why 'store before enable' ordering prevents unescrowed encryption
- Query Graph for recovery keys and reconcile against local manage-bde output
- Build a repeatable, scheduled audit rather than a one-off manual check
- Execute a safe rollback that decrypts before removing policy, avoiding orphaned encrypted drives
#Prerequisites
Access requirements: an account with Intune Policy and Profile Manager rights (or equivalent Endpoint Manager role), plus Entra ID permissions sufficient to read device objects and BitLocker recovery keys via Graph — specifically Device.Read.All and BitLockerKey.Read.All delegated or application scopes if scripting the audit. Global Reader is insufficient for the Graph BitLocker recovery key endpoint in most tenant configurations; test this against a non-production account first rather than assuming role inheritance covers it.
Environment requirements: at least one test device per hardware SKU in the fleet, since TPM firmware version affects escrow timing behaviour. A hybrid-joined test device is required separately from an Entra-joined one if the estate has both, because the escrow destination logic differs and cannot be validated on one join type alone.
Tooling: PowerShell with the Microsoft.Graph module installed locally or in Cloud Shell for the audit script, and local admin rights on test devices to run manage-bde and dsregcmd. If the estate still runs a legacy BitLocker GPO, read access to the linked OU in AD is needed to confirm whether it is still active before attempting any profile rollout, since an unnoticed active GPO is the most common cause of the conflict failure mode.
Change management: because this profile can trigger encryption on devices not previously encrypted, a documented pilot scope and rollback plan should exist before assignment — not drafted reactively after a kiosk or lab machine gets caught by a broad dynamic group query.
#Worked Example
Consider a 40-device pilot mixing Entra-joined laptops and hybrid-joined desktops still linked to a legacy BitLocker GPO. Before touching Intune, dsregcmd /status is run against five sample machines: three return AzureAdJoined:YES with DomainJoined:NO, confirming pure Entra join; two return both flags set, confirming hybrid join with on-prem AD as the current escrow target.
The Endpoint Protection profile is built and assigned only to the Entra-joined subset first, using a dynamic group scoped to that cohort's naming prefix. After one policy sync cycle, manage-bde -status C: on a test laptop reports a RecoveryPassword key protector with GUID ending in 7f2a. The Graph query against that device's object ID returns a matching recovery key entry — escrow confirmed on the first attempt.
For the hybrid-joined subset, the legacy GPO is disabled at the OU level before the Intune profile is assigned, avoiding the registry-key conflict under HKLM\SOFTWARE\Policies\Microsoft\FVE. gpupdate /force is run, followed by a manual Intune sync from Settings > Accounts > Access work or school. A second manage-bde -status check on one hybrid device shows encryption completed, and the Graph BitLocker recovery key query returns the matching entry, confirming redirection to Entra ID succeeded rather than silently defaulting to the now-disabled GPO path.
One hybrid device in the pilot shows encrypted status locally but an empty Graph result. Cross-checking with Get-MgDevice -Filter reveals the query used the Intune device ID rather than the Entra object ID; re-running with the correct object ID returns the expected key. This is logged as a procedural note for the audit script rather than a genuine escrow failure, illustrating why the ID-mismatch trap in the failure table is worth checking before escalating a suspected escrow fault.
With all 40 pilot devices verified individually, the scheduled audit script is run against the pilot group as a rehearsal for full-estate use, exporting zero rows to unescrowed-devices.csv — the expected clean result that justifies expanding assignment to the next ring.
Comments
Add a thoughtful note on Escrowing BitLocker Recovery Keys via Intune and Entra ID. Comments are checked for spam and held for moderation before appearing.
Related articles
Endpoint and Device Management
Automating Leaver Device Retirement and Autopilot Cleanup in Intune
A practical runbook for retiring leaver devices in Intune, de-registering Autopilot hashes and cleaning up Entra ID device objects with verifiable evidence.
Security & Operations
Failure-Aware Security Operations Architecture for Microsoft Defender
A bounded, failure-aware Security & Operations workflow for Microsoft Defender: detection, semi-automated investigation, reversible device isolation, and a validated recovery path with least-privilege role separation.
Software Architecture
A Bounded Recovery Path for API-Driven Software Architecture Changes
How to design, validate and recover one bounded API architecture change with explicit evidence, bounded failure containment and a fixed rollback path.
Discover more
Graduate Learning
Ops Playbook
Lexicon Definitions
Learn More About KBY
About KBY
Learn about our mission, editorial standards, and commitment to trusted engineering knowledge.
Why Trust KBY
Explore the processes and policies that ensure our publications are accurate, useful, and responsible.
Newsletter
Get our latest editorial publications, research and practical insights sent directly to your inbox.
Was this useful?
Build practical engineering skills.
Receive new lessons, learning paths, practical exercises and early-career guidance.