BitLocker FAQ

Yes, BitLocker supports multifactor authentication for operating system drives. If BitLocker is enabled on a computer that has a TPM version 1.2 or later, additional forms of authentication can be used with the TPM protection.

Two partitions are required to run BitLocker because pre-startup authentication and system integrity verification must occur on a separate partition from the encrypted operating system drive. This configuration helps protect the operating system and the information in the encrypted drive.

The TPM status can be checked in Windows Defender Security Center > Device Security > Security processor details.

Yes, BitLocker can be enabled on an operating system drive without a TPM, if the BIOS or UEFI firmware has the ability to read from a USB flash drive in the boot environment. BitLocker won't unlock the protected drive until BitLocker's own volume master key is first released by either the computer's TPM or by a USB flash drive containing the BitLocker startup key for that computer. However, computers without TPMs won't be able to use the system integrity verification that BitLocker can also provide. To help determine whether a computer can read from a USB device during the boot process, use the BitLocker system check as part of the BitLocker setup process. This system check performs tests to confirm that the computer can properly read from the USB devices at the appropriate time and that the computer meets other BitLocker requirements.

Contact the computer manufacturer to request a Trusted Computing Group (TCG)-compliant BIOS or UEFI boot firmware that meets the following requirements:

• It's compliant with the TCG standards for a client computer
• It has a secure update mechanism to help prevent a malicious BIOS or boot firmware from being installed on the computer

To turn on, turn off, or change configurations of BitLocker on operating system and fixed data drives, membership to the local Administrators group is required. Standard users can turn on, turn off, or change configurations of BitLocker on removable data drives.

The computer's startup options should be configured to have the hard disk drive first in the boot order, before any other drives such as CD/DVD drives or USB drives. If the hard disk isn't first and the computer typically boots from the hard disk, then a boot order change may be detected or assumed when removable media is found during boot. The boot order typically affects the system measurement that is verified by BitLocker and a change in boot order will cause a prompt for the BitLocker recovery key. For the same reason, if a laptop is used with a docking station, ensure that the hard disk drive is first in the boot order both when the laptop is docked and undocked.

Yes.

Decrypt completely removes BitLocker protection and fully decrypts the drive.

Suspend keeps the data encrypted but encrypts the BitLocker volume master key with a clear key. The clear key is a cryptographic key stored unencrypted and unprotected on the disk drive. By storing this key unencrypted, the Suspend option allows for changes or upgrades to the computer without the time and cost of decrypting and re-encrypting the entire drive. After the changes are made and BitLocker is again enabled, BitLocker will reseal the encryption key to the new values of the measured components that changed as a part of the upgrade, the volume master key is changed, the protectors are updated to match and the clear key is erased.

No user action is required for BitLocker in order to apply updates from Microsoft, including Windows quality updates and feature updates. Users need to suspend BitLocker for Non-Microsoft software updates, such as:

• Some TPM firmware updates if these updates clear the TPM outside of the Windows API. Not every TPM firmware update will clear the TPM. Users don't have to suspend BitLocker if the TPM firmware update uses Windows API to clear the TPM because in this case, BitLocker will be automatically suspended. It's recommended that users test their TPM firmware updates if they don't want to suspend BitLocker protection
• Non-Microsoft application updates that modify the UEFI\BIOS configuration
• Manual or non-Microsoft updates to secure boot databases (only if BitLocker uses Secure Boot for integrity validation)
• Updates to UEFI\BIOS firmware, installation of additional UEFI drivers, or UEFI applications without using the Windows update mechanism (only if BitLocker doesn't use Secure Boot for integrity validation during updates)
• BitLocker can be checked if it uses Secure Boot for integrity validation with the command line manage-bde.exe -protectors -get C:. If Secure Boot for integrity validation is being used, it reports Uses Secure Boot for integrity validation

Yes, the deployment and configuration BitLocker can be automated using either Windows PowerShell or with the manage-bde.exe command. For more information about common BitLocker management commands, check the BitLocker operations guide.

Typically, there's a small performance overhead, often in single-digit percentages, which is relative to the throughput of the storage operations on which it needs to operate.

Although BitLocker encryption occurs in the background while a user continues to work with the system remaining usable, encryption times vary depending on the type of drive that is being encrypted, the size of the drive, and the speed of the drive. If encrypting large drives, encryption may want to be scheduled during times when the drive isn't being used.

When BitLocker is enabled, BitLocker can also be set to encrypt the entire drive or just the used space on the drive. On a new hard drive, encrypting just the used spaced can be considerably faster than encrypting the entire drive. When this encryption option is selected, BitLocker automatically encrypts data as it is saved, ensuring that no data is stored unencrypted.

If the computer is turned off or goes into hibernation, the BitLocker encryption and decryption process will resume where it stopped the next time Windows starts. BitLocker resuming encryption or decryption is true even if the power is suddenly unavailable.

No, BitLocker doesn't encrypt and decrypt the entire drive when reading and writing data. The encrypted sectors in the BitLocker-protected drive are decrypted only as they're requested from system read operations. Blocks that are written to the drive are encrypted before the system writes them to the physical disk. No unencrypted data is ever stored on a BitLocker-protected drive.

Policy settings can be configured to require that data drives be BitLocker-protected before a BitLocker-protected computer can write data to them. For more info, see BitLocker policy settings. When these policy settings are enabled, the BitLocker-protected operating system will mount any data drives that aren't protected by BitLocker as read-only.

BitLocker lets users choose to encrypt just their data. Although it's not the most secure way to encrypt a drive, this option can reduce encryption time by more than 99 percent, depending on how much data that needs to be encrypted. For more information, see Used Disk Space Only encryption.

The following types of system changes can cause an integrity check failure and prevent the TPM from releasing the BitLocker key to decrypt the protected operating system drive:

• Moving the BitLocker-protected drive into a new computer
• Installing a new motherboard with a new TPM
• Turning off, disabling, or clearing the TPM
• Changing any boot configuration settings
• Changing the BIOS, UEFI firmware, master boot record, boot sector, boot manager, option ROM, or other early boot components or boot configuration data

Because BitLocker is designed to protect computers from numerous attacks, there are numerous reasons why BitLocker could start in recovery mode. For example:

• Changing the BIOS boot order to boot another drive in advance of the hard drive
• Adding or removing hardware, such as inserting a new card in the computer
• Removing, inserting, or completely depleting the charge on a smart battery on a portable computer

In BitLocker, recovery consists of decrypting a copy of the volume master key using either a recovery key stored on a USB flash drive or a cryptographic key derived from a recovery password. The TPM isn't involved in any recovery scenarios, so recovery is still possible if the TPM fails boot component validation, malfunctions, or is removed.

BitLocker can be prevented from binding to PCR 7 if a non-Windows OS booted prior to Windows, or if Secure Boot isn't available to the device, either because it's disabled or the hardware doesn't support it.

Yes, multiple hard disks can be swapped on the same computer if BitLocker is enabled, but only if the hard disks were BitLocker-protected on the same computer. The BitLocker keys are unique to the TPM and the operating system drive. If a backup operating system or data drive needs to be prepared in case of a disk failure, make sure that they were matched with the correct TPM. Different hard drives can also be configured for different operating systems and then enable BitLocker on each one with different authentication methods (such as one with TPM-only and one with TPM+PIN) without any conflicts.

Yes, if the drive is a data drive, it can be unlocked from the BitLocker Drive Encryption Control Panel item by using a password or smart card. If the data drive was configured for automatic unlock only, it will need to be unlocked by using the recovery key. The encrypted hard disk can be unlocked by a data recovery agent (if one was configured) or it can be unlocked by using the recovery key.

Some drives can't be encrypted with BitLocker. Reasons a drive can't be encrypted include insufficient disk size, an incompatible file system, if the drive is a dynamic disk, or a drive is designated as the system partition. By default, the system drive (or system partition) is hidden from display. However, if it isn't created as a hidden drive when the operating system was installed due to a custom installation process, that drive might be displayed but can't be encrypted.

Any number of internal, fixed data drives can be protected with BitLocker. On some versions ATA and SATA-based, direct-attached storage devices are also supported.

Removable data drives can be unlocked using a password or a smart card. A SID protector can also be configured to unlock a drive by using user domain credentials. After encryption has started, the drive can also be automatically unlocked on a specific computer for a specific user account. System administrators can configure which options are available for users including password complexity and minimum length requirements. To unlock by using a SID protector, use manage-bde.exe:

Manage-bde.exe -protectors -add e: -sid domain\username

There are multiple keys that can be generated and used by BitLocker. Some keys are required and some are optional protectors you can choose to use depending on the level of security you require.

TPM owner password

Prior to enabling BitLocker on a computer with a TPM version 1.2, you must initialize the TPM. The initialization process generates a TPM owner password, which is a password set on the TPM. You must be able to supply the TPM owner password to change the state of the TPM, such as when enabling or disabling the TPM or resetting the TPM lockout.

Recovery password and recovery key

When you set up BitLocker, you must choose how access to BitLocker-protected drives can be recovered in the event that the specified unlock method cannot be used (such as if the TPM cannot validate the boot components, the personal identification number (PIN) is forgotten, or the password is forgotten). In these situations, you must be able to supply either the recovery key or the recovery password to unlock the encrypted data on the drive. When you supply the recovery information, you can use either of the following formats:

• A recovery password consisting of 48 digits divided into eight groups. During recovery, you need to type this password into the BitLocker recovery console by using the function keys on your keyboard
• A key file on a USB flash drive that is read directly by the BitLocker recovery console. During recovery, you need to insert this USB device

PIN and enhanced PIN

For a higher level of security with the TPM, you can configure BitLocker with a personal identification number (PIN). The PIN is a user-created value that must be entered each time the computer starts or resumes from hibernation. The PIN can consist of 4 to 20 digits as specified by the Configure minimum PIN length for startup policy setting and is stored internally as a 256-bit hash of the entered Unicode characters. This value is never displayed to the user. The PIN is used to provide another factor of authentication in conjunction with TPM authentication.
For an even higher level of security with the TPM, you can configure BitLocker to use enhanced PINs. Enhanced PINs are PINs that use the full keyboard character set in addition to the numeric set to allow for more possible PIN combinations and are between 4 and 20 characters in length. To use enhanced PINs, you must enable the Allow enhanced PINs for startup policy setting before adding the PIN to the drive. By enabling this policy, all PINs created can utilize full keyboard characters.

Startup key

Configuring a startup key is another method to enable a higher level of security with the TPM. The startup key is a key stored on a USB flash drive, and the USB flash drive must be inserted every time the computer starts. The startup key is used to provide another factor of authentication in conjunction with TPM authentication. To use a USB flash drive as a startup key, the USB flash drive must be formatted by using the NTFS, FAT, or FAT32 file system.

The recovery password and recovery key for an operating system drive or a fixed data drive can be saved to a folder, saved to one or more USB devices, saved to a Microsoft Account, or printed.

For removable data drives, the recovery password and recovery key can be saved to a folder, saved to a Microsoft Account, or printed. By default, a recovery key for a removable drive can't be stored on a removable drive.

A domain administrator can also configure policy settings to automatically generate recovery passwords and store them in Active Directory Domain Services (AD DS) or Microsoft Entra ID for any BitLocker-protected drive.

The Manage-bde.exe command-line tool can be used to replace TPM-only authentication mode with a multifactor authentication mode. For example, if BitLocker is enabled with TPM authentication only and PIN authentication needs to be added, use the following commands from an elevated Command Prompt, replacing 4-20 digit numeric PIN with the desired numeric PIN:

manage-bde.exe -protectors -delete %systemdrive% -type tpm

manage-bde.exe -protectors -add %systemdrive% -tpmandpin <4-20 digit numeric PIN>

New hardware that meets Windows Hardware Compatibility Program requirements make a PIN less critical as a mitigation, and having a TPM-only protector is likely sufficient when combined with policies like device lockout. For example, Surface Pro and Surface Book don't have external DMA ports to attack. For older hardware, where a PIN may be needed, it's recommended to enable enhanced PINs that allow non-numeric characters such as letters and punctuation marks, and to set the PIN length based on the risk tolerance and the hardware anti-hammering capabilities available to the TPMs on the computers.

BitLocker is designed to make the encrypted drive unrecoverable without the required authentication. When in recovery mode, the user needs the recovery password or recovery key to unlock the encrypted drive.

While using a USB flash drive as both the startup key and for storage of the recovery key is technically possible, it isn't a best practice to use one USB flash drive to store both keys. If the USB flash drive that contains the startup key is lost or stolen, the recovery key will also be lost. In addition, inserting this key would cause the computer to automatically boot from the recovery key even if TPM-measured files have changed, which circumvents the TPM's system integrity check.

Yes, computer's startup key can be saved on multiple USB flash drives. Right-clicking a BitLocker-protected drive and selecting Manage BitLocker will provide the options to save the recovery keys on additional USB flash drives as needed.

Yes, BitLocker startup keys for different computers can be saved on the same USB flash drive.

Generating different startup keys for the same computer can be done through scripting. However, for computers that have a TPM, creating different startup keys prevents BitLocker from using the TPM's system integrity check.

Generating multiple PIN combinations can't be done.

Raw data is encrypted with the full volume encryption key, which is then encrypted with the volume master key. The volume master key is in turn encrypted by one of several possible methods depending on the authentication (that is, key protectors or TPM) and recovery scenarios.

The full volume encryption key is encrypted by the volume master key and stored in the encrypted drive. The volume master key is encrypted by the appropriate key protector and stored in the encrypted drive. If BitLocker has been suspended, the clear key that is used to encrypt the volume master key is also stored in the encrypted drive, along with the encrypted volume master key.

This storage process ensures that the volume master key is never stored unencrypted and is protected unless BitLocker is disabled. The keys are also saved to two additional locations on the drive for redundancy. The keys can be read and processed by the boot manager.

The F1 through F10 keys are universally mapped scan codes available in the pre-boot environment on all computers and in all languages. The numeric keys 0 through 9 aren't usable in the pre-boot environment on all keyboards.

When using an enhanced PIN, users should run the optional system check during the BitLocker setup process to ensure that the PIN can be entered correctly in the pre-boot environment.

It's possible that a personal identification number (PIN) can be discovered by an attacker performing a brute force attack. A brute force attack occurs when an attacker uses an automated tool to try different PIN combinations until the correct one is discovered. For BitLocker-protected computers, this type of attack, also known as a dictionary attack, requires that the attacker has physical access to the computer.

The TPM has the built-in ability to detect and react to these types of attacks. Because different manufacturers' TPMs may support different PIN and attack mitigations, contact the TPM's manufacturer to determine how the computer's TPM mitigates PIN brute force attacks. After the TPM's manufacturer is determined, contact the manufacturer to gather the TPM's vendor-specific information. Most manufacturers use the PIN authentication failure count to exponentially increase lockout time to the PIN interface. However, each manufacturer has different policies regarding when and how the failure counter is decreased or reset.

The TPM manufacturer can be determined in Windows Defender Security Center > Device Security > Security processor details.

The following questions can assist when asking a TPM manufacturer about the design of a dictionary attack mitigation mechanism:

• How many failed authorization attempts can occur before lockout?
• What is the algorithm for determining the duration of a lockout based on the number of failed attempts and any other relevant parameters?
• What actions can cause the failure count and lockout duration to be decreased or reset?

The minimum personal identification number (PIN) length can be configured by using the Configure minimum PIN length for startup Group Policy setting and allow the use of alphanumeric PINs by enabling the Allow enhanced PINs for startup policy setting. PIN complexity can't be required via policy settings.

For more info, see BitLocker policy settings.

BitLocker hashes the user-specified personal identification number (PIN) by using SHA-256, and the first 160 bits of the hash are used as authorization data sent to the TPM to seal the volume master key. The volume master key is now protected by both the TPM and the PIN. To unseal the volume master key, you are required to enter the PIN each time the computer restarts or resumes from hibernation.

BitLocker To Go is BitLocker Drive Encryption on removable data drives. This feature includes the encryption of:

• USB flash drives
• SD cards
• External hard disk drives
• Other drives that are formatted by using the NTFS, FAT16, FAT32, or exFAT file system.

Drive partitioning must meet the BitLocker Drive Encryption Partitioning Requirements.

As with BitLocker, drives that are encrypted by BitLocker To Go can be opened by using a password or smart card on another computer. In Control Panel, use BitLocker Drive Encryption.

If BitLocker is enabled on a drive before policy settings are applied to enforce a backup, the recovery information won't be automatically backed up to AD DS when the computer joins the domain or when the policy settings are subsequently applied. However, the policy settings Choose how BitLocker-protected operating system drives can be recovered, Choose how BitLocker-protected fixed drives can be recovered, and Choose how BitLocker-protected removable drives can be recovered can be chosen to require the computer to be connected to a domain before BitLocker can be enabled to help ensure that recovery information for BitLocker-protected drives in the organization is backed up to AD DS.

For more information how to back up the recovery password to AD DS or Microsoft Entra ID, review the BitLocker operations guide.

Yes, an event log entry that indicates the success or failure of a backup is recorded on the client computer. However, even if an event log entry says "Success," the information could have been subsequently removed from AD DS, or BitLocker could have been reconfigured in such a way that the Active Directory information can no longer unlock the drive (such as by removing the recovery password key protector). In addition, it's also possible that the log entry could be spoofed.

Ultimately, determining whether a legitimate backup exists in AD DS requires querying AD DS with domain administrator credentials by using the BitLocker password viewer tool.

No. By design, BitLocker recovery password entries don't get deleted from AD DS. Therefore, multiple passwords might be seen for each drive. To identify the latest password, check the date on the object.

If the backup initially fails, such as when a domain controller is unreachable at the time when the BitLocker setup wizard is run, BitLocker doesn't try again to back up the recovery information to AD DS.

When an administrator selects the Do not enable BitLocker until recovery information is stored in AD DS for (operating system | fixed data | removable data) drives check box in any of the Choose how BitLocker-protected operating system drives can be recovered, Choose how BitLocker-protected fixed data drives can be recovered, and Choose how BitLocker-protected removable data drives can be recovered policy settings, users can't enable BitLocker unless the computer is connected to the domain and the backup of BitLocker recovery information to AD DS succeeds. With these settings configured if the backup fails, BitLocker can't be enabled, ensuring that administrators will be able to recover BitLocker-protected drives in the organization.

For more info, see BitLocker policy settings.

When an administrator clears these check boxes, the administrator is allowing a drive to be BitLocker-protected without having the recovery information successfully backed up to AD DS; however, BitLocker won't automatically retry the backup if it fails. Instead, administrators can create a backup script, as described earlier in What if BitLocker is enabled on a computer before the computer joins the domain? to capture the information after connectivity is restored.

BitLocker uses Advanced Encryption Standard (AES) as its encryption algorithm with configurable key lengths of 128 bits or 256 bits. The default encryption setting is AES-128, but the options are configurable by using policy settings.

The recommended practice for BitLocker configuration on an operating system drive is to implement BitLocker on a computer with a TPM version 1.2 or higher.

BitLocker on operating system drives in its basic configuration provides extra security for the hibernate mode. In sleep mode, the computer is vulnerable to direct memory access attacks, since unprotected data remains in RAM. Therefore, for improved security, it's recommended to disable sleep mode. Startup authentication can be configured by using a policy setting.

Most operating systems use a shared memory space and rely on the operating system to manage physical memory. A TPM is a hardware component that uses its own internal firmware and logic circuits for processing instructions, thus shielding it from external software vulnerabilities. Attacking the TPM requires physical access to the computer. Additionally, the tools and skills necessary to attack hardware are often more expensive, and usually aren't as available as the ones used to attack software. And because each TPM is unique to the computer that contains it, attacking multiple TPM computers would be difficult and time-consuming.

BitLocker Network Unlock enables easier management for BitLocker-enabled clients and servers that use the TPM+PIN protection method in a domain environment. When a computer that is connected to a wired corporate network is rebooted, Network Unlock allows the PIN entry prompt to be bypassed. It automatically unlocks BitLocker-protected operating system volumes by using a trusted key that is provided by the Windows Deployment Services server as its secondary authentication method.

To use Network Unlock, a PIN must be configured for the computer. When the computer isn't connected to the network, a PIN will need to be provided to unlock it.

BitLocker Network Unlock has software and hardware requirements for both client computers, Windows Deployment services, and domain controllers that must be met before it can be used.

Network Unlock uses two protectors - the TPM protector and the protector provided by the network or by the PIN. Automatic unlock uses a single protector - the one stored in the TPM. If the computer is joined to a network without the key protector, it will prompt to enter a PIN. If the PIN isn't available, the recovery key will need to be used to unlock the computer if it can't be connected to the network.

For more info, see BitLocker: How to enable Network Unlock.

Yes, Encrypting File System (EFS) can be used to encrypt files on a BitLocker-protected drive. BitLocker helps protect the entire operating system drive against offline attacks, whereas EFS can provide additional user-based file level encryption for security separation between multiple users of the same computer. EFS can also be used in Windows to encrypt files on other drives that aren't encrypted by BitLocker. The root secrets of EFS are stored by default on the operating system drive; therefore, if BitLocker is enabled for the operating system drive, data that is encrypted by EFS on other drives is also indirectly protected by BitLocker.

Yes. However, the debugger should be turned on before enabling BitLocker. Turning on the debugger ensures that the correct measurements are calculated when sealing to the TPM, allowing the computer to start properly. If debugging needs to be turned on or off when using BitLocker, be sure to suspend BitLocker first to avoid putting the computer into recovery mode.

BitLocker has a storage driver stack that ensures memory dumps are encrypted when BitLocker is enabled.

BitLocker doesn't support smart cards for pre-boot authentication. There's no single industry standard for smart card support in the firmware, and most computers either don't implement firmware support for smart cards, or only support specific smart cards and readers. This lack of standardization makes supporting them difficult.

Microsoft doesn't support non-Microsoft TPM drivers and strongly recommends against using them with BitLocker. Attempting to use a non-Microsoft TPM driver with BitLocker may cause BitLocker to report that a TPM isn't present on the computer and not allow the TPM to be used with BitLocker.

We don't recommend modifying the master boot record on computers whose operating system drives are BitLocker-protected for several security, reliability, and product support reasons. Changes to the master boot record (MBR) could change the security environment and prevent the computer from starting normally and complicate any efforts to recover from a corrupted MBR. Changes made to the MBR by anything other than Windows might force the computer into recovery mode or prevent it from booting entirely.

The system check is designed to ensure the computer's BIOS or UEFI firmware is compatible with BitLocker and that the TPM is working correctly. The system check can fail for several reasons:

• The computer's BIOS or UEFI firmware can't read USB flash drives
• The computer's BIOS, uEFI firmware, or boot menu doesn't have reading USB flash drives enabled
• There are multiple USB flash drives inserted into the computer
• The PIN wasn't entered correctly
• The computer's BIOS or UEFI firmware only supports using the function keys (F1-F10) to enter numerals in the pre-boot environment
• The startup key was removed before the computer finished rebooting
• The TPM has malfunctioned and fails to unseal the keys

Some computers can't read USB flash drives in the pre-boot environment. First, check the BIOS or UEFI firmware and boot settings to ensure that the use of USB drives is enabled. If it isn't enabled, enable the use of USB drives in the BIOS or UEFI firmware and boot settings, and then try to read the recovery key from the USB flash drive again. If the USB flash drive still can't be read, the hard drive will need to be mounted as a data drive on another computer so that there's an operating system to attempt to read the recovery key from the USB flash drive. If the USB flash drive has been corrupted or damaged, a recovery password may need to be supplied or use the recovery information that was backed up to AD DS. Also, if the recovery key is being used in the pre-boot environment, ensure that the drive is formatted by using the NTFS, FAT16, or FAT32 file system.

The Save to USB option isn't shown by default for removable drives. If the option is unavailable, it means that a system administrator has disallowed the use of recovery keys.

Automatic unlocking for fixed data drives requires the operating system drive to also be protected by BitLocker. If a computer is being used that doesn't have a BitLocker-protected operating system drive, then the fixed drive can't be automatically unlocked. For removable data drives, automatic unlocking can be added by right-clicking the drive in Windows Explorer and selecting Manage BitLocker. Password or smart card credentials that were supplied when BitLocker was turned on can still be used to unlock the removable drive on other computers.

Limited BitLocker functionality is available in Safe Mode. BitLocker-protected drives can be unlocked and decrypted by using the BitLocker Drive Encryption Control Panel item. Right-clicking to access BitLocker options from Windows Explorer isn't available in Safe Mode.

Both fixed and removable data drives can be locked by using the Manage-bde command-line tool and the -lock command.

The syntax of this command is:

manage-bde.exe <driveletter> -lock

Outside of using this command, data drives will be locked on shutdown and restart of the operating system. A removable data drive will also be locked automatically when the drive is removed from the computer.

Yes. However, shadow copies made prior to enabling BitLocker will be automatically deleted when BitLocker is enabled on software-encrypted drives. If a hardware encrypted drive is being used, the shadow copies are retained.

BitLocker should work like any specific physical machine within its hardware limitations as long as the environment (physical or virtual) meets Windows Operating System requirements to run.

• With TPM: Yes, it's supported.
• Without TPM: Yes, it's supported (with password protector).

BitLocker is also supported on data volume VHDs, such as those used by clusters.

Yes, BitLocker can be used with virtual machines (VMs) if the environment meets BitLocker's hardware and software requirements.