Recovery keys are escrowed per tenant — and that is the data-loss trap in a migration
A BitLocker recovery key does not belong to the laptop. It belongs to the tenant the laptop is joined to. Move the tenant and forget that, and you can delete the only copy of the key that stands between a user and a permanently locked drive.
New to cloud? CAMPUX is a free, build-first course. Start here →
Most tenant migrations go fine right up until a machine throws a blue BitLocker recovery screen and asks for a 48-digit key that nobody can find. This is part of the Azure tenant-to-tenant migration guide, and it is the one failure that turns a routine project into a data-loss incident. The keys were escrowed, the migration ran, and somewhere in the cleanup the key vanished. Understanding where those keys actually live is the whole game.
Where the recovery keys really live
When Intune encrypts a Windows device with BitLocker, the recovery key is backed up to Microsoft Entra ID — specifically, it is stored against the device object for that machine in that tenant. Microsoft's own docs put it plainly: you view and copy those keys from the device's details in Entra or Intune, and they are "available only for Windows devices that are encrypted and store their keys in Microsoft Entra ID." An admin reads them from the device's Recovery keys blade; the owner can self-serve through the Company Portal or the My Account portal. Every one of those paths resolves through the device object in the source tenant.
That is the detail that bites. The key is not a floating record you can look up by serial number. It hangs off a device object, and a device object is a tenant-scoped thing. It has no existence outside the tenant that created it.
Why they do not move with a migration
A tenant-to-tenant migration does not carry your Entra device objects across. The device re-registers or re-enrolls into the target and gets a new object there — a clean record with no BitLocker key attached. The old key stays behind on the old object in the source tenant, and only there. Nothing in the migration copies it over. So immediately after cutover you have an encrypted disk whose escrowed recovery key sits in a tenant you are about to decommission.
The key lives on the source device object. The migration leaves that object, and the key, behind.
The exact moment the key is lost
Here is where a good plan and a bad one diverge. Cleanup is a normal migration step — you delete the stale source objects once devices land in the target. But Microsoft is explicit that deleting a device from Entra ID "removes all details attached to the device. For example, BitLocker keys," and calls it "a nonrecoverable activity." Worse, deleting the Intune object for an Entra joined device triggers a sync that removes the key protectors for the operating system volume and leaves BitLocker suspended. Do that source cleanup before you have captured the key elsewhere, and you have destroyed your only copy. If the disk later asks for recovery — a firmware update, a hardware change, a TPM reset — there is nothing to type in.
Capture before you cut. Export every device's recovery key out of the source tenant first — from the Recovery keys blade, or in bulk with a Graph script against the source — and store that export somewhere safe and access-controlled. Only then migrate the device. Re-escrow the key to the target after it re-enrolls. Verify the key is visible on the new object. Delete the source object last, once you have confirmed the target holds a good key. Reverse that order and the cleanup step becomes the incident.
Re-escrow to the target, then verify
Once the device is joined and enrolled in the destination tenant, you do not "restore" the old key — you re-escrow the current one. The supported way to push an existing recovery-password protector up to the new Entra ID tenant is the BackupToAAD-BitLockerKeyProtector PowerShell cmdlet, run against the protector already on the disk. In parallel, make sure a disk-encryption policy in the target requires backup of recovery information to Entra ID, so every future key — including rotated ones — escrows automatically. Then verify like you mean it: open the device in the target, go to Recovery keys, choose Show Recovery Key, and confirm a key ID and value are actually present. "It should have escrowed" is not verification. Seeing the key on the new object is.
A note on scale: if you are moving hundreds of machines, do the export and the re-escrow-verify as scripted, logged batches, and reconcile the count. One silently missing key in a spreadsheet of nine hundred is exactly the one that surfaces six weeks later at the worst time.
The takeaway
BitLocker recovery keys are tenant-bound: they are escrowed to the Entra device object in the tenant the machine is joined to, and that object does not travel in a tenant-to-tenant migration. Treat the key as the fragile thing it is. Export it out of the source before you touch the device, re-escrow it to the target after re-enrollment, verify it shows on the new object, and only then clean up the source — because deleting that source object is nonrecoverable and takes the key with it. This pairs directly with the device work in moving Intune-managed devices; sequence the two together and nobody ever sees the recovery screen.
Questions people also ask
Do BitLocker recovery keys transfer to a new tenant?
No. A recovery key is escrowed to the Entra ID device object in the tenant the device is joined or enrolled to, and that object does not move in a tenant-to-tenant migration. The device gets a brand-new object in the target tenant with no key attached. You have to escrow the key to the target yourself after the device re-enrolls, or verify that policy does it for you.
Where are BitLocker recovery keys stored in Entra ID?
They are stored on the device object in Entra ID, tied to that specific device in that specific tenant. An admin views them under the device's Recovery keys blade in Intune or Entra, and the owner can retrieve their own key through the Company Portal or the My Account portal. Because the key hangs off the device object, deleting that object takes the key with it.
What happens to the BitLocker key when you delete a device from Entra ID?
Deleting the device object removes all details attached to it, including the BitLocker keys, and Microsoft describes this as a nonrecoverable activity. Deleting the Intune object for an Entra joined device also removes the key protectors for the OS volume and leaves BitLocker suspended. So cleaning up the source object before you have captured the key destroys your only copy.
How do I back up a BitLocker recovery key to a new tenant?
Once the device is joined and enrolled in the target tenant, you re-escrow the existing key to that tenant rather than restoring it. The BackupToAAD-BitLockerKeyProtector cmdlet pushes the current recovery-password protector to the new Entra ID tenant, and a disk-encryption policy that requires backup to Entra ID keeps future keys escrowed. Then confirm the key appears on the new device object.
Can you recover a BitLocker key after the device object is deleted?
Not from Entra ID. Once the device object and its escrowed key are gone, there is no restore path in the tenant — Microsoft treats the deletion as nonrecoverable. Your only remaining copy is whatever you exported beforehand or a protector still present on the disk. If a recovery prompt appears after that, with no key anywhere, the data on that volume is effectively lost.