mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-20 21:03:42 +00:00
updates
This commit is contained in:
@ -56,15 +56,15 @@ Companies that image their own computers using Configuration Manager can use an
|
||||
|
||||
## Manage Microsoft Entra joined devices
|
||||
|
||||
Devices joined to Azure AD are managed using Mobile Device Management (MDM) policy from an MDM solution such as Microsoft Intune. Prior to Windows 10, version 1809, only local administrators can enable BitLocker via Intune policy. Intune can enable BitLocker for standard users. [Device Encryption](index.md#device-encryption) status can be queried from managed machines via the [Policy Configuration Settings Provider (CSP)](/windows/client-management/mdm/policy-configuration-service-provider/), which reports on whether BitLocker Device Encryption is enabled on the device. Compliance with BitLocker Device Encryption policy can be a requirement for [Conditional Access](https://www.microsoft.com/cloud-platform/conditional-access/) to services like Exchange Online and SharePoint Online.
|
||||
Devices joined to Azure AD are managed using Mobile Device Management (MDM) policy from an MDM solution such as Microsoft Intune. Prior to Windows 10, version 1809, only local administrators can enable BitLocker via Intune policy. Intune can enable BitLocker for standard users. [Device encryption](index.md#device-encryption) status can be queried from managed machines via the [Policy Configuration Settings Provider (CSP)](/windows/client-management/mdm/policy-configuration-service-provider/), which reports on whether device encryption is enabled on the device. Compliance with device encryption policy can be a requirement for [Conditional Access](https://www.microsoft.com/cloud-platform/conditional-access/) to services like Exchange Online and SharePoint Online.
|
||||
|
||||
The enablement of BitLocker can be triggered over MDM either by the [Policy CSP](/windows/client-management/mdm/policy-configuration-service-provider/) or the [BitLocker CSP](/windows/client-management/mdm/bitlocker-csp/). The BitLocker CSP adds policy options that go beyond ensuring that encryption has occurred.
|
||||
|
||||
For hardware that is compliant with Modern Standby and HSTI, when using either of these features, [Device Encryption](index.md#device-encryption) is automatically turned on whenever the user joins a device to Azure AD. Azure AD provides a portal where recovery keys are also backed up, so users can retrieve their own recovery key for self-service, if necessary.
|
||||
For hardware that is compliant with Modern Standby and HSTI, when using either of these features, [device encryption](index.md#device-encryption) is automatically turned on whenever the user joins a device to Azure AD. Azure AD provides a portal where recovery keys are also backed up, so users can retrieve their own recovery key for self-service, if necessary.
|
||||
|
||||
## Manage Microsoft Entra registered devices
|
||||
|
||||
For Windows devices that are enrolled using **Connect to work or school account**, BitLocker Device Encryption is managed over MDM, the same as Microsoft Entra ID joined devices.
|
||||
For Windows devices that are enrolled using **Connect to work or school account**, device encryption is managed over MDM, the same as Microsoft Entra ID joined devices.
|
||||
|
||||
## Manage servers
|
||||
|
||||
|
@ -7,14 +7,14 @@ ms.date: 10/09/2023
|
||||
|
||||
# Device encryption
|
||||
|
||||
*Device encryption* is a Windows feature that provides a simple way for some devices to enable BitLocker encryption automatically. Device encryption is available on all Windows versions, including Home edition, but requires a device to meet either [Modern Standby](/windows-hardware/design/device-experiences/modern-standby) or HSTI security requirements, and have no externally accessible ports that allow DMA access.
|
||||
*Device encryption* is a Windows feature that provides a simple way for some devices to enable BitLocker encryption automatically. Device encryption is available on all Windows versions, including Home edition, and it requires a device to meet either [Modern Standby](/windows-hardware/design/device-experiences/modern-standby) or HSTI security requirements, and have no externally accessible ports that allow DMA access.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Device encryption encrypts only the OS drive and fixed drives, it doesn't encrypt external/USB drives
|
||||
> Device encryption encrypts only the OS drive and fixed drives, it doesn't encrypt external/USB drives.
|
||||
|
||||
Unlike a standard BitLocker implementation, device encryption is enabled automatically so that the device is always protected. When a clean installation of Windows is completed and the out-of-box experience is finished, the device is prepared for first use. As part of this preparation, device encryption is initialized on the OS drive and fixed data drives on the computer with a clear key that is the equivalent of standard BitLocker suspended state. In this state, the drive is shown with a warning icon in Windows Explorer. The yellow warning icon is removed after the TPM protector is created and the recovery key is backed up.
|
||||
|
||||
- If the device is Microsoft Entra joined or Active Directory domain joined, the clear key is removed once the the recovery key is successfully backed up to Microsoft Entra ID or Active Directory Domain Services (AD DS). The following policy settings must be enabled for the recovery key to be backed up: [Choose how BitLocker-protected operating system drives can be recovered](policy-settings.md?tabs=os#choose-how-bitlocker-protected-operating-system-drives-can-be-recovered)
|
||||
- If the device is Microsoft Entra joined or Active Directory domain joined, the clear key is removed once the recovery key is successfully backed up to Microsoft Entra ID or Active Directory Domain Services (AD DS). The following policy settings must be enabled for the recovery key to be backed up: [Choose how BitLocker-protected operating system drives can be recovered](policy-settings.md?tabs=os#choose-how-bitlocker-protected-operating-system-drives-can-be-recovered)
|
||||
- For Microsoft Entra joined devices: the recovery password is created automatically when the user authenticates to Microsoft Entra ID, then the recovery key is backed up to Microsoft Entra ID, the TPM protector is created, and the clear key is removed
|
||||
- For AD DS joined devices: the recovery password is created automatically when the computer joins the domain. The recovery key is then backed up to AD DS, the TPM protector is created, and the clear key is removed
|
||||
- If the device isn't Microsoft Entra joined or Active Directory domain joined, a Microsoft account with administrative privileges on the device is required. When the administrator uses a Microsoft account to sign in, the clear key is removed, a recovery key is uploaded to the online Microsoft account, and a TPM protector is created. Should a device require the recovery key, the user is guided to use an alternate device and navigate to a recovery key access URL to retrieve the recovery key by using their Microsoft account credentials
|
||||
@ -22,18 +22,26 @@ Unlike a standard BitLocker implementation, device encryption is enabled automat
|
||||
|
||||
If a device doesn't initially qualify for device encryption, but then a change is made that causes the device to qualify (for example, turn *Secure Boot* on), device encryption enables BitLocker automatically as soon as it detects it (unless device encryption is disabled).
|
||||
|
||||
You can check whether a device meets requirements for device encryption in the System Information app (msinfo32.exe). If the device meets the requirements, System Information shows a device encryption Support line that reads: **Meets prerequisites**.
|
||||
You can check whether a device meets requirements for device encryption in the System Information app (`msinfo32.exe`). If the device meets the requirements, System Information shows a line that reads:
|
||||
|
||||
|Item|Value|
|
||||
|-|-|
|
||||
|Device Encryption Support | Meets prerequisites|
|
||||
|
||||
> [!NOTE]
|
||||
> Device encryption uses the `XTS-AES 128-bit` encryption method. If a different encryption method and/or cipher strength is needed but the device is already encrypted, it must first be decrypted before the new encryption method and/or cipher strength can be applied. After the device is decrypted, you can apply different BitLocker settings.
|
||||
|
||||
## Difference between BitLocker and device encryption
|
||||
|
||||
- Device encryption turns BitLocker on automatically on device encryption-qualifying devices, with the recovery key automatically backed up to Microsoft Entra ID, AD DS, or the user's Microsoft account
|
||||
- Device encryption turns on BitLocker automatically on device encryption-qualifying devices, with the recovery key automatically backed up to Microsoft Entra ID, AD DS, or the user's Microsoft account
|
||||
- Device encryption adds a device encryption setting in the Settings app, which can be used to turn device encryption on or off
|
||||
- The Settings UI will not show device encryption enabled until encryption is complete
|
||||
> [!NOTE]
|
||||
> If device encryption is turned off, it will no longer automatically enable itself in the future. The user must enable it manually in Settings
|
||||
- The Settings UI doesn't show device encryption enabled until encryption is complete
|
||||
|
||||
:::image type="content" source="images/settings-device-encryption.png" alt-text="Screenshot of the Settings app showing the device encryption panel." border="False":::
|
||||
|
||||
> [!NOTE]
|
||||
> If device encryption is turned off, it will no longer automatically enable itself in the future. The user must enable it manually in Settings
|
||||
|
||||
## Disable device encryption
|
||||
|
||||
It's recommended to keep device encryption on for any systems that support it. However, you can prevent the automatic device encryption process by changing the following registry setting:
|
||||
@ -41,6 +49,3 @@ It's recommended to keep device encryption on for any systems that support it. H
|
||||
| Path|Name|Type|Value|
|
||||
|-|-|-|-|
|
||||
| `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BitLocker`| `PreventDeviceEncryption`|REG_DWORD|0x1|
|
||||
|
||||
> [!NOTE]
|
||||
> Device encryption uses the XTS-AES 128-bit encryption method. If a different encryption method and/or cipher strength is needed but the device is already encrypted, it must first be decrypted before the new encryption method and/or cipher strength can be applied. After the device is decrypted, you can apply different BitLocker settings.
|
||||
|
@ -53,11 +53,11 @@ BitLocker has the following requirements:
|
||||
> [!NOTE]
|
||||
> When installing the BitLocker optional component on a server, the *Enhanced Storage* feature must be installed. The feature is used to support hardware encrypted drives.
|
||||
|
||||
## Device Encryption
|
||||
## Device encryption
|
||||
|
||||
*Device Encryption* is a security feature that provides a simple way for some devices to enable BitLocker encryption automatically. Device Encryption requires a device to meet either [Modern Standby](/windows-hardware/design/device-experiences/modern-standby) or HSTI security requirements, and have no externally accessible ports that allow DMA access.
|
||||
*Device encryption* is a security feature that provides a simple way for some devices to enable BitLocker encryption automatically. Device encryption requires a device to meet either [Modern Standby](/windows-hardware/design/device-experiences/modern-standby) or HSTI security requirements, and have no externally accessible ports that allow DMA access.
|
||||
|
||||
To learn more about Device Encryption, review the [Device Encryption](device-encryption.md) documentation.
|
||||
To learn more about device encryption, review the [device encryption](device-encryption.md) documentation.
|
||||
|
||||
[!INCLUDE [bitlocker](../../../../../includes/licensing/bitlocker-enablement.md)]
|
||||
|
||||
|
@ -28,7 +28,7 @@ BitLocker recovery is the process by which access to a BitLocker-protected drive
|
||||
|
||||
The following list provides examples of specific events that will cause BitLocker to enter recovery mode when attempting to start the operating system drive:
|
||||
|
||||
- On devices that use BitLocker drive encryption or [Device Encryption](index.md#device-encryption), when an attack is detected the device will reboot and enter into BitLocker recovery mode. To take advantage of this functionality, administrators can set the **Interactive logon: Machine account lockout threshold** Group Policy setting located in **Computer Configuration** > **Windows Settings** > **Security Settings** > **Local Policies** > **Security Options** in the Local Group Policy Editor. Or they can use the **MaxFailedPasswordAttempts** policy of [Exchange ActiveSync](/Exchange/clients/exchange-activesync/exchange-activesync) (also configurable through [Microsoft Intune](/mem/intune)), to limit the number of failed password attempts before the device goes into Device Lockout.
|
||||
- On devices that use BitLocker drive encryption or [device encryption](index.md#device-encryption), when an attack is detected the device will reboot and enter into BitLocker recovery mode. To take advantage of this functionality, administrators can set the **Interactive logon: Machine account lockout threshold** Group Policy setting located in **Computer Configuration** > **Windows Settings** > **Security Settings** > **Local Policies** > **Security Options** in the Local Group Policy Editor. Or they can use the **MaxFailedPasswordAttempts** policy of [Exchange ActiveSync](/Exchange/clients/exchange-activesync/exchange-activesync) (also configurable through [Microsoft Intune](/mem/intune)), to limit the number of failed password attempts before the device goes into Device Lockout.
|
||||
|
||||
- On devices with TPM 1.2, changing the BIOS or firmware boot device order causes BitLocker recovery. However, devices with TPM 2.0 don't start BitLocker recovery in this case. TPM 2.0 doesn't consider a firmware change of boot device order as a security threat because the OS Boot Loader isn't compromised.
|
||||
|
||||
@ -301,9 +301,9 @@ If the USB flash drive that contains the startup key has been lost, then drive m
|
||||
|
||||
This error occurs if the firmware is updated. As a best practice, BitLocker should be suspended before making changes to the firmware. Protection should then be resumed after the firmware update has completed. Suspending BitLocker prevents the computer from going into recovery mode. However, if changes were made when BitLocker protection was on, the recovery password can be used to unlock the drive and the platform validation profile will be updated so that recovery won't occur the next time.
|
||||
|
||||
## Windows RE and Device Encryption
|
||||
## Windows RE and device encryption
|
||||
|
||||
Windows Recovery Environment (RE) can be used to recover access to a drive protected by [Device Encryption](index.md#device-encryption). If a device is unable to boot after two failures, Startup Repair automatically starts. When Startup Repair is launched automatically due to boot failures, it executes only operating system and driver file repairs if the boot logs or any available crash dump points to a specific corrupted file. Devices that include firmware to support specific TPM measurements for *PCR 7*, the TPM can validate that Windows RE is a trusted operating environment and unlock any BitLocker-protected drives if Windows RE hasn't been modified. If the Windows RE environment has been modified, for example, the TPM has been disabled, the drives stay locked until the BitLocker recovery key is provided. If Startup Repair isn't able to run automatically from the PC and instead, Windows RE is manually started from a repair disk, the BitLocker recovery key must be provided to unlock the BitLocker-protected drives.
|
||||
Windows Recovery Environment (RE) can be used to recover access to a drive protected by [device encryption](index.md#device-encryption). If a device is unable to boot after two failures, Startup Repair automatically starts. When Startup Repair is launched automatically due to boot failures, it executes only operating system and driver file repairs if the boot logs or any available crash dump points to a specific corrupted file. Devices that include firmware to support specific TPM measurements for *PCR 7*, the TPM can validate that Windows RE is a trusted operating environment and unlock any BitLocker-protected drives if Windows RE hasn't been modified. If the Windows RE environment has been modified, for example, the TPM has been disabled, the drives stay locked until the BitLocker recovery key is provided. If Startup Repair isn't able to run automatically from the PC and instead, Windows RE is manually started from a repair disk, the BitLocker recovery key must be provided to unlock the BitLocker-protected drives.
|
||||
|
||||
Windows RE will also ask for a BitLocker recovery key when a **Remove everything** reset from Windows RE is started on a device that uses **TPM + PIN** or **Password for OS drive** protectors. If BitLocker recovery is started on a keyboardless device with TPM-only protection, Windows RE, not the boot manager, will ask for the BitLocker recovery key. After the key is entered, Windows RE troubleshooting tools can be accessed, or Windows can be started normally.
|
||||
|
||||
|
@ -5,7 +5,7 @@ items:
|
||||
href: countermeasures.md
|
||||
- name: BitLocker planning guide
|
||||
href: planning-guide.md
|
||||
- name: Device Encryption
|
||||
- name: Device encryption
|
||||
href: device-encryption.md
|
||||
- name: How-to guides
|
||||
items:
|
||||
|
Reference in New Issue
Block a user