To protect data at rest on your Intune-managed Windows devices, BitLocker disk encryption can be applied automatically using the BitLocker CSP.  If you are deploying devices with Autopilot, this will also allow you to encrypt them at the time of deployment.  Existing devices will be encrypted as soon as the device checks in with Intune to pull down the configuration.

There is a wealth of settings in Intune for BitLocker. Some are unintuitive, some cause conflicts, and some are even hidden.  Following this article, you can configure BitLocker encryption to best-practice for reliable, secure disk encryption in your environment.

The settings for BitLocker are exposed in two Microsoft Endpoint Manager (MEM) areas: endpoint security profiles and configuration profiles.  Both profile types ultimately configure the same background settings, but with a different user interface.  Endpoint security profiles are the newer type of Intune profile, with the intent being you can manage all your security rules in a dedicated part of MEM.  However, not all configuration possibilities are available in it.  Therefore, this best-practice guide relies on both profile types.

In all scenarios, choose to assign your Intune settings to devices rather than users.  Disk encryption is not the kind of policy you want to always follow a user as they move from device to device, and may lead to unintended encryption.

Endpoint security profile – configuration settings

BitLocker endpoint security profiles are set up in Endpoint security > Manage > Disk encryption.  From here, choose Create Policy

 

Choosing to hide prompt about third-party encryption is a prerequisite to silent encryption, which is an automated approach that does not require end-user intervention. If there is third-party encryption enabled (such as TrueCrypt) and BitLocker encrypts too, this can cause problems, so it is important to conduct discovery of your environment prior to production deployment.  Allow standard users to enable encryption during Autopilot is important if you are Azure AD Joining your Autopilot devices.  If this is not set to yes and users are not administrators, silent (automatic) encryption will not work.  Lastly for base settings, enabling client-driven recovery password rotation for both device states (Azure AD Joined and Hybrid Azure AD Joined) will trigger the recovery key to change (“rotate”) when used, therefore removing a potential backdoor if a user is ever provided one during a support request.

Fixed drive settings

The fixed drive settings control encryption rules for internal drives that do not contain the OS.  This is where the sheer vastness of options becomes apparent.  Best-practice settings are detailed below.

Here’s the reasoning behind some of the less intuitive settings.  Recovery key file creation, configure BitLocker recovery package, and hide recovery options during BitLocker setup are configured as prerequisites for silent encryption.  By specifying require device to backup recovery information to Azure AD, you introduce a safeguard whereby the encryption will not take place if a recovery key cannot be created.  Block write access to fixed data-drives not protected by BitLocker is recommended as it prevents saving data on unencrypted drives, and may be important for compliance reasons.

Finally, it’s recommended that AES-256-XTS is used as the encryption method.  The intricacies of 128-bit vs. 256-bit key sizes and different ciphers is beyond the scope of this article, but AES-256-XTS is generally agreed to offer the best balance of strong encryption for regulatory compliance along with ease of use in Windows 10 environments.

OS drive settings

Operating system drives are controlled by OS drive settings and recommended settings, below, are mostly the same as fixed data-drives, but with settings for startup and keys too.

 

As BitLocker encrypts full disks, a decryption key is required.  The most secure method of holding this decryption key is in the Trusted Platform Module (TPM) – a hardware element that securely holds secrets and has controls to prevent against things like brute force attacks to steal them. The other advantage of decrypting use the TPM is it allows to encrypt the device automatically (silently), because if we instead asked for a key or password from the user, that would interrupt them with a prompt.  Therefore, it’s recommended you only deploy the encryption to devices with a TPM, and control this by setting startup authentication required to yes and compatible TPM startup to required.

Removable drive settings

The final area of our BitLocker endpoint security, removable drive settings apply to storage devices such as USB flash storage devices and external hard drives.

The only setting it’s recommended be configured here is setting the encryption method to AES-256-XTS.  The remaining two settings to block write access if configured as endpoint security profile can lead to conflicts if you want different rules for different devices, so are best controlled using device configuration profiles.

Device configuration profile – configuration settings

While enforcing removable storage devices to be encrypted is generally regarded as a wise move to improve things such as data loss prevention, many environments should not deploy it universally to all devices.  For example, if the IT department regularly provisions USB boot devices for OS deployment, you shouldn’t force all of those to be encrypted, nor may you want to enforce encryption on departments that will send devices to customers.

Therefore, we want to have different rules for different devices, and do this with configuration profiles found in Devices > Windows > Configuration profiles.  From here, choose to Create profile of template Endpoint protection.

 

Removable drive settings

In this configuration profile, expand Windows Encryption then BitLocker removable data-drive settings.  It is important to leave all other settings unconfigured to avoid conflicts with the endpoint security profile.

 

By choosing to block for both settings, you ensure that drives are mounted in read-only mode until encrypted, which users will be prompted to do, and also limit write access to encryption delivered by your environment’s devices, rather than BitLocker encrypted by other environments or on BYOD devices.  Your “organisation” is determined by the IdentificationField, which is ultimately is a string held in the registry.  So this policy is not foolproof against a dedicated adversary, but a good first-line-of-defence against accidental noncompliance.

You can now assign this device configuration profile only to device groups that you want to enforce the policy on.

Important Notes about Intune BitLocker Deployment

In addition to the configuration detailed above, we’ll conclude with notes on important prerequisites and advice for making your rollout successful.

The BitLocker CSP isn’t available in Windows 10 prior to version 1703, so you should upgrade devices to the latest feature version.  The version you upgrade to may also be important if you don’t have Windows 10 Enterprise.  Windows 10 version 1703-1803 do not support Windows 10 Pro, only Enterprise.  Pro is supported by 1809+.

As drives encrypt, BitLocker will automatically send recovery keys to Azure AD if you followed the configuration above.  These are maintained against the device object.  However, BitLocker will not automatically send recovery keys for drives already encrypted, which you may find to be the case if your supplier sends them already encrypted, or you have previously done so manually.  One way to get that key into Azure AD is to script the use of the PowerShell cmdlet BackupToAAD-BitLockerKeyProtector.

If devices are already encrypted with BitLocker, your policies deployed by Intune will not change the existing encryption.  For example, a device encrypted at AES-128-XTS will not be changed to AES-256-XTS, and you will actually see the policy logged as a failure in the Intune logs.  If the device has the same encryption settings already, the policy will be logged as successful, but it won’t have actually done anything other than verify it doesn’t differ from your requirement.

Finally, in some Autopilot scenarios, only the default Intune setting of AES-128-XTS will apply. This effects Windows 10 version 1803 and prior because these versions do not wait until the Enrolment Status Page (ESP) has finished before they start encrypting (if the hardware supports automatic encryption), and therefore encrypt prior to retrieving all your Intune settings.  Consequently, it’s a strong recommendation to ensure your Autopilot device supplier ships your devices with the latest Windows 10 feature update.