BitLocker To Go Best Practices

Posted on Updated on

BitLocker To Go is Microsoft’s removable media encryption solution. It uses the same underlying disk encryption technology as BitLocker (for fixed disks) but is designed to address the use cases around removable media. For example, sensitive data is copied to a USB key and lost. If the key is protected with BitLocker To Go, if the key is found, the data is unreadable on a device that hasn’t viewed the data previously without a PIN. This renders the data essentially useless except by an authorized user.

There are dozens of configuration options managed through policy objects that can be used to control BitLocker. There is plenty of information already on TechNet here.

I’m not going to get into the fine details of each individual policy. I’m going to provide a framework to help you decide what combination of configuration options will meet a particular use case. Most organizations need to understand how they want to implement BitLocker To Go. A good starting point is to by considering the following questions:

  1. Do you want to enforce the encryption of removable media or leave encryption to the user’s discretion?
  2. Do you want to prevent the reading of data from removable media not authored within the organization (E.g. read a key from a vendor, or a personal a user’s personal unencrypted key)
  3. Do you want to prevent writing to unencrypted removable media devices?

Most organizations will not want to leave the decision whether or not to encrypt removable media to the discretion of the end user. This involves a training burden and sound judgment by the end user. Ultimately there is no way to ensure or measure compliance.

Typically, an organization will want to ensure compliance. This involves creating a process to centrally encrypt USB keys and have a request/authorization process for users that need to right to keys.

  1. The scenario for USB keys is something like the following:
  2. Users can read from unencrypted USB keys (personal or from partners, vendors, etc.)
  3. Users are prevented from writing to unencrypted keys
  4. Users who need to write to a USB key go through the request and approval process.
  5. The Service Desk encrypts a key and delivers it along with the PIN and use instructions.
  6. Users are prompted for a PIN on first use of an encrypted key on a particular machine and can then write to the key
  7. If USB key is lost or stolen, it cannot be read except on a machine that has previously read the Key or by entering the PIN (or smartcard)

To implement the above scenario the following GPOs can be used as a starting point:

Group Policy


Allow users to apply BitLocker protection on removable data drives


Allow users to suspend and decrypt BitLocker protection on removable data drives


Do not allow write access to devices configured in another organization


Do not install BitLocker To Go Reader on FAT formatted removable drives


Require password for removable data drive


Allow Data Recovery Agent


Omit recovery options from BitLocker setup wizard


Save BitLocker recovery information to AD DS for removable data drives


Do not enable BitLocker until recovery information is stored in AD DS for removable data drives


Require use of smart cards on removable data drives


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s