Escrowing BitLocker Recovery Keys via Intune and Entra ID

#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 encryption), then a TPM failure, a firmware update that trips a PCR measurement, or a simple forgotten PIN turns into a device that cannot be recovered without wiping it. For a fleet standardising on Intune, key escrow is not an optional hardening extra. It is the difference between a five-minute help desk call and a full re-image with data loss.

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).

1. Confirm the device join type first. Escrow destination depends on it. Run on a test machine:

   snippet.text

   1dsregcmd /status

   Look for AzureAdJoined or DomainJoined plus AzureAdJoined (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.

2. 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:

   snippet.text

   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: Yes

   The 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.

3. Assign to a pilot group, not the whole estate. Use an Entra ID dynamic device group scoped to a small cohort:

   

   snippet.text

   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.

4. 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.

5. 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, KeyProtector

You 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 -NoTypeInformation

Run 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

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.

1. Remove the pilot device group assignment from the Endpoint Protection profile first, so no new devices pick it up.
2. For devices already encrypted that need to be reverted, decrypt explicitly and deliberately:
   snippet.text

   1manage-bde -off C:

   then confirm with manage-bde -status C: until it reports “Fully Decrypted”.

3. Only after decryption is confirmed, remove the profile assignment or delete the profile in Intune.
4. 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.
5. 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.