BitLocker Automatic Device Encryption Recovery Key Escrow for Local Accounts

Direct answer

No documented mechanism exists to force a BitLocker recovery key export to a local network share during the OOBE Automatic Device Encryption flow when a local account is used. With cloud identity integration disabled, Automatic Device Encryption still encrypts the OS volume on Windows 11 systems meeting TPM and Modern Standby requirements, but the recovery key is not escrowed to Microsoft account or Entra ID. Escrow must be provided after OOBE by domain-based policy or by a post-provisioning script.

Confirmed facts

• Group Policy "Store BitLocker recovery information in Active Directory Domain Services" under Computer Configuration → Administrative Templates → Windows Components → BitLocker Drive Encryption → Operating System Drives forces recovery keys to be saved in AD for BitLocker encrypted volumes, regardless of the account type used during OOBE.
• Group Policy "Backup BitLocker recovery information to a network share" in the same path stores the recovery key on a specified UNC after encryption completes. It does not run during the OOBE automatic encryption step.
• There is no documented OOBE configuration that directs the automatic encryption process to export the recovery key to a local network share when a local account is used.
• Once provisioned, the recovery key is viewable locally via Manage BitLocker UI or manage-bde -protectors -get C:.

Likely explanation for the gap

Automatic Device Encryption is designed to escrow to the user’s cloud identity during OOBE. With a local account and no domain join, the OS has no built-in escrow target. The network share backup policy applies after the BitLocker service processes the volume, not during the initial automatic encryption trigger in OOBE. This is why administrators see encryption succeed with no external key copy.

Steps needed for this case

Assumption: Windows 11 24H2, TPM 2.0 present, local accounts used in OOBE.

1. Determine join state. If devices are domain-joined, enable "Store BitLocker recovery information in Active Directory Domain Services" and ensure the computer account can write to AD.
2. If devices remain workgroup, Automatic Device Encryption will not escrow externally. Use a post-OOBE provisioning step to export the key. Example approach: deploy a scheduled task or provisioning package that runs after first sign-in as SYSTEM and copies the key to a secured share.
3. Optional network share backup: enable "Backup BitLocker recovery information to a network share" with a reachable UNC and service account. Note this runs after encryption completes, not during OOBE.

Verification

• Confirm policy application: gpresult /h result.html
• Check local protector: manage-bde -protectors -get C:
• For AD escrow, inspect the computer object for recovery information after the policy applies.

One missing diagnostic detail that changes the recommendation: Are the devices domain-joined or workgroup? AD DS escrow is only effective when domain-joined; workgroup devices require a custom post-OOBE export and cannot use the built-in AD policy.

Uncertainty note: Policy timing and OOBE interactions require current verification on 24H2 builds. The network share backup policy is known to fail silently if the share is unavailable at encryption time.