Hello @cullen ,
If BitLocker was enabled manually before the devices were enrolled or before the Hexnode BitLocker policy was applied, the existing recovery key may not automatically appear in Hexnode UEM. In that case, the recovery information may still be stored locally on the device or in another directory service, depending on how BitLocker was originally enabled.
For Hexnode UEM to store the recovery key, verify the BitLocker policy configuration:
-
Navigate to Policies > Windows > Security > BitLocker.
-
Under the recovery options, ensure the option Escrow recovery password to Hexnode UEM is enabled.
-
Save the policy and ensure it is assigned to your devices.
-
Go to Manage > Endpoints, select the affected machines, click Actions, and select Scan device to force them to fetch the new policy and report their updated status.
For the devices that are still reporting as “non-encrypted,” verify the following hardware and system prerequisites:
-
TPM (Trusted Platform Module): BitLocker requires a compatible TPM (1.2 or 2.0) enabled in the device BIOS/UEFI. You can verify this locally on a device by pressing Win+R, typing tpm.msc, and hitting Enter. If a device lacks a compatible TPM, your policy must have the Allow BitLocker to be activated on devices without a compatible TPM option enabled.
-
Silent Encryption Requirements: For encryption to trigger silently without user interaction, the device must be Microsoft Entra ID joined. Standard domain-joined or workgroup devices will require user interaction on the device itself to begin encryption.
-
Pending System Reboots: Windows often requires a system check and a restart before it will begin disk encryption and report the new status back to Hexnode UEM.
Regards,
Simon Scott
Hexnode UEM