18.9.11.1.13 Ensure 'Configure use of smart cards on fixed data drives: Require use of smart cards on fixed data drives' is set to 'Enabled: True'

Information

This policy setting allows you to specify whether smart cards must be used to authenticate user access to the BitLocker-protected fixed data drives on a computer.

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' check box.

Note: This setting is enforced when turning on BitLocker, not when unlocking a drive. BitLocker will allow unlocking a drive with any of the protectors available on the drive.

The recommended state for this setting is: Enabled: True (checked).

Rationale:

A drive can be compromised by guessing or finding the authentication information used to access the drive. For example, a password could be guessed, or a drive set to automatically unlock could be lost or stolen with the computer it automatically unlocks with.

Impact:

Smart cards will be required to authenticate user access to fixed data drives. Use of smart cards requires PKI infrastructure. Users will need to authenticate with the smart card to unlock the fixed data drive every time they restart the computer.

Solution

To establish the recommended configuration via GP, set the following UI path to Enabled: True (checked):

Computer Configuration\Policies\Administrative Templates\Windows Components\BitLocker Drive Encryption\Fixed Data Drives\Configure use of smart cards on fixed data drives: Require use of smart cards on fixed data drives

Note: This Group Policy path may not exist by default. It is provided by the Group Policy template VolumeEncryption.admx/adml that is included with the Microsoft Windows 7 & Server 2008 R2 Administrative Templates (or newer).

Default Value:

Enabled: False (unchecked). (Users are allowed to use smart cards to authenticate their access to BitLocker-protected fixed data drives, but it is not required.)

See Also

https://workbench.cisecurity.org/files/4167