Let’s say you want to enable BitLocker during a Windows Autopilot user-driven deployment, and you want “maximum security” by changing the default BitLocker encryption settings to instead use XTS-AES 256-bit encryption (instead of the default 128-bit). You would end up creating a device configuration profile in Intune that looks something like this:
Notice the note that is displayed in the Intune portal when you choose an encryption method that is different from the default:
Note: devices enabled with automatic encryption will require decryption before changing encryption method.
Well, if this is a new device being deployed via Windows Autopilot, that’s exactly what you don’t want to do.
It’s worth explaining what it means for a device to be “enabled with automatic encryption.” As mentioned in the BitLocker docs, devices that meet these requirements will automatically begin encrypting:
- The device contains a TPM (Trusted Platform Module), either TPM 1.2 or TPM 2.0.
- UEFI Secure Boot is enabled. See Secure Boot for more information.
- Platform Secure Boot is enabled
- Direct memory access (DMA) protection is enabled
The rest of that doc page explains in even more detail what’s required, but there is one more key item: The device needs to support modern standby or HSTI. Practically, this includes all Surface devices, and some OEM devices (especially tablets).
OK, but why does that all matter? Imagine you aren’t using the Enrollment Status Page (or, horror of horrors, you aren’t using Windows Autopilot at all). As soon as the device boots up, if it sees the device meets the automatic encryption requirements it will start encrypting. And that give you no time to get a new set of BitLocker settings to the device first, so it starts encrypting with the default XTS-AES 128-bit settings. Too late to make changes, hence the note in the portal about having to decrypt to make the change.
Alright, now back to making it actually work. We made some changes in Windows 10 1809 and above to fix this problem when you are using BitLocker with Windows Autopilot and the Enrollment Status Page. With these changes, BitLocker will wait to begin encrypting until the end of OOBE, after the ESP device configuration phase has completed. That gives Intune sufficient time to get the BitLocker policies applied to the device first, so when BitLocker starts encrypting, it does it using the XTS-AES 256-bit settings you configured.
Of course all of this is documented in the Windows Autopilot documentation. I’m sure you’ve read all of that, right?
There’s one other gotcha though: Windows 10 1903 broke this process (causing BitLocker to start encrypting prematurely) requiring some additional changes that were included in the June 27th cumulative update (KB4501375) and all later updates. (There are a variety of other Windows Autopilot fixes in the July 26th cumulative update, so it would be even better to use at least that one.) For new devices, make sure your OEM is shipping a properly-patched version of Windows 10 1903 to get those fixes.
Categories: Windows Autopilot
What happens if the device gets the default 128 bitlocker and we send a bitlocker 256 policy to the device ? I presume it will fail , Probably remediation error?
It definitely won’t be able to change the setting. I believe Intune will report the policy as failed.
Hi Michael, should Intune be able to ask a non-admin user to set a BitLocker PIN upon logon? I’ve not be able to get this working so far. Kind regards, Paul
I don’t believe that’s possible, at least not without doing something custom. I would generally argue for getting rid of the PIN as a better option.
Thanks for the rapid response. We are also discussing the need for the PIN too. Dispensing with it will make my life easier… Will please the users too no doubt! Currently in the UK, the NCSC (National Cyber Security Centre) that much of the government follow are still advocating the PIN, so hopefully they can change their direction. Kind regards, Paul
We currently enforce the PIN in some entities (like the UK). We workaround it by deploying a required Win32 app which is targeted at the user. The Win32 app just runs a PSH script to set a default PIN. The users can then change the default PIN to one of their choosing when the desktop loads (standard users can change the PIN). We use a Win32 app simply to ensure it’s tracked by the ESP, when that supports PSH we will just use the native PSH support in Intune.
We are working with our security teams to see if we can remove the PIN but this seems to work quite well as a temporary solution. There is a risk that the user does not change the default PIN – we could probably address that with a scheduled task to prompt the user.
what happens to the bitlocker encryption when I want to do a remote “autopilot reset”?
Is the encryption removed for this period?
What is with the WinRE partition? Is this also encrypted?
Thanks for a reply,
The WinRE partition is not encrypted (necessarily so, as the device needs to be able to boot the recovery image). When doing a reset of any kind, the BitLocker encryption is temporarily suspended, but the disk remains encrypted.
If you require a “startup PIN with TPM” the disk won’t be encrypted when using WhiteGlove.
Is there a way to pre-encrypt the device during WhiteGlove and then prompt the user to enter his PIN after the first sign-in ?