By Matt Shadbolt | Intune Sr. Program Manager


Microsoft Intune provides a comprehensive set of configuration options to manage BitLocker on Windows 10 devices, October 2018 update.


One such setting allows the IT Administrator to set the BitLocker encryption algorithm. The BitLocker encryption algorithm is used when BitLocker is first enabled and sets the strength to which full volume encryption should occur. An IT Administrator can set this algorithm to AES-CBC 128-bit, AES-CBC 256-bit, XTS-AES 128-bit or XTS-AES 256-bit encryption.


By default, Windows 10 will encrypt a drive with XTS-AES 128-bit encryption. Encryption can be enabled on unencrypted Windows 10 PCs using MDM policy, such as when the device becomes Azure AD Joined (AADJ).


When a Windows 10 device runs through the Out Of Box Experience (OOBE), and an AADJ occurs during OOBE, BitLocker may be automatically enabled on modern hardware with the default XTS-128-bit encryption algorithm before the Intune MDM policy is processed and the IT administrator’s configuration is applied.


This causes a situation whereby the BitLocker disk encryption does not meet the IT administrator’s defined requirements in Intune.




Microsoft Intune recently made some UI changes to call out that these settings only apply at first encryption. To help improve this experience, we made some changes to the Windows Autopilot build process that enables Windows to consume the IT administrator’s MDM settings before automatic encryption is started.


From Windows 10 October 2018 Update, the BitLocker encryption algorithm can be changed during an Autopilot build. To achieve this, you need to configure the following:

  1. Configure the encryption method settings in the Windows 10 Endpoint Protection profile to the desired encryption algorithm.
  2. Target the encryption method policy to your Autopilot group of devices. This is required as the policy needs to be processed as a device targeted policy, not a user targeted policy.
  3. Enable the Autopilot Enrollment Status Page (ESP) for your users/devices. This is required because if the ESP is not enabled, the policy will not apply before encryption starts.

By meeting these three configuration requirements, your Autopilot configured devices will now honor the BitLocker encryption algorithm setting and will encrypt with your specified encryption algorithm.


Let us know if you have any questions on this expanded feature set. 

New Contributor

Question for me.   Windows 10 October 2018 Update ties back to 1809 build.   We have several devices on 1809 that are Hybrid DJ in AutoPilot yet the Bitlocker is now kicking off automatically.   Is there a dependency that is also tied to Win10 being on Enterprise vs Pro?   Reason why it would not be running automatically.

Certain this is in doc's, but quoting directly from one of our Intune experts, Courtenay Bernier- "Beginning with Windows 10 Creators Update (1703) BitLocker can also be managed and enabled with Microsoft Intune by using Configuration Service Provider (CSP) settings.  Note: Windows Business/Enterprise/Education is required.https://blogs.technet.microsoft.com/cbernier/2017/07/11/windows-10-intune-windows-bitlocker-manageme... 

Senior Member

Hi Intune Support Team, I am looking for some confirmation that in order to enforce 256bit encryption, the Bitlocker policy needs to be assigned to a DEVICE group and not a USER group to make sure it gets pulled down early enough during the ESP. This blog post is the only place where I have been able to find any reference for this requirement. If this is indeed required, my plan is to target the policy to the same AAD device groups that I use to assign the AutoPilot profiles. You mention to target the 'Autopilot group of devices', which I read to be the same approach. Any confirmation or link to additional information on this topic would be greatly appreciated. Thanks, Jan


Update: I feel that Oliver K. Has been able to answer my question about DEVICE vs. USER targeting in the comments section of his blog post  @ 


Senior Member

The blog post states that 'To help improve this experience, we made some changes to the Windows Autopilot build process that enables Windows to consume the IT administrator’s MDM settings before automatic encryption is started.'


It is my understanding (and that of the Microsoft engineer working on a case on this exact question) that most modern hardware (InstantGo) will start automatic encryption with 128bit when the PC first boots up, right at the start of OOBE. This is before any of the MDM settings can be applied.


Can you please explain how we can enforce 256bit encryption using MDM settings and the ESP as described in this blog post for those 'modern' devices?


Hi Jan. You're right, InstantGo devices will automatically enable device encryption on Azure AD Join. Per this blog post, if you're using Autopilot and target the configuration correctly (to a device group, ESP, etc), the policy is received by the client early enough before auto encryption starts. This means the 256-bit encryption requirement will be honored when auto encryption begins. 

Hope that helps clear it up. 


Senior Member

Hi Matt,

Maybe I am confusing InstantGo with something else here, but what I was trying to say is that we have devices that auto-encrypt at first boot! This is at the very beginning of the OOBE when the user selects the region, so before Internet/AutoPilot/Intune has even been contacted. If that happens, 128bit encryption is used and MDM/ESP even when targeted to a device group will not be able to change it because encryption has already started. Not sure why some devices auto-encrypt that early in the process, and unfortunately there is no mention of this in any of the MS blogs/docs.

We have an open case with MS on this, so please feel free to look at that if you have access: 119030526001011