bitlocker to go

BitLocker To Go enabling by itself on Windows 11 24H2/25H2 devices is typically the result of BitLocker/device-encryption prerequisites being met and an encryption policy or default behavior being applied, even if no explicit “BitLocker To Go” setting was configured in Intune or classic Group Policy.

From the available information, the following checks and explanations are supported:

1. Verify whether Intune is actually targeting the devices
   • Use the MDM Diagnostics Report on an affected device to confirm whether any BitLocker CSP settings are being applied:
     • Generate the report (saved under C:\Users\Public\Documents\MDMDiagnostics).
     • Use the BitLocker CSP documentation referenced in the report to see which BitLocker-related settings are present and whether they match the intended Intune configuration.
   • This helps confirm if a device configuration or compliance policy is silently enforcing encryption.
2. Confirm OS build and edition behavior
   • The MDM Diagnostics Report also shows OS build and edition. Some BitLocker CSP settings only apply from specific Windows 10/11 versions and editions onward. As devices move to newer builds (such as 24H2/25H2), previously non-effective settings can start applying and trigger encryption.
3. Understand automatic/device encryption behavior
   • Device encryption is a Windows feature that can automatically enable BitLocker when hardware prerequisites (TPM, UEFI, etc.) are met. It encrypts OS and fixed data drives automatically after out-of-box experience and recovery-key backup to Microsoft Entra ID or AD DS.
   • On newer builds (starting with Windows 11, version 24H2), prerequisites like DMA and HSTI/Modern Standby are relaxed, so more devices become eligible for automatic encryption. This can make it appear as if BitLocker “enabled itself” once the OS was upgraded.
4. Check BitLocker status and policy alignment on a sample device
   • On an affected machine, run as administrator:
     • manage-bde -status to see which volumes are encrypted and with what method.
   • Compare the encryption method (for example, XTS-AES 128 vs 256) and scope (OS vs fixed vs removable) with what is configured in Intune. A mismatch can put devices into an error or unexpected state even though they are encrypted.
5. Validate TPM and prerequisite state
   • Use msinfo32 and tpm.msc or Get-Tpm to confirm that TPM and UEFI are present and ready. When these prerequisites become satisfied (for example, after firmware changes or OS upgrade), previously dormant policies or default device-encryption behavior can start encrypting drives without additional admin action.
6. Use Intune encryption reporting to identify the trigger
   • In the Intune encryption report, check:
     • Whether devices show as “ready but not encrypted silently,” “encrypted,” or “error state but encrypted.”
     • Status details can indicate if WinRE, TPM, or admin-rights prerequisites were blocking encryption earlier and are now satisfied, which would explain why encryption started after moving to 24H2/25H2.

In practice, the combination of:

• Automatic/device encryption behavior in Windows,
• Relaxed prerequisites in Windows 11 24H2 and later, and
• Existing but previously ineffective BitLocker/Intune settings

can cause BitLocker (including BitLocker To Go for fixed/removable drives) to start encrypting without any new explicit configuration.

To regain control, use the MDM Diagnostics Report and Intune encryption report to identify which BitLocker CSP or compliance settings are active, then adjust or remove those policies and, if required, decrypt affected drives using manage-bde in a controlled manner.

References:

• Troubleshooting BitLocker policies from the client side
• BitLocker overview
• Troubleshooting BitLocker with the Intune encryption report