The following table lists the BitLocker policies applicable to all drive types, indicating if they're applicable via configuration service provider (CSP) and/or group policy (GPO). Select the policy name for more details.
Allow standard user encryption
With this policy you can enforce the Require device encryption policy for scenarios where the policy is applied while the current logged-on user doesn't have administrative rights.
Choose default folder for recovery password
Specify the default path that is displayed when the BitLocker Drive Encryption setup wizard prompts the user to enter the location of a folder in which to save the recovery password. You can specify either a fully qualified path or include the target computer's environment variables in the path:
- If the path isn't valid, the BitLocker setup wizard displays the computer's top-level folder view
- If you disable or don't configure this policy setting, the BitLocker setup wizard displays the computer's top-level folder view when the user chooses the option to save the recovery password in a folder
Note
This policy setting does not prevent the user from saving the recovery password in another folder.
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption |
Choose drive encryption method and cipher strength
With this policy, you can configure an encryption algorithm and key cipher strength for fixed data drives, operating system drives, and removable data drives individually.
Recommended settings: XTS-AES algorithm for all drives. The choice of key size, 128 bit or 256 bit depends on the performance of the device. For more performant hard drives and CPU, choose 256-bit key, for less performant ones use 128.
Important
Key size might be required by regulators or industry.
If you disable or don't configure this policy setting, BitLocker uses the default encryption method of XTS-AES 128-bit.
Note
This policy doesn't apply to encrypted drives. Encrypted drives utilize their own algorithm, which is set by the drive during partitioning.
|
Path |
| CSP |
./Device/Vendor/MSFT/BitLocker/EncryptionMethodByDriveType |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption |
With this policy you can configure a numeric recovery password rotation upon use for OS and fixed drives on Microsoft Entra joined and Microsoft Entra hybrid joined devices.
Possible values are:
0: numeric recovery password rotation is turned off1: numeric recovery password rotation upon use is on for Microsoft Entra joined devices. This is also the default value2: numeric recovery password rotation upon use is on for both Microsoft Entra joined devices and Microsoft Entra hybrid joined devices
Note
The Policy is effective only when Micropsoft Entra ID or Active Directory backup for recovery password is configured to required
- For OS drive: enable Do not enable BitLocker until recovery information is stored to AD DS for operating system drives
- For fixed drives: enable "Do not enable BitLocker until recovery information is stored to AD DS for fixed data drives
Disable new DMA devices when this computer is locked
When enabled, this policy setting blocks direct memory access (DMA) for all hot pluggable PCI ports until a user signs into Windows.
Once a user signs in, Windows enumerates the PCI devices connected to the host Thunderbolt PCI ports. Every time the user locks the device, DMA is blocked on hot plug Thunderbolt PCI ports with no children devices, until the user signs in again.
Devices that were already enumerated when the device was unlocked will continue to function until unplugged, or the system is rebooted or hibernated.
This policy setting is only enforced when BitLocker or device encryption is enabled.
Important
This policy is not compatible with Kernel DMA Protection. It's recommended to disable this policy if the system supports Kernel DMA Protection, as Kernel DMA Protection provides higher security for the system. For more information about Kernel DMA Protection, see Kernel DMA Protection.
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption |
Prevent memory overwrite on restart
This policy setting is used to control whether the computer's memory is overwritten when the device restarts. BitLocker secrets include key material used to encrypt data.
- If you enable this policy setting, memory isn't overwritten when the computer restarts. Preventing memory overwrite may improve restart performance but increases the risk of exposing BitLocker secrets.
- If you disable or do not configure this policy setting, BitLocker secrets are removed from memory when the computer restarts.
Note
This policy setting applies only when BitLocker protection is enabled.
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption |
Provide the unique identifiers for your organization
This policy setting allows you to associate unique organizational identifiers to a drive that is encrypted with BitLocker. The identifiers are stored as the identification field and allowed identification field:
- The identification field allows you to associate a unique organizational identifier to BitLocker-protected drives. This identifier is automatically added to new BitLocker-protected drives and can be updated on existing BitLocker-protected drives using the BitLocker Drive Encryption: Configuration Tool (
manage-bde.exe)
- The allowed identification field is used in combination with the Deny write access to removable drives not protected by BitLocker policy setting to help control the use of removable drives in your organization. It's a comma separated list of identification fields from your organization or other external organizations. You can configure the identification fields on existing drives by using
manage-bde.exe.
If you enable this policy setting, you can configure the identification field on the BitLocker-protected drive and any allowed identification field used by your organization. When a BitLocker-protected drive is mounted on another BitLocker-enabled device, the identification field and allowed identification field are used to determine whether the drive is from a different organization.
If you disable or don't configure this policy setting, the identification field is not required.
Important
Identification fields are required for management of certificate-based data recovery agents on BitLocker-protected drives. BitLocker only manages and updates certificate-based data recovery agents when the identification field is present on a drive and is identical to the value configured on the device. The identification field can be any value of 260 characters or fewer.
|
Path |
| CSP |
./Device/Vendor/MSFT/BitLocker/IdentificationField |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption |
Require device encryption
This policy setting determines whether BitLocker is required:
- If enabled, encryption is triggered on all drives silently or non-silently based on Allow warning for other disk encryption policy
- If disabled, BitLocker isn't turned off for the system drive, but it stops prompting the user to turn BitLocker on.
Encryptable fixed data volumes are treated similarly to OS volumes, but they must meet other criteria to be encryptable:
- It must not be a dynamic volume
- It must not be a recovery partition
- It must not be a hidden volume
- It must not be a system partition
- It must not be backed by virtual storage
- It must not have a reference in the BCD store
Validate smart card certificate usage rule compliance
This policy setting is used to determine which certificate to use with BitLocker by associating an object identifier (OID) from a smart card certificate to a BitLocker-protected drive. The object identifier is specified in the enhanced key usage (EKU) of a certificate.
BitLocker can identify which certificates may be used to authenticate a user certificate to a BitLocker-protected drive by matching the object identifier in the certificate with the object identifier that is defined by this policy setting. Default OID is 1.3.6.1.4.1.311.67.1.1.
If you enable this policy setting, the object identifier specified in the Object identifier field must match the object identifier in the smart card certificate. If you disable or don't configure this policy setting, the default OID is used.
Note
BitLocker doesn't require that a certificate have an EKU attribute; however, if one is configured for the certificate, it must be set to an object identifier that matches the object identifier configured for BitLocker.
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption |
Allow devices compliant with InstantGo or HSTI to opt out of preboot PIN
This policy setting allows users on devices that are compliant with InstantGo or Microsoft Hardware Security Test Interface (HSTI) to not have a PIN for preboot authentication.
The policy overrides the Require startup PIN with TPM and Require startup key and PIN with TPM options of the Require additional authentication at startup policy on compliant hardware.
- If you enable this policy setting, users on InstantGo and HSTI compliant devices can turn on BitLocker without preboot authentication
- If the policy is disabled or not configured, the options of Require additional authentication at startup policy apply
Allow enhanced PINs for startup
This setting permits the use of enhanced PINs when an unlock method that includes a PIN is used.
Enhanced startup PINs permit the use of characters (including uppercase and lowercase letters, symbols, numbers, and spaces).
Important
Not all computers support enhanced PIN characters in the preboot environment. It's strongly recommended that users perform a system check during the BitLocker setup to verify that enhanced PIN characters can be used.
|
Path |
| CSP |
./Device/Vendor/MSFT/BitLocker/SystemDrivesEnhancedPIN |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives |
Allow network unlock at startup
This policy setting controls whether a BitLocker-protected device that is connected to a trusted wired Local Area Network (LAN) can create and use Network Key Protectors on TPM-enabled computers to automatically unlock the operating system drive when the computer is started.
If you enable this policy, devices configured with a BitLocker Network Unlock certificate can create and use Network Key Protectors. To use a Network Key Protector to unlock the computer, both the computer and the BitLocker Drive Encryption Network Unlock server must be provisioned with a Network Unlock certificate. The Network Unlock certificate is used to create Network Key Protectors, and protects the information exchanged with the server to unlock the computer.
The Group Policy setting Computer Configuration > Windows Settings > Security Settings > Public Key Policies > BitLocker Drive Encryption Network Unlock Certificate can be used on the domain controller to distribute this certificate to computers in the organization. This unlock method uses the TPM on the computer, so computers that don't have a TPM can't create Network Key Protectors to automatically unlock with Network Unlock.
If you disable or don't configure this policy setting, BitLocker clients won't be able to create and use Network Key Protectors.
Note
For reliability and security, computers should also have a TPM startup PIN that can be used when the computer is disconnected from the wired network or the server at startup.
For more information about Network Unlock feature, see BitLocker: How to enable Network Unlock
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives |
Allow Secure Boot for integrity validation
This policy setting allows you to configure whether Secure Boot is allowed as the platform integrity provider for BitLocker operating system drives.
Secure Boot ensures that the device's preboot environment only loads firmware that is digitally signed by authorized software publishers.
- If you enable or don't configure this policy setting, BitLocker uses Secure Boot for platform integrity if the platform is capable of Secure Boot-based integrity validation
- If you disable this policy setting, BitLocker uses legacy platform integrity validation, even on systems capable of Secure Boot-based integrity validation
When this policy is enabled and the hardware is capable of using Secure Boot for BitLocker scenarios, the Use enhanced Boot Configuration Data validation profile policy setting is ignored and Secure Boot verifies BCD settings according to the Secure Boot policy setting, which is configured separately from BitLocker.
Warning
Disabling this policy might result in BitLocker recovery when manufacturer-specific firmware is updated. If this policy is disabled, suspend BitLocker prior to applying firmware updates.
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives |
Allow warning for other disk encryption
With this policy you can disable all notification for encryption, warning prompt for other disk encryption, and turn on encryption silently.
Important
This policy applies to Microsoft Entra joined devices only.
This policy takes effect only if Require device encryption policy is enabled.
Warning
When you enable BitLocker on a device with non-Microsoft encryption, it may render the device unusable and will require reinstallation of Windows.
The expected values for this policy are:
- Enabled (default): warning prompt and encryption notification is allowed
- Disabled: warning prompt and encryption notification are suppressed. Windows will attempt to silently enable BitLocker
Note
When you disable the warning prompt, the OS drive's recovery key will back up to the user's Microsoft Entra ID account. When you allow the warning prompt, the user who receives the prompt can select where to back up the OS drive's recovery key.
The endpoint for a fixed data drive's backup is chosen in the following order:
- The user's Windows Server Active Directory Domain Services account
- The user's Microsoft Entra ID account
- The user's personal OneDrive (MDM/MAM only)
Encryption will wait until one of these three locations backs up successfully.
Choose how BitLocker-protected operating system drives can be recovered
This policy setting allows you to control how BitLocker-protected operating system drives are recovered in the absence of the required startup key information. If you enable this policy setting, you can control the methods available to users to recover data from BitLocker-protected operating system drives. Here are the available options:
- Allow certificate-based data recovery agent: specify whether a data recovery agent can be used with BitLocker-protected OS drives. Before a data recovery agent can be used, it must be added from the Public Key Policies item in either the Group Policy Management Console or the Local Group Policy Editor
- Configure user storage of BitLocker recovery information: select whether users are allowed, required, or not allowed to generate a 48-digit recovery password or a 256-bit recovery key
- Omit recovery options from the BitLocker setup wizard: prevent users from specifying recovery options when they turn on BitLocker for a drive. This means that users won't be able to specify which recovery option to use when they turn on BitLocker. BitLocker recovery options for the drive are determined by the policy setting
- Save BitLocker recovery information to Active Directory Domain Services: choose which BitLocker recovery information to store in AD DS for operating system drives. If you select Backup recovery password and key package, both the BitLocker recovery password and key package are stored in AD DS. Storing the key package supports recovering data from a drive that has been physically corrupted. If you select Backup recovery password only, only the recovery password is stored in AD DS
- Do not enable BitLocker until recovery information is stored in AD DS for operating system drives: prevents users from enabling BitLocker unless the device is connected to the domain and the backup of BitLocker recovery information to AD DS succeeds. When using this option, a recovery password is automatically generated.
If this policy setting is disabled or not configured, the default recovery options are supported for BitLocker recovery. By default a DRA is allowed, the recovery options can be specified by the user including the recovery password and recovery key, and recovery information is not backed up to AD DS.
For Microsoft Entra hybrid joined devices, the BitLocker recovery password is backed up to both Active Directory and Entra ID.
|
Path |
| CSP |
./Device/Vendor/MSFT/BitLocker/SystemDrivesRecoveryOptions |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives |
This policy configures a minimum length for a Trusted Platform Module (TPM) startup PIN. The startup PIN must have a minimum length of 4 digits and can have a maximum length of 20 digits.
If you enable this policy setting, you can require a minimum number of digits to be used when setting the startup PIN.
If you disable or do not configure this policy setting, users can configure a startup PIN of any length between 6 and 20 digits.
The TPM can be configured to use Dictionary Attack Prevention parameters (lockout threshold and lockout duration to control how many failed authorizations attempts are allowed before the TPM is locked out, and how much time must elapse before another attempt can be made.
The Dictionary Attack Prevention Parameters provide a way to balance security needs with usability. For example, when BitLocker is used with a TPM + PIN configuration, the number of PIN guesses is limited over time. A TPM 2.0 in this example could be configured to allow only 32 PIN guesses immediately, and then only one more guess every two hours. This number of attempts totals to a maximum of about 4415 guesses per year. If the PIN is four digits, all 9999 possible PIN combinations could be attempted in a little over two years.
Tip
Increasing the PIN length requires a greater number of guesses for an attacker. In that case, the lockout duration between each guess can be shortened to allow legitimate users to retry a failed attempt sooner, while maintaining a similar level of protection.
Note
If minimum PIN length is set below 6 digits, Windows will attempt to update the TPM 2.0 lockout period to be greater than the default when a PIN is changed. If successful, Windows will only reset the TPM lockout period back to default if the TPM is reset.
|
Path |
| CSP |
./Device/Vendor/MSFT/BitLocker/SystemDrivesMinimumPINLength |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives |
This policy setting is used to configure the recovery message and to replace the existing URL that is displayed on the preboot recovery screen when the OS drive is locked.
- If you select the Use default recovery message and URL option, the default BitLocker recovery message and URL are displayed in the preboot key recovery screen. If you have previously configured a custom recovery message or URL and want to revert to the default message, you must keep the policy enabled and select the Use default recovery message and URL option
- If you select the Use custom recovery message option, the message you add to the Custom recovery message option text box is displayed in the preboot key recovery screen. If a recovery URL is available, include it in the message
- If you select the Use custom recovery URL option, the URL you add to the Custom recovery URL option text box replaces the default URL in the default recovery message, which is displayed in the preboot key recovery screen
Note
Not all characters and languages are supported in pre-boot. It is strongly recommended that you test that the characters you use for the custom message or URL appear correctly on the pre-boot recovery screen.
For more information about the BitLocker preboot recovery screen, see Preboot recovery screen.
|
Path |
| CSP |
./Device/Vendor/MSFT/BitLocker/SystemDrivesRecoveryMessage |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives |
This policy setting determines what values the TPM measures when it validates early boot components before it unlocks an operating system drive on a computer with a BIOS configuration or with UEFI firmware that has the Compatibility Support Module (CSM) enabled.
- When enabled, the boot components that the TPM validates before unlocking access to the BitLocker-encrypted operating system drive can be configured. If any of these components change while BitLocker protection is in effect, then the TPM doesn't release the encryption key to unlock the drive. Instead, the computer displays the BitLocker Recovery console and requires that the recovery password or the recovery key is provided to unlock the drive.
- When disabled or not configured, the TPM uses the default platform validation profile or the platform validation profile that is specified by the setup script.
This policy setting doesn't apply if the computer doesn't have a compatible TPM or if BitLocker has already been turned on with TPM protection.
Important
This Group Policy setting only applies to computers with BIOS configurations or to computers with UEFI firmware with the CSM enabled. Computers that use a native UEFI firmware configuration store different values in the Platform Configuration Registers (PCRs). Use the Configure TPM platform validation profile for native UEFI firmware configurations policy setting to configure the TPM PCR profile for computers that use native UEFI firmware.
A platform validation profile consists of a set of PCR indices that range from 0 to 23. Each PCR index represents a specific measurement that the TPM validates during early boot. The default platform validation profile secures the encryption key against changes to the following PCRs:
| PCR |
Description |
| PCR 0 |
Core root-of-trust for measurement, BIOS, and platform extensions |
| PCR 2 |
Option ROM code |
| PCR 4 |
Master Boot Record (MBR) code |
| PCR 8 |
NTFS boot sector |
| PCR 9 |
NTFS boot block |
| PCR 10 |
Boot manager |
| PCR 11 |
BitLocker access control |
Note
Changing from the default platform validation profile affects the security and manageability of a computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs.
The following list identifies all of the available PCRs:
| PCR |
Description |
| PCR 0 |
Core root-of-trust for measurement, BIOS, and platform extensions |
| PCR 1 |
Platform and motherboard configuration and data. |
| PCR 2 |
Option ROM code |
| PCR 3 |
Option ROM data and configuration |
| PCR 4 |
Master Boot Record (MBR) code |
| PCR 5 |
Master Boot Record (MBR) partition table |
| PCR 6 |
State transition and wake events |
| PCR 7 |
Computer manufacturer-specific |
| PCR 8 |
NTFS boot sector |
| PCR 9 |
NTFS boot block |
| PCR 10 |
Boot manager |
| PCR 11 |
BitLocker access control |
| PCR 12-23 |
Reserved for future use |
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives |
This policy setting determines what values the TPM measures when it validates early boot components, before unlocking the OS drive on native-UEFI firmware device.
- If you enable this policy setting before turning on BitLocker, you can configure the boot components that the TPM validates before unlocking access to the BitLocker-encrypted OS drive. If any of these components change while BitLocker protection is in effect, the TPM doesn't release the encryption key to unlock the drive. The device displays the BitLocker Recovery console and requires that either the recovery password or recovery key be provided to unlock the drive
- If you disable or do not configure this policy setting, BitLocker uses the default platform validation profile for the available hardware, or the platform validation profile specified by the setup script
Important
This policy setting only applies to devices with a native UEFI firmware configuration. Computers with BIOS or UEFI firmware with a Compatibility Support Module (CSM) enabled store different values in the Platform Configuration Registers (PCRs). Use the Configure TPM platform validation profile for BIOS-based firmware configurations policy setting to configure the TPM PCR profile for devices with BIOS configurations, or for devices with UEFI firmware with a CSM enabled.
A platform validation profile consists of a set of PCR indices ranging from 0 to 23. The default platform validation profile secures the encryption key against changes to the following PCRs:
| PCR |
Description |
| PCR 0 |
Core System Firmware executable code |
| PCR 2 |
Extended or pluggable executable code |
| PCR 4 |
Boot Manager |
| PCR 11 |
BitLocker access control |
Note
When Secure Boot State (PCR7) support is available, the default platform validation profile secures the encryption key using Secure Boot State (PCR 7) and the BitLocker access control (PCR 11).
The following list identifies all of the available PCRs:
| PCR |
Description |
| PCR 0 |
Core System Firmware executable code |
| PCR 1 |
Core System Firmware data |
| PCR 2 |
Extended or pluggable executable code |
| PCR 3 |
Extended or pluggable firmware data |
| PCR 4 |
Boot Manager |
| PCR 5 |
GPT/Partition Table |
| PCR 6 |
Resume from S4 and S5 Power State Events |
| PCR 7 |
Secure Boot State |
| PCR 8 |
Initialized to 0 with no Extends (reserved for future use) |
| PCR 9 |
Initialized to 0 with no Extends (reserved for future use) |
| PCR 10 |
Initialized to 0 with no Extends (reserved for future use) |
| PCR 11 |
BitLocker access control |
| PCR 12 |
Data events and highly volatile events |
| PCR 13 |
Boot Module Details |
| PCR 14 |
Boot Authorities |
| PCR 15 - 23 |
Reserved for future use |
Warning
Changing from the default platform validation profile affects the security and manageability of a device. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs.
Setting this policy with PCR 7 omitted, overrides the Allow Secure Boot for integrity validation policy, preventing BitLocker from using Secure Boot for platform or Boot Configuration Data (BCD) integrity validation.
Setting this policy may result in BitLocker recovery when firmware is updated. If you set this policy to include PCR 0, suspend BitLocker prior to applying firmware updates. It is recommended to not configure this policy, to allow Windows to select the PCR profile for the best combination of security and usability based on the available hardware on each device.
PCR 7 measures the state of Secure Boot. With PCR 7, BitLocker can use Secure Boot for integrity validation. Secure Boot ensures that the computer's preboot environment loads only firmware that is digitally signed by authorized software publishers. PCR 7 measurements indicate whether Secure Boot is on, and which keys are trusted on the platform. If Secure Boot is on and the firmware measures PCR 7 correctly per the UEFI specification, BitLocker can bind to this information rather than to PCRs 0, 2, and 4, which have the measurements of the exact firmware and Bootmgr images loaded. This process reduces the likelihood of BitLocker starting in recovery mode as a result of firmware and image updates, and it provides with greater flexibility to manage the preboot configuration.
PCR 7 measurements must follow the guidance that is described in Appendix A Trusted Execution Environment EFI Protocol.
PCR 7 measurements are a mandatory logo requirement for systems that support Modern Standby (also known as Always On, Always Connected PCs). On such systems, if the TPM with PCR 7 measurement and secure boot are correctly configured, BitLocker binds to PCR 7 and PCR 11 by default.
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives |
This policy setting allows you to manage BitLocker's use of hardware-based encryption on operating system drives and specify which encryption algorithms it can use with hardware-based encryption. Using hardware-based encryption can improve performance of drive operations that involve frequent reading or writing of data to the drive.
If you enable this policy setting, you can specify options that control whether BitLocker software-based encryption is used instead of hardware-based encryption on devices that don't support hardware-based encryption. You can also specify if you want to restrict the encryption algorithms and cipher suites used with hardware-based encryption.
If you disable this policy setting, BitLocker can't use hardware-based encryption with operating system drives, and BitLocker software-based encryption will be used by default when the drive is encrypted.
If you do not configure this policy setting, BitLocker will use software-based encryption, irrespective of hardware-based encryption availability.
Note
The Choose drive encryption method and cipher strength policy setting doesn't apply to hardware-based encryption. The encryption algorithm used by hardware-based encryption is set when the drive is partitioned. By default, BitLocker uses the algorithm configured on the drive to encrypt the drive.
The Restrict encryption algorithms and cipher suites allowed for hardware-based encryption option enables you to restrict the encryption algorithms that BitLocker can use with hardware encryption. If the algorithm set for the drive isn't available, BitLocker disables the use of hardware-based encryption. Encryption algorithms are specified by object identifiers (OID). For example:
- AES 128 in CBC mode OID:
2.16.840.1.101.3.4.1.2
- AES 256 in CBC mode OID:
2.16.840.1.101.3.4.1.42
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives |
This policy setting specifies the constraints for passwords used to unlock BitLocker-protected operating system drives. If non-TPM protectors are allowed on operating system drives, you can provision a password, enforce complexity requirements, and configure a minimum length.
Important
For the complexity requirement setting to be effective, the group policy setting Password must meet complexity requirements located in Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy, must be also enabled.
If you enable this policy setting, users can configure a password that meets the requirements you define. To enforce complexity requirements on the password, select Require complexity:
- When set to Require complexity, a connection to a domain controller is necessary when BitLocker is enabled to validate the complexity the password
- When set to Allow complexity, a connection to a domain controller is attempted to validate that the complexity adheres to the rules set by the policy. If no domain controllers are found, the password is accepted regardless of actual password complexity and the drive will be encrypted using that password as a protector
- When set to Do not allow complexity, password complexity isn't validated
Passwords must be at least eight characters. To configure a greater minimum length for the password, specify the desired number of characters under Minimum password length
If you disable or don't configure this policy setting, the default length constraint of eight characters applies to operating system drive passwords, and no complexity checks occur.
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives |
Disallow standard users from changing the PIN or password
This policy allows configuration of whether standard users are allowed to change the PIN or password that is used to protect the operating system drive, if they can provide the existing PIN first.
If you enable this policy, standard users can't change BitLocker PINs or passwords.
If you disable or don't configure this policy, standard users can change BitLocker PINs and passwords.
This policy setting allows users to turn on authentication options that require user input from the preboot environment, even if the platform lacks preboot input capability. The Windows touch keyboard (such as that used by tablets) isn't available in the preboot environment where BitLocker requires additional information such as a PIN or Password.
- If you enable this policy setting, devices must have an alternative means of preboot input (such as an attached USB keyboard).
- If this policy isn't enabled, the Windows Recovery Environment must be enabled on tablets to support the entry of the BitLocker recovery password.
It's recommended that administrators enable this policy only for devices that are verified to have an alternative means of preboot input, such as attaching a USB keyboard.
When the Windows Recovery Environment (WinRE) isn't enabled and this policy isn't enabled, BitLocker can't be turned on a device that uses a touch keyboard.
If this policy setting isn't enabled, the following options in the Require additional authentication at startup policy might not be available:
- Configure TPM startup PIN: Required and Allowed
- Configure TPM startup key and PIN: Required and Allowed
- Configure use of passwords for operating system drives
Enforce drive encryption type on operating system drives
This policy setting allows you to configure the encryption type used by BitLocker Drive Encryption.
When you enable this policy setting, the encryption type option isn't offered in the BitLocker setup wizard:
- Choose full encryption to require that the entire drive be encrypted when BitLocker is turned on
- Choose used space only encryption to require that only the portion of the drive used to store data is encrypted when BitLocker is turned on
If you disable or don't configure this policy setting, the BitLocker setup wizard asks the user to select the encryption type before turning on BitLocker.
Note
Changing the encryption type has no effect if the drive is already encrypted or if encryption is in progress.
This policy is ignored when shrinking or expanding a volume, and the BitLocker driver uses the current encryption method. For example, when a drive that is using Used Space Only encryption is expanded, the new free space isn't wiped like a drive that uses Full encryption. The user could wipe the free space on a Used Space Only drive by using the following command: manage-bde.exe -w. If the volume is shrunk, no action is taken for the new free space.
|
Path |
| CSP |
./Device/Vendor/MSFT/BitLocker/SystemDrivesEncryptionType |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives |
Require additional authentication at startup
This policy setting configures whether BitLocker requires extra authentication each time the device starts.
If you enable this policy, users can configure advanced startup options in the BitLocker setup wizard.
If you disable or don't configure this policy setting, users can configure only basic options on computers with a TPM.
Note
Only one of the additional authentication options can be required at startup, otherwise a policy error occurs.
If you want to use BitLocker on a device without a TPM, select the option Allow BitLocker without a compatible TPM. In this mode, either a password or a USB drive is required for startup.
When using a startup key, the key information used to encrypt the drive is stored on the USB drive, creating a USB key. When the USB key is inserted, the access to the drive is authenticated and the drive is accessible. If the USB key is lost or unavailable, or if you have forgotten the password, then you must use one of the BitLocker recovery options to access the drive.
On a computer with a compatible TPM, four types of authentication methods can be used at startup to provide added protection for encrypted data. When the computer starts, it can use:
- TPM only
- a USB flash drive containing a startup key
- a PIN (6-digit to 20-digit)
- PIN + USB flash drive
Note
If you want to require the use of a startup PIN and a USB flash drive, you must configure BitLocker settings using the command-line tool manage-bde instead of the BitLocker Drive Encryption setup wizard.
There are four options for TPM-enabled devices:
Configure TPM startup
- Allow TPM
- Require TPM
- Don't allow TPM
Configure TPM startup PIN
- Allow startup PIN with TPM
- Require startup PIN with TPM
- Don't allow startup PIN with TPM
Configure TPM startup key
- Allow startup key with TPM
- Require startup key with TPM
- Don't allow startup key with TPM
Configure TPM startup key and PIN
- Allow TPM startup key with PIN
- Require startup key and PIN with TPM
- Don't allow TPM startup key with PIN
|
Path |
| CSP |
./Device/Vendor/MSFT/BitLocker/SystemDrivesRequireStartupAuthentication |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives |
This policy setting determines if platform validation data should refresh when Windows is started following a BitLocker recovery. A platform validation data profile consists of the values in a set of Platform Configuration Register (PCR) indices that range from 0 to 23.
If you enable this policy setting, platform validation data is refreshed when Windows is started following BitLocker recovery. This is the default behavior.
If you disable this policy setting, platform validation data won't be refreshed when Windows is started following BitLocker recovery.
For more information about the recovery process, see the BitLocker recovery overview.
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives |
Use enhanced Boot Configuration Data validation profile
This policy setting determines specific Boot Configuration Data (BCD) settings to verify during platform validation. A platform validation uses the data in the platform validation profile, which consists of a set of Platform Configuration Register (PCR) indices that range from 0 to 23.
If you don't configure this policy setting, the device will verify the default Windows BCD settings.
Note
When BitLocker is using Secure Boot for platform and BCD integrity validation, as defined by the Allow Secure Boot for integrity validation policy setting, this policy setting is ignored. The setting that controls boot debugging 0x16000010 is always validated, and it has no effect if it's included in the inclusion or exclusion list.
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives |
Choose how BitLocker-protected fixed drives can be recovered
This policy setting allows you to control how BitLocker-protected fixed data drives are recovered in the absence of the required startup key information. If you enable this policy setting, you can control the methods available to users to recover data from BitLocker-protected fixed data drives. Here are the available options:
- Allow certificate-based data recovery agent: specify whether a data recovery agent can be used with BitLocker-protected fixed data drives. Before a data recovery agent can be used, it must be added from the Public Key Policies item in either the Group Policy Management Console or the Local Group Policy Editor
- Configure user storage of BitLocker recovery information: select whether users are allowed, required, or not allowed to generate a 48-digit recovery password or a 256-bit recovery key
- Omit recovery options from the BitLocker setup wizard: prevent users from specifying recovery options when they turn on BitLocker for a drive. This means that users won't be able to specify which recovery option to use when they turn on BitLocker. BitLocker recovery options for the drive are determined by the policy setting
- Save BitLocker recovery information to Active Directory Domain Services: choose which BitLocker recovery information to store in AD DS for fixed data drives. If you select Backup recovery password and key package, both the BitLocker recovery password and key package are stored in AD DS. Storing the key package supports recovering data from a drive that has been physically corrupted. If you select Backup recovery password only, only the recovery password is stored in AD DS
- Do not enable BitLocker until recovery information is stored in AD DS for fixed data drives: prevents users from enabling BitLocker unless the device is connected to the domain and the backup of BitLocker recovery information to AD DS succeeds. When using this option, a recovery password is automatically generated.
Important
The use of recovery keys must be disallowed if the Deny write access to fixed drives not protected by BitLocker policy setting is enabled.
If this policy setting is disabled or not configured, the default recovery options are supported for BitLocker recovery. By default a DRA is allowed, the recovery options can be specified by the user including the recovery password and recovery key, and recovery information is not backed up to AD DS.
|
Path |
| CSP |
./Device/Vendor/MSFT/BitLocker/FixedDrivesRecoveryOptions |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Fixed Data Drives |
This policy setting allows you to manage BitLocker's use of hardware-based encryption on fixed data drives and specify which encryption algorithms it can use with hardware-based encryption. Using hardware-based encryption can improve performance of drive operations that involve frequent reading or writing of data to the drive.
If you enable this policy setting, you can specify options that control whether BitLocker software-based encryption is used instead of hardware-based encryption on devices that don't support hardware-based encryption. You can also specify if you want to restrict the encryption algorithms and cipher suites used with hardware-based encryption.
If you disable this policy setting, BitLocker can't use hardware-based encryption with fixed data drives, and BitLocker software-based encryption will be used by default when the drive is encrypted.
If you do not configure this policy setting, BitLocker will use software-based encryption, irrespective of hardware-based encryption availability.
Note
The Choose drive encryption method and cipher strength policy setting doesn't apply to hardware-based encryption. The encryption algorithm used by hardware-based encryption is set when the drive is partitioned. By default, BitLocker uses the algorithm configured on the drive to encrypt the drive.
The Restrict encryption algorithms and cipher suites allowed for hardware-based encryption option enables you to restrict the encryption algorithms that BitLocker can use with hardware encryption. If the algorithm set for the drive isn't available, BitLocker disables the use of hardware-based encryption. Encryption algorithms are specified by object identifiers (OID). For example:
- AES 128 in CBC mode OID:
2.16.840.1.101.3.4.1.2
- AES 256 in CBC mode OID:
2.16.840.1.101.3.4.1.42
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Fixed Data Drives |
This policy setting specifies whether a password is required to unlock BitLocker-protected fixed data drives. If you choose to allow the use of a password, you can require that a password be used, enforce complexity requirements, and configure a minimum length.
Important
For the complexity requirement setting to be effective, the group policy setting Password must meet complexity requirements located in Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy, must be also enabled.
If you enable this policy setting, users can configure a password that meets the requirements you define. To enforce complexity requirements on the password, select Require complexity:
- When set to Require complexity, a connection to a domain controller is necessary when BitLocker is enabled to validate the complexity the password
- When set to Allow complexity, a connection to a domain controller is attempted to validate that the complexity adheres to the rules set by the policy. If no domain controllers are found, the password is accepted regardless of actual password complexity and the drive will be encrypted using that password as a protector
- When set to Do not allow complexity, password complexity isn't validated
Passwords must be at least eight characters. To configure a greater minimum length for the password, specify the desired number of characters under Minimum password length
If you disable or don't configure this policy setting, the default length constraint of eight characters applies to operating system drive passwords, and no complexity checks occur.
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Fixed Data Drives |
This policy setting allows you to specify whether smart cards can be used to authenticate user access to the BitLocker-protected fixed data drives.
- If you enable this policy setting, smart cards can be used to authenticate user access to the drive
- You can require a smart card authentication by selecting the Require use of smart cards on fixed data drives option
- If you disable this policy setting, users can't use smart cards to authenticate their access to BitLocker-protected fixed data drives
- If you don't configure this policy setting, smart cards can be used to authenticate user access to a BitLocker-protected drive
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Fixed Data Drives |
Deny write access to fixed drives not protected by BitLocker
This policy setting is used to require encryption of fixed drives prior to granting write access.
If you enable this policy setting, all fixed data drives that are not BitLocker-protected will be mounted as read-only. If the drive is protected by BitLocker, it will be mounted with read and write access.
If you disable or don't configure this policy setting, all fixed data drives on the computer will be mounted with read and write access.
Note
When this policy setting is enabled, users receive Access denied error messages when they try to save data to unencrypted fixed data drives.
If the BitLocker Drive Preparation Tool BdeHdCfg.exe is executed on a computer when this policy setting is enabled, the following issues could be encountered:
- If you attempt to shrink a drive to create the system drive, the drive size is successfully reduced, and a raw partition is created. However, the raw partition isn't formatted. The following error message is displayed: The new active drive cannot be formatted. You may need to manually prepare your drive for BitLocker.
- If you attempt to use unallocated space to create the system drive, a raw partition is created. However, the raw partition isn't be formatted. The following error message is displayed: The new active drive cannot be formatted. You may need to manually prepare your drive for BitLocker.
- If you attempt to merge an existing drive into the system drive, the tool fails to copy the required boot file onto the target drive to create the system drive. The following error message is displayed: BitLocker setup failed to copy boot files. You may need to manually prepare your drive for BitLocker.
|
Path |
| CSP |
./Device/Vendor/MSFT/BitLocker/FixedDrivesRequireEncryption |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Fixed Data Drives |
Enforce drive encryption type on fixed data drives
This policy setting controls the use of BitLocker on fixed data drives.
If you enable this policy setting the encryption type that BitLocker uses to encrypt drives is defined by this policy, and the encryption type option won't be presented in the BitLocker setup wizard:
- Choose full encryption to require that the entire drive be encrypted when BitLocker is turned on
- Choose used space only encryption to require that only the portion of the drive used to store data is encrypted when BitLocker is turned on
If you disable or don't configure this policy setting, the BitLocker setup wizard asks the user to select the encryption type before turning on BitLocker.
Note
Changing the encryption type has no effect if the drive is already encrypted or if encryption is in progress.
This policy is ignored when shrinking or expanding a volume, and the BitLocker driver uses the current encryption method. For example, when a drive that is using Used Space Only encryption is expanded, the new free space isn't wiped like a drive that uses Full encryption. The user could wipe the free space on a Used Space Only drive by using the following command: manage-bde.exe -w. If the volume is shrunk, no action is taken for the new free space.
|
Path |
| CSP |
./Device/Vendor/MSFT/BitLocker/FixedDrivesEncryptionType |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Fixed Data Drives |
Choose how BitLocker-protected removable drives can be recovered
This policy setting allows you to control how BitLocker-protected removable data drives are recovered in the absence of the required startup key information. If you enable this policy setting, you can control the methods available to users to recover data from BitLocker-protected removable data drives. Here are the available options:
- Allow certificate-based data recovery agent: specify whether a data recovery agent can be used with BitLocker-protected removable data drives. Before a data recovery agent can be used, it must be added from the Public Key Policies item in either the Group Policy Management Console or the Local Group Policy Editor
- Configure user storage of BitLocker recovery information: select whether users are allowed, required, or not allowed to generate a 48-digit recovery password or a 256-bit recovery key
- Omit recovery options from the BitLocker setup wizard: prevent users from specifying recovery options when they turn on BitLocker for a drive. This means that users won't be able to specify which recovery option to use when they turn on BitLocker. BitLocker recovery options for the drive are determined by the policy setting
- Save BitLocker recovery information to Active Directory Domain Services: choose which BitLocker recovery information to store in AD DS for removable data drives. If you select Backup recovery password and key package, both the BitLocker recovery password and key package are stored in AD DS. Storing the key package supports recovering data from a drive that has been physically corrupted. If you select Backup recovery password only, only the recovery password is stored in AD DS
- Do not enable BitLocker until recovery information is stored in AD DS for removable data drives: prevents users from enabling BitLocker unless the device is connected to the domain and the backup of BitLocker recovery information to AD DS succeeds. When using this option, a recovery password is automatically generated.
Important
The use of recovery keys must be disallowed if the Deny write access to removable drives not protected by BitLocker policy setting is enabled.
If this policy setting is disabled or not configured, the default recovery options are supported for BitLocker recovery. By default a DRA is allowed, the recovery options can be specified by the user including the recovery password and recovery key, and recovery information is not backed up to AD DS.
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Removable Data Drives |
This policy setting allows you to manage BitLocker's use of hardware-based encryption on removable data drives and specify which encryption algorithms it can use with hardware-based encryption. Using hardware-based encryption can improve performance of drive operations that involve frequent reading or writing of data to the drive.
If you enable this policy setting, you can specify options that control whether BitLocker software-based encryption is used instead of hardware-based encryption on devices that don't support hardware-based encryption. You can also specify if you want to restrict the encryption algorithms and cipher suites used with hardware-based encryption.
If you disable this policy setting, BitLocker can't use hardware-based encryption with removable data drives, and BitLocker software-based encryption will be used by default when the drive is encrypted.
If you do not configure this policy setting, BitLocker will use software-based encryption, irrespective of hardware-based encryption availability.
Note
The Choose drive encryption method and cipher strength policy setting doesn't apply to hardware-based encryption. The encryption algorithm used by hardware-based encryption is set when the drive is partitioned. By default, BitLocker uses the algorithm configured on the drive to encrypt the drive.
The Restrict encryption algorithms and cipher suites allowed for hardware-based encryption option enables you to restrict the encryption algorithms that BitLocker can use with hardware encryption. If the algorithm set for the drive isn't available, BitLocker disables the use of hardware-based encryption. Encryption algorithms are specified by object identifiers (OID). For example:
- AES 128 in CBC mode OID:
2.16.840.1.101.3.4.1.2
- AES 256 in CBC mode OID:
2.16.840.1.101.3.4.1.42
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Removable Data Drives |
This policy setting specifies whether a password is required to unlock BitLocker-protected removable data drives. If you choose to allow the use of a password, you can require that a password be used, enforce complexity requirements, and configure a minimum length.
Important
For the complexity requirement setting to be effective, the group policy setting Password must meet complexity requirements located in Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy, must be also enabled.
If you enable this policy setting, users can configure a password that meets the requirements you define. To enforce complexity requirements on the password, select Require complexity:
- When set to Require complexity, a connection to a domain controller is necessary when BitLocker is enabled to validate the complexity of the password
- When set to Allow complexity, a connection to a domain controller is attempted to validate that the complexity adheres to the rules set by the policy. If no domain controllers are found, the password is accepted regardless of actual password complexity and the drive will be encrypted using that password as a protector
- When set to Do not allow complexity, password complexity isn't validated
Passwords must be at least 8 characters. To configure a greater minimum length for the password, specify the desired number of characters under Minimum password length
If you disable or don't configure this policy setting, the default length constraint of eight characters applies to operating system drive passwords, and no complexity checks occur.
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Removable Data Drives |
This policy setting allows you to specify whether smart cards can be used to authenticate user access to the BitLocker-protected removable data drives.
- If you enable this policy setting, smart cards can be used to authenticate user access to the drive
- You can require a smart card authentication by selecting the Require use of smart cards on removable data drives option
- If you disable this policy setting, users can't use smart cards to authenticate their access to BitLocker-protected removable data drives
- If you don't configure this policy setting, smart cards can be used to authenticate user access to a BitLocker-protected drive
|
Path |
| CSP |
Not available |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Removable Data Drives |
Control use of BitLocker on removable drives
This policy setting controls the use of BitLocker on removable data drives.
When this policy setting is enabled, you can select property settings that control how users can configure BitLocker:
- Choose Allow users to apply BitLocker protection on removable data drives to permit the user to run the BitLocker setup wizard on a removable data drive
- Choose Allow users to suspend and decrypt BitLocker on removable data drives to permit the user to remove BitLocker encryption from the drive or suspend the encryption while maintenance is performed
If you disable this policy setting, users can't use BitLocker on removable disk drives.
|
Path |
| CSP |
./Device/Vendor/MSFT/BitLocker/RemovableDrivesConfigureBDE |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Removable Data Drives |
Deny write access to removable drives not protected by BitLocker
This policy setting configures whether BitLocker protection is required for a device to be able to write data to a removable data drive.
If you enable this policy setting:
- all removable data drives that are not BitLocker-protected are mounted as read-only
- if the drive is protected by BitLocker, it's mounted with read and write access
- if the Deny write access to devices configured in another organization option is selected, only drives with identification fields matching the computer's identification fields are given write access
- When a removable data drive is accessed, it's checked for valid identification field and allowed identification fields. These fields are defined by the (Provide the unique identifiers for your organization)[] policy setting
If you disable or do not configure this policy setting, all removable data drives on the computer are mounted with read and write access.
Note
This policy setting is ignored if the policy settings Removable Disks: Deny write access is enabled.
Important
If you enable this policy:
- Use of BitLocker with the TPM startup key or TPM key and PIN must be disallowed
- Use of recovery keys must be disallowed
|
Path |
| CSP |
./Device/Vendor/MSFT/BitLocker/RemovableDrivesRequireEncryption |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Removable Data Drives |
Enforce drive encryption type on removable data drives
This policy setting controls the use of BitLocker on removable data drives.
When you enable this policy setting, the encryption type option isn't offered in the BitLocker setup wizard:
- Choose full encryption to require that the entire drive be encrypted when BitLocker is turned on
- Choose used space only encryption to require that only the portion of the drive used to store data is encrypted when BitLocker is turned on
If you disable or don't configure this policy setting, the BitLocker setup wizard asks the user to select the encryption type before turning on BitLocker.
Note
Changing the encryption type has no effect if the drive is already encrypted or if encryption is in progress.
This policy is ignored when shrinking or expanding a volume, and the BitLocker driver uses the current encryption method. For example, when a drive that is using Used Space Only encryption is expanded, the new free space isn't wiped like a drive that uses Full encryption. The user could wipe the free space on a Used Space Only drive by using the following command: manage-bde.exe -w. If the volume is shrunk, no action is taken for the new free space.
|
Path |
| CSP |
./Device/Vendor/MSFT/BitLocker/RemovableDrivesEncryptionType |
| GPO |
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Removable Data Drives |
Removable drives excluded from encryption
Common settings
Operating system drive
Fixed data drives