Bitlocker Group Policy Windows 11
Emmanuelle Riker
While many of the BitLocker policy settings can be configured using both CSP and GPO, there are some settings that are only available using one of the options. To learn about the policy settings available for both CSP and GPO, review the section BitLocker policy settings.
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.
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:
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.
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.
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.
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:
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.
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.
Typically, BitLocker follows the Choose drive encryption method and cipher strength policy configuration. However, this policy setting will be ignored for self-encrypting fixed drives and self-encrypting OS drives.
Only full disk encryption is supported when using this policy for silent encryption. For non-silent encryption, encryption type will depend on the Enforce drive encryption type on operating system drives and Enforce drive encryption type on fixed data drives policies configured on the device.
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.
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.
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.
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.
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.
If the policy setting Configure TPM platform validation profile for native UEFI firmware configurations is enabled and has PCR 7 omitted, BitLocker is prevented from using Secure Boot for platform or Boot Configuration Data (BCD) integrity validation.
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.
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:
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.
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.
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.
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.
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.
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.
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:
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.
d3342ee215