BitLocker recovery keys

A BitLocker recovery key is only useful if someone can find it on the day the laptop asks for it. Tenvara collects the recovery key of every encrypted volume on every Windows device into the credentials vault, whoever turned BitLocker on: Tenvara's own hardening, Intune, Group Policy, another tool, a technician with manage-bde, or Windows device encryption on a new laptop.

It is part of Device hardening, so it is there when the Device hardening module is switched on, and it needs the Documentation module for the vault.

How keys are collected, and when#

The Tenvara agent reads every BitLocker volume on the device: the operating system volume, fixed data volumes and removable drives. For each unlocked volume it reads every recovery password and sends it sealed to Tenvara, which keeps each one as its own credential in the vault, linked to the device and named "BitLocker recovery key" with the volume and the device. A key is never written to a command, a log or the agent's own storage in clear.

Keys are kept current in two ways:

• Daily. Every Windows device is asked for its keys once a day by default.
• On change. Between checks the agent watches the volumes and their protectors, and reports straight away when a volume is encrypted or a protector is added, removed or rotated. Tenvara then asks for the keys at once.

A volume that is locked lists its protectors, and its key is read once it is unlocked. A device that is offline is asked when it next connects.

It works whichever tool turned BitLocker on, on Windows 11 and Windows Server, and on older Windows through the Lite agent. See Older Windows and the Lite agent.

The Encryption block on a device#

Open a device and look at its Overview tab. The Encryption block, after Protection, lists each volume with its state and protectors, and for each key:

• Recovery key held in Tenvara, last confirmed and when, with Open in the vault to go to the credential.
• Recovery key not held yet: it is read on the next check, or the volume is locked and it is read once it is unlocked.
• No recovery password: the volume has no recovery password at all (see below).

Check now asks the agent straight away. The line under the block says when the keys were last checked.

If the agent on the device is too old to read BitLocker keys, the block says so: update the agent and its keys are collected on the next check. An edition of Windows with no BitLocker says that instead.

Superseded keys#

When a recovery password is replaced (a rotation after use, or someone removing and adding a protector), Tenvara keeps both. The new key is collected, and the old one is marked Superseded with the date, renamed to say so in the vault and tagged, with its history intact. The block lists earlier keys kept under the current one.

Collection never deletes a key. A volume that is no longer on the device keeps its keys in the vault, and the block lists it as no longer on the device, so an older key is still there if a drive ever asks for it.

Adding a recovery password#

A volume that unlocks with the TPM only has nothing to type in when the TPM is reset or the mainboard is replaced, and its data cannot be recovered. Tenvara flags it as No recovery password on the device and in the report.

1. In the device's Encryption block, press Add a recovery password on that volume.
2. Give a Reason. It is shown to the approver.
3. Press Ask for approval.

The request goes through Approvals and shows Waiting for approval until it is answered. Once approved, the agent adds a recovery password to the volume and keeps it in the vault before anything else. The encryption itself is left exactly as it is: nothing is decrypted or encrypted again.

The BitLocker keys page and the Home block#

Go to Security > Hardening and open the BitLocker keys tab for the whole fleet. The tiles count Encrypted devices, Encrypted volumes held, devices With no recovery key held and volumes With no recovery password at all. The list shows each device with its customer, how many of its keys are held and when it was last checked, with the devices that have no key held first. Switch Show between the ones with no key held and every device, and search by device.

When every key is held, the page says Every encrypted device has its recovery key held: new and changed keys are collected by themselves, so there is nothing to do.

Home has a block for the same thing, Encrypted devices with no recovery key held, which reads "Every recovery key is held in the vault" when there are none. Add it from Customise on Home.

Removable drives are shown and their keys kept, but because they come and go they are never counted as a device with no key held.

Tip: In takeover mode, every Windows device of the customer is asked for its keys as soon as takeover starts, and the takeover card and its turn-off dialog show how many BitLocker keys have been collected. Check that number before the previous provider's tools are removed.

Turning it off for a customer#

Some customers do not allow their recovery keys to be kept by a supplier. Collection is on by default and can be turned off per customer.

• For everyone: Settings > Agent protection, under Device hardening, has Collect BitLocker recovery keys and Check BitLocker recovery keys every (24 hours by default).
• For one customer: open the customer page, go to Security, then Hardening. The BitLocker recovery keys card shows whether keys are Collected or Not collected, the counts of encrypted devices, keys held and volumes with no key held, and a link to Customer settings where the switch is.

The same card carries a data processing note you can show the customer: what is kept (each volume's 48-digit recovery password), where (encrypted in the credentials vault, linked to the device) and who can reveal it. With collection turned off, nothing new is read from that customer's devices, and the device's block says so. Keys kept before it was turned off stay in the vault until someone deletes them there.

Who can reveal a key#

Seeing that a key is held is not the same as reading it. The Encryption block and the BitLocker keys page show only that a key exists and when it was last confirmed. The 48 digits are a vault credential, so revealing them follows the vault's rules:

• The person needs access to that customer's credentials and the Reveal credentials role action.
• They confirm it is them and give a reason where your vault settings ask for one.
• Every reveal is in the vault audit log, with who, when and why.

See The credentials vault and Reviews and the vault audit log.

Related: Enforcing in rings and rolling back (BitLocker turned on by a hardening baseline), Device protection.