In my previous article, I tried to explain the working mechanism of Bitlocker encryption, the internal OS components involved and most importantly – why it is necessary and how it helps secure the OS platform from cold boot attacks. I would urge you to give it a read here if you have not seen it yet.
- Part 1 – Bitlocker Unlocked with Joy – Behind the Scenes Windows 10
- Part 2 – Device Encryption – Bitlocker made Effortless
- Part 3 – Deciphering Intune’s Scope w.r.t Bitlocker Drive Encryption
- Part 4 – Intune and Silent Encryption – A Deeper Dive to Explore the Internal
When we talk about security aspect of Windows 10 devices, Bitlocker presents itself in three different forms, namely
- Bitlocker Device Encryption
- Bitlocker Drive Encryption
- Bitlocker To Go
A continuation from my previous post, today in this post, I will be focusing on Bitlocker Device Encryption and how it is integrated as a seamless experience with Windows 10.
Getting to know Device Encryption… (Bitlocker Automatic Encryption?)
Device Encryption is a light weight version of Bitlocker, stripped down off the administrative capabilities and available across all Windows 10 SKU.
As per Microsoft article, from Windows 10 version 1703 onwards, devices which are
- and support Modern Standby (
S0 Low Power Idle ACPI Sleep State)
Device Encryption feature triggers Bitlocker Encryption for the OS volume and fixed Data drive (if found any) out of the box, as end users complete the device initialization through the 1st boot setup experience (OOBE).
The encryption gets triggered essentially during the time when you are presented with the First Sign-In Animation (FSIA) screen.
Anomaly to the Device Encryption requirement I discovered…
I checked using a Dell E7270 laptop which is HSTI compliant (above HSTI test result is a snap from that laptop), but does not have support for
S0 low power idle sleep state modern standby.
Surprisingly, in System Information (msinfo32), it still showed that the device meets the pre-requisites for Device Encryption.
So cannot really confirm if Modern Standby is really a legitimate requirement anymore or not. I could not find any Microsoft document stating the change in requirements.
In reality, I have seen Device Encryption working on the device running Windows 10 version 1803 onwards, without support for Modern Standby. (HSTI compliance is still required though!)
Device Encryption settings – Cipher strength and Key Protector
Device Encryption uses the default Bitlocker settings –
128 bit AES-XTS algorithmto create the
Used space onlyencryption scheme for speed
TPM onlyas the authentication method for protecting the
Recovery Keywhich is
online account(Microsoft account or Work Account) without any prompts to the end user.
Device Encryption in its default form is unmanageable – you cannot change the cipher strength or cipher algorithm.
Device Encryption feature of Windows 10 does not requires any administrative overhead, like deploying a Bitlocker policy from AD (via GPO) or Intune (any MDM solution as such).
For Windows 10 Home SKU, since it does not comes with the standard Bitlocker Drive Encryption features, you do not have the
Bitlocker GUI tool (Control Panel) or the
manage-bde command line tool available.
However, for other SKU of Windows 10 (Pro, Enterprise and Education), you can add additional Key Protectors to the default TPM only authentication used at startup to unlock OS volume for added security (at the expense of some user experience!) using the tools as mentioned above.
The tool behind Device Encryption
BitlockerDeviceEncryption.exe found at
C:\Windows\System32 is essentially what gets triggered during the FSIA if the device meets all the required criteria of Device Encryption.
How it works? Automatic Device Encryption…
If you have used a Microsoft Account or a Work Account to join the device to Azure AD, during the OOBE setup, Windows 10 will automatically trigger Bitlocker Device Encryption if device meets the criteria (HSTI compliant with Modern Standby (?) support).
It is the same story in the background
- Disk sectors are encrypted using the FVEK (128 bit AES-XTS)
- The FVEK gets protected using the VMK (256 bit AES-CCM)
- The VMK is protected using TPM (TPM EK Cert + SHA measurement of PCR 7,11)
- Recovery Key generated is backed up against the online account (Microsoft Account or Azure AD for Work Account)
Simple check to know if your device supports Device Encryption?
Open System Information (msinfo32) with admin rights and check for the highlighted item
If your system meets the prerequisites of Device Encryption, check encryption status using command line tool
manage-bde (for Pro, Enterprise or Education SKU only)
As you can see in the above snap, it shows that my device is standalone workstation (not joined to local domain or Azure AD) and there is no local Group Policy applied as well. Still encryption status shows protection is ON.
Since Windows 10 Home edition does not comes with any Bitlocker Administration interface, the way to check is using Windows Settings menu (
Settings > Update & Security > Device Encryption)
If your device does not meets the hardware prescriptions, System Information page will show you the details why the device failed automatic encryption.
Complete list of reasons for which a device can fail Device Encryption
- TPM is not available,
- TPM is not usable.
- PCR7 binding is not supported,
- Hardware Security Test Interface failed,
- Device is not Modern Standby,
- Un-allowed DMA capable bus/device(s) detected
If you see any of this in msinfo32 against the Device Encryption Support, then your device will not get automatically encrypted.
Device Encryption Events to check…
For a device meeting the pre-requisites, post completing the initial device setup as part of the guided experience (OOBE), open Event Viewer and navigate to
Applications and Services Logs > Microsoft > Windows > Bitlocker-API > Management
You would see the below events for successful automatic encryption.
Event 768 Bitlocker encryption was started for volume C: using XTS-AES 128 algorithm Event 775 A Bitlocker key protector was created Event 828 Bitlocker Drive Encryption recovery information for volume C: was backed up successfully to your Microsoft Account Event 817 Bitlocker successfully sealed a key to the TPM
Ways of getting the Recovery Key
Users can easily get access to the Recovery Key via
- for Microsoft Account, sign-in to https://aka.ms/myrecoverykey from another device to get the recovery key
- for Work Account sign-in to https://account.activedirectory.windowsazure.com/ from another device and navigate to
Profile > Devices > Select the device > Get Bitlocker keys
What if you create a Local Account during initial setup? (Bitlocker Automatic Encryption…)
If you have created a Local Account instead of using a Microsoft Account or a Work Account to sign-in during the OOBE setup, even though Device Encryption will trigger the encryption process, it won’t create the key protectors (seal VMK to TPM and create the Recovery Key).
As such, the protection status will show as Off, but notice that the volume is encrypted (used space only as default).
If you go and check Device Encryption from the Windows Settings menu, you will see that it requires you sign-in with a Microsoft account to finish the encryption.
The VMK at this stage is protected with a Clear Key. (It is not sealed to TPM yet)
Clear Key is an unprotected 256-bit AES key which gets created when there is no other VMK protector present. It is stored on the volume as RAW data along with the VMK in the FVE Metadata block to decrypt the VMK. In such a scenario, even though the drive (volume) is encrypted, but it will be freely accessible. The Clear Key gets removed as the VMK gets protected with the new protectors.
NOTE: The FVEK that gets generated is constant for a particular initialization and cannot be removed or modified (cipher strength or cipher algorithm) unless a full decrypt and re-encrypt operation. This is true for the VMK as well.
As you change the Account type from Local Account and sign-in with a Microsoft Account
Device Encryption will remove the Clear Key and proceed to seal the VMK to TPM. Recovery Key is also generated as part of the process and escrowed to the online Microsoft Account.
Requires you to sign-out of current user profile and sign-in using the Microsoft Account !!!
What will happen if you connect your Work Account to register (not Azure AD join) the device to Azure AD instead of changing Local Account to a Microsoft Account?
As you setup a Work Account to register device to your organization’s Azure AD tenant
You would require to sign-out and sign-in back (Important!) for Device Encryption to complete the process of creating the key protectors and resuming protection.
Device Encryption has no dependency on Intune (or any EMM/UEM products), as such even if you do not have auto-enrollment enabled, it will still work.
NOTE: For AAD join/AAD register with auto enrollment enabled, if your organization has a Bitlocker policy deployed from device management service with a different cipher strength and encryption algorithm, that policy will always remain in failure state. (Explained more in the last part of this post). However, if it matches the Bitlocker default settings, will show as success.
What if you switch back to a Local Account?
This can be true for only two scenarios that I can think of.
For Windows 10 Home SKU
You initially signed in with a Microsoft Account but later decide to use a local account instead (something that Microsoft wont certainly want you to as Windows 10 benefits from connected experience).
In such case, you will get the below prompt to save the Recovery Key for later use. This is important because post switching to local account, Device Encryption will not be paused but continue to be effective 🙂
Why backing up the Recovery Key is important in this scenario? If you are using Windows 10 Home SKU, then post account switch, you will not have the usual Bitlocker management tools in the OS to take the backup of the Recovery Key. Under such scenario, if your device enters recovery mode during restart or cold boot due to any changes made, you have no way to get the data back from the drive volume by yourself.
For Windows 10 Pro, Enterprise and Education SKU
You have created a local account initially and then work registered your device. But post leaving the organization, you disconnect the Work Account and continue using the local account.
In this scenario, sadly you will not get a prompt to backup the Recovery Key. But since Device Encryption will continue to protect the drive, it is important that you either turn it off (not recommended even for personal device) or backup using the Bitlocker management tool from Control Panel or using the manage-bde command line tool.
Yes, since Work Account only possible in Pro, Enterprise or Education SKU, it will also have the full Bitlocker capabilities, unlike the Home SKU.
Device Encryption Error Scenario (Bitlocker Automatic Encryption failed?)
The only thing that can cause error in Device Encryption is the security chip on your device – TPM
TPM needs to be in ready state with support for PCR 7 binding (Secure Boot needs to be enabled in UEFI) and key attestation.
But this is a Dell E7270 model which I know is HSTI compliant as I have tested with it many times. And it is certainly not possible that TPM is disabled in UEFI settings as this system has Secure Boot enabled. But still it shows TPMPresent as False.
As I checked, I found the TPM option itself went missing in UEFI settings. Checked the Dell Support site and got a match for my issue. The fix was a firmware update and TPM came back to life.
Always keep the device firmware and chipset drivers updated as made available by the OEM. The updates are made available for a purpose 😉
If you get errors related to TPM and you know your device has TPM 2.0, confirm in UEFI if the same is enabled or not.
Bitlocker Device Encryption does not supports TPM 2.0 in Legacy and CSM Modes of the BIOS. Devices with TPM 2.0 must have their BIOS mode configured as Native UEFI only. Also Secure Boot needs to be enabled as it will use PCR 7 measurement value for binding operation.
How to stop Automatic Encryption?
There may be scenarios where it requires Bitlocker to use stronger cipher strength (256 bit key instead of 128 bit) or a different encryption algorithm (AES-CBC instead of AES-XTS).
In such cases, Bitlocker Device Encryption can be a pain. This is because, once automatic encryption is triggered, the volume needs to be manually decrypted before a custom Bitlocker policy can be applied on the device.
This is shown as a warning note itself when you configure Bitlocker policy in Intune portal.
If you do not decrypt the volume prior to custom Bitlocker policy deployment, the policy will always result in failure state.
If you wish, you can disable Device Encryption by using Command Prompt (
Shift + F10) during the initial phases of OOBE to make the necessary changes to the registry
- Key Path:
Just a few days back, the same was achieved via Intune by deploying a custom OMA-URI profile (in case you are doing AADJ from OOBE and have a different Bitlocker policy configured) since this is not available via native UI.
Name: PreventAutomaticDeviceEncryptionForAzureADJoinedDevices OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Security/PreventAutomaticDeviceEncryptionForAzureADJoinedDevices Data Type: Integer Value: 1
But as of today, Intune has introduced a native UI settings to control the automatic encryption behavior on the devices.
Device Encryption is a good feature, especially for devices running Windows 10 Home edition since this version do not get the standard Bitlocker toolset for user to manually encrypt the device.
For Enterprise, if in your environment all devices are HSTI compliant, it helps to reduce administrative burden by ensuring that the Windows 10 devices are automatically encrypted and protected as they are provisioned without any administrative cost involved.
Well, that was all for today. In my next post on this series of
#bitlockerunlockedwithjoy I will be taking you through Bitlocker Drive Encryption – the fully featured Bitlocker with which we as admins work with.
Till then, keep reading, keep learning!