BitLocker Recovery Key Not Backed Up to Entra ID After Autopilot? Fix the Escrow Gap

A new laptop finishes Autopilot and shows encrypted in Intune. Months later it boots to the BitLocker recovery screen, you open the device in Intune, and you get “No BitLocker key found for this device”. The drive was encrypted during provisioning, but the recovery key never reached Entra ID.

This post covers why that happens to Autopilot devices specifically, and how to set up your policy so every new build escrows on day one. If you already have a fleet of deployed devices with missing keys, that's a different job. It's covered in BitLocker Recovery Key Missing From Intune? Force the Escrow Fleet-Wide.

Why Autopilot devices skip the BitLocker key backup

Windows backs up a recovery password when the protector is created. If that one attempt fails and your policy doesn't make backup mandatory, the drive stays encrypted with a key that exists only on the device. Every cause below is a way of losing that one attempt.

Automatic device encryption beats your policy

On capable hardware, Windows encrypts the OS drive on its own during OOBE. Microsoft's Autopilot documentation says that by default this uses XTS-AES 128-bit, used space only. Your Intune settings only get there first if the device has an Enrollment Status Page: “If an ESP isn't enabled, the BitLocker policy doesn't apply before encryption starts.”

Once Windows has encrypted the drive, your policy doesn't redo it. The disk encryption settings reference says that if the drive was already encrypted, “no extra action is taken”. If the in-place configuration doesn't match the policy, “configuration will likely return an error”. So you end up with a 128-bit drive, a policy in error, and a backup that ran on Windows' terms rather than yours.

Windows 11 24H2 made this more common. Microsoft's OEM BitLocker documentation states that automatic device encryption “doesn't depend on Hardware Security Test Interface (HSTI) / Modern Standby anymore”, and the DMA interface check was removed too. Many mid-range business devices that used to skip automatic encryption now encrypt during OOBE after a clean install.

There's also a documented race on unregistered devices. Microsoft's Autopilot known issues page says BitLocker “might default to 128-bit even though the admin configured 256-bit encryption due to a known race condition” and recommends registering devices. For Autopilot device preparation, Microsoft says in its September 14, 2026 notes that “the default 128-bit BitLocker encryption policy is no longer applied during OOBE.”

Backup isn't required, so failure is silent

This is the setting most tenants get wrong. Microsoft's settings reference for the older profile is blunt: when the “require backup” option is not configured, “BitLocker enablement will complete even if recovery key backup to Microsoft Entra ID fails.”

In the current Settings Catalog-style profile, the switch is named after AD DS: “Do not enable BitLocker until recovery information is stored to AD DS for operating system drives”. That puts people off, but the BitLocker CSP documentation states that for Microsoft Entra joined devices the recovery password is backed up to Entra ID. Leave it off and a dropped Wi-Fi connection during OOBE is enough to lose the key: as one community answer on the Microsoft Q&A thread “BitLocker keys aren't syncing to Entra ID (Azure AD)” puts it, “if there is even a slight network hiccup, the backup fails and it rarely retries successfully on its own.”

Pre-provisioning (white glove): the technician flow has no user

In pre-provisioning, the technician flow runs only the Device preparation and Device setup phases of the ESP. It applies device-targeted policy, so BitLocker can start there. In his call4cloud.nl post “Autopilot & Pre-Provisioning's Infinite Play...uh...Waiting list”, tested on a pure Entra joined setup, Rudy Ooms showed that after enrolment in this phase the device lost its Entra device certificate and no user was signed in. The key backup then failed with event 846 and error 0x801c0450, which the PowerSyncPro knowledge base resolves to DSREG_E_CERTPROVIDER_NOT_FOUND: the device “could not locate a valid certificate to authenticate to Entra ID”. Pair that with a custom script that waits for escrow and you hit the 30-minute PowerShell script timeout in the ESP.

Silent encryption never actually ran

Sometimes the “missing key” is really missing encryption, or encryption that a user started by hand. Silent enablement needs:

• an Entra joined or hybrid joined device (Entra registered isn't enough)
• TPM 1.2 or later
• native UEFI with Secure Boot
• a working WinRE

It also needs no TPM startup PIN or startup key. Microsoft specifically warns that the security baseline for Microsoft Defender can turn on the TPM startup PIN and key, which blocks silent enablement.

Hybrid joined and the 200-key ceiling

Hybrid Autopilot creates two device objects for a while, so you can easily find the “empty” one. Hybrid pre-provisioning also fails when policy needs line of sight to a domain controller. Separately, Microsoft's “Encrypt Windows devices with BitLocker using Intune” page states that “Microsoft Entra ID supports a maximum of 200 BitLocker recovery keys per device” and that if you reach this limit, “silent encryption fails due to the failing backup of recovery keys before starting encryption on the device.” Heavily reused devices are the ones at risk.

How to confirm the escrow failed on the device

Open Event Viewer, then Applications and Services Logs > Microsoft > Windows > BitLocker-API > Management. These are the events worth knowing, as documented by Microsoft:

Event 845 in the BitLocker-API Management log is your proof that escrow actually happened.

Then cross-check:

• dsregcmd /status should show AzureAdJoined : YES.
• manage-bde -status C: shows the encryption method and conversion status. XTS-AES 128 on a tenant that requires 256 means automatic encryption won the race.
• manage-bde -protectors -get C: should list a Numerical Password protector. If you only see TPM, no recovery password was ever created.
• In Intune, go to Devices > All devices > (device) > Recovery keys. In Entra, open the device record and check its BitLocker keys.
• Devices > Monitor > Encryption report shows encryption state and readiness. Don't treat “Encrypted” as proof of escrow.

The disk encryption policy settings that make escrow stick

Create the policy in Endpoint security > Disk encryption > Create Policy > Windows > BitLocker. Use one policy, and don't layer it over a legacy Endpoint protection profile or a baseline that sets conflicting BitLocker values.

Three things make or break this for Autopilot:

1. Assign to a device group. Microsoft's Autopilot BitLocker guidance is explicit that it must be a device group and not a user group. A dynamic group on (device.devicePhysicalIDs -any (_ -startsWith "[ZTDId]")) covers every registered Autopilot device.
2. Assign an ESP to the same devices. Without it, the policy doesn't apply before encryption starts.
3. Accept the trade-off. With backup required, a device that can't escrow stays unencrypted instead of silently encrypting. That's what you want, because a compliance policy requiring BitLocker will flag it, whereas a key that silently went missing never gets flagged.

For pre-provisioning, let this policy apply in the technician flow, but judge success only after the user flow. Don't deploy custom scripts that loop waiting for escrow during the technician phase.

Check the BitLocker key backup on the device you just enrolled

Run this elevated on the test device after the user flow completes:

# Encryption state and protectors
Get-BitLockerVolume -MountPoint $env:SystemDrive |
    Select-Object VolumeStatus, EncryptionMethod, ProtectionStatus, KeyProtector

# Escrow evidence (confirm the channel name with: Get-WinEvent -ListLog *BitLocker*)
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-BitLocker-API/Management'
    Id      = 845, 846
} -MaxEvents 10 | Format-Table TimeCreated, Id, Message -Wrap

If there's a recovery password protector but no 845, push the existing one:

$rp = (Get-BitLockerVolume -MountPoint $env:SystemDrive).KeyProtector |
    Where-Object KeyProtectorType -eq 'RecoveryPassword'

foreach ($p in $rp) {
    BackupToAAD-BitLockerKeyProtector -MountPoint $env:SystemDrive -KeyProtectorId $p.KeyProtectorId
}

The loop matters. Some devices carry more than one RecoveryPassword protector, and passing the whole collection to -KeyProtectorId fails. Only add a new protector with Add-BitLockerKeyProtector -RecoveryPasswordProtector when there are none at all. Each extra protector is another key against the 200-per-device limit and another key your helpdesk has to choose between.

The key ID in Entra should match the protector ID from Get-BitLockerVolume.

Already deployed devices without keys

Fixing the policy only protects new builds. Devices that are already encrypted won't re-escrow on their own, because Windows backs up a recovery password when it's created or rotated. For those, detect the missing 845 and force the backup through Intune remediations, which is exactly what the fleet-wide escrow fix walks through. A similar technician-flow gap affects LAPS: Microsoft lists LAPS policy as not applying until the user phase of pre-provisioning. If that's biting you too, see Windows LAPS password not rotating.

FAQ

Why is my BitLocker key not backed up to Entra ID after Autopilot?

Usually encryption started before your policy arrived (no ESP, or automatic device encryption won the race), or the backup failed and your policy didn't require it. Check events 845 and 846 in the BitLocker-API Management log first.

Does BitLocker escrow the recovery key during Autopilot pre-provisioning?

Device-targeted BitLocker policy applies in the technician flow, but escrow can fail there because no user is signed in and the device state changes after enrolment. Verify the key after the user flow, not when the technician flow shows green.

Why does encryption not start when “store recovery information before enabling BitLocker” is on?

Because the backup is failing, and the setting is doing its job. Fix the cause: join state, network, the 200-key limit or TPM issues. Don't turn the setting off.

Why did Autopilot encrypt with XTS-AES 128 instead of 256?

Automatic device encryption ran first. Make sure an ESP is assigned and the device is registered for Autopilot. A drive that's already encrypted has to be decrypted before a new cipher applies.

Do I need a disk encryption policy if Windows encrypts automatically?

Yes. Automatic encryption doesn't give you control over the cipher, the startup authentication or mandatory escrow.