Practical Protection: Adding Self-Service to BitLocker Recovery Key Access

All about BitLocker

When Microsoft introduced BitLocker in 2004, as part of Windows Vista, it was a big deal. Its combination of device encryption and boot integrity verification was unique; there were other full-disk encryption (FDE) products from third parties, and even a few self-encrypting drives (SED), but building FDE protection into the operating system was a fairly bold move. BitLocker’s feature set has evolved over the last 20 years, and the current implementation protects against several different types of offline attacks.

It’s important to note that a big part of BitLocker’s security value comes from using it on machines that have a Trusted Platform Module (TPM) chip. Each volume protected with BitLocker has a volume master key (VMK). When a TPM-equipped machine with BitLocker boots, it’s actually using a small, unencrypted boot partition that contains the Windows bootloader. This bootloader asks the TPM to “unseal” the VMK for the operating system volume, but the TPM will only release the VMK if it’s able to verify that the bootloader and BIOS integrity remain intact.

What if the TPM won’t release the VMK, or it can’t be read? One case when this can happen is when the device is protected with a PIN or a startup key. In those BitLocker modes, if the user can’t produce the PIN or startup key (perhaps because the PIN is forgotten or the USB containing the key’s been lost), the device will be permanently unbootable. The solution for this is that BitLocker allows you to generate a recovery key and store it elsewhere (in Active Directory or Entra ID, in your Microsoft consumer account, as a text file, or even on paper). You can enter the recovery key to unlock the VMK, and thus boot the machine. The full preboot authentication phase is complicated, but interesting; you can read more about it in the BitLocker documentation. For purposes of this column it’s enough to know that it exists.

Recovering the Recovery Key

The presence of the recovery key means that enterprises can still recover BitLocker-protected machines even when the user isn’t able to provide the PIN or startup key. One common case: an employee leaves her job and turns in her laptop but forgets to tell the company what the BitLocker PIN was. The IT team can look up the recovery key in Entra ID, type it in, and unlock the machine. This superpower means that these protectors are obviously sensitive, so they are protected in the directory by specific Graph permissions. The normal flow is that an administrator will log in, retrieve the recovery key, and use it to unlock the machine. However, now Microsoft is making this process a little easier by allowing users to see their own recovery keys using Intune self-service. As of Intune release 2405, there are 4 new capabilities available for Intune-enrolled devices:

1. Administrators can choose to allow end users to see their own recovery keys. This access is controlled at the tenant level by a setting in the Entra admin center (Devices > Device settings > Restrict users from recovering the BitLocker key(s) for their owned devices). By default, this is set to “no,” meaning that all users can recover their own keys.
2. Administrators can enforce a conditional access policy to restrict key access to managed devices.
3. When the tenant-level setting and any applicable CA policies both allow it, users can go to the Intune Company Portal website and look up their own recovery keys. The keys are visible as properties of each managed device. The Company Portal app doesn’t support showing the keys.
4. When a user retrieves their keys, the access is recorded in the Entra ID audit logs. This parallels what previously existed with admin access, which was also audited.

Two Things to Keep in Mind

The process of using the recovery key after retrieval remains unchanged: a human needs to type in the 48-character key on the BitLocker boot screen, which then releases the VMK, which is then used to unlock the encrypted volume. It’s important to understand that unlocking the volume doesn’t allow the user who holds the recovery key to log in; the normal Windows login mechanisms apply. If the machine was previously joined to a domain, for example, it may require some rehab work before you can use domain credentials to log in to it. (This is a great example of where Windows LAPS can be useful!)

In addition, this self-service access requires that the device be enrolled in Intune. If you have devices that aren’t enrolled, you either need to enroll them or to consider other ways of ensuring access to the recovery key… like having an administrator do it.

This new feature isn’t world-changing, since administrators have always had the ability to get the recovery key, but it will probably be useful in larger organizations that want to allow users to have self-service access. It’s a good example of Microsoft making a small but useful incremental change to help justify the ongoing cost of a subscription to Intune, and no doubt there will be more similar changes in the future.