BitLocker is successful only when three things are true at the same time: the volume is encrypted, the intended protector unlocks it during normal use, and authorised support staff can recover the correct device without exposing recovery material. Checking only the first of those produces a deceptively reassuring dashboard.

Decide what you are protecting against

Full-volume encryption mainly protects data at rest when a device or drive is lost, stolen or removed. It does not make an already unlocked, compromised session safe, replace identity controls or repair failing storage.

Define the device classes, data sensitivity, ownership and likely recovery conditions. A fixed office desktop, a travelling laptop, a shared workstation and a removable USB drive may need different protectors and operating controls even when they all use BitLocker.

Choose an owner for policy, recovery access, audit review, exception expiry and device disposal. If no one owns recovery, encryption can turn a routine firmware change or employee departure into permanent data loss.

Separate encryption, protectors and escrow

Record these as distinct states:

  • Encryption state: which volumes are encrypted and whether conversion is complete.
  • Protector state: TPM, TPM plus PIN, startup key, password or recovery protectors present and enabled for that volume.
  • Escrow state: where a current recovery password is stored and whether it can be retrieved by the approved role.

A policy assignment is not proof of any of them. Build reporting that reads back the actual device and directory/management records.

Depending on join and management design, Windows can back recovery passwords to Microsoft Entra ID, Active Directory Domain Services or a personal Microsoft account. Business devices need an organisation-controlled destination with least-privilege access and an audit trail. Use policy that requires successful organisational backup before encryption where the platform supports it.

Do not assume the recovery record is current because an old key exists. Match the recovery key identifier shown by the device to the stored record and confirm a usable current protector after any recovery or rotation.

Design policy before enabling encryption

Decide at least:

  • operating-system, fixed-data and removable-drive scope;
  • allowed encryption methods and compatibility requirements;
  • TPM-only versus stronger pre-boot authentication according to risk and support capability;
  • recovery password creation and escrow destination;
  • who may retrieve recovery material, for which devices and with what audit evidence;
  • whether standard users may enable encryption outside management;
  • removable-media write/access rules; and
  • exception duration for hardware that cannot meet policy.

Avoid mixing conflicting Group Policy, MDM and local configuration without defining which authority wins. A device that repeatedly changes protectors or encryption settings may have competing policy sources rather than a BitLocker fault.

Pilot the failure paths, not only the happy path

Begin with a small, representative group. Before enforcing encryption, confirm firmware/TPM readiness, partition and disk health, management check-in, escrow access and a known recovery contact.

For each pilot device, verify:

  1. intended policy arrives;
  2. recovery material is escrowed successfully;
  3. encryption completes on every required volume;
  4. normal restart and sign-in work;
  5. an authorised operator can retrieve the matching recovery password;
  6. an unauthorised operator cannot;
  7. a controlled recovery event restores access; and
  8. the used recovery password is rotated and the new record is confirmed.

Expand by device cohort only when failure and support rates are acceptable. A rapid all-device enablement can uncover incompatible firmware, stale directory ownership and absent escrow at the same time.

Treat recovery material like a powerful credential

At recovery, identify both the requester and the physical or managed device. Use the displayed key identifier to select the correct record; never guess from a user’s name alone. Confirm that releasing the key is appropriate for the incident—lost/stolen or potentially tampered equipment may require security handling rather than immediate unlock.

Reveal the recovery password only through the approved channel. Do not paste it into a normal ticket, email, chat transcript, screenshot or permanent device note. Record who requested it, which asset was involved, why recovery occurred and whether access succeeded without retaining the password itself.

After an authorised recovery, determine the trigger. Common causes include firmware or boot changes, TPM changes, altered boot order, hardware replacement and policy changes. Fix the cause, restore the intended protector state, rotate recovery material where supported and verify the new escrow record.

Control planned firmware and hardware work

Before BIOS/UEFI, TPM, boot-manager or relevant hardware changes:

  • identify the exact device and volumes;
  • confirm a matching current recovery password can be retrieved;
  • take any required data backup;
  • use the supported, time-bounded BitLocker suspension path for the change;
  • perform the one approved change; and
  • resume protection and read back encryption, protector and escrow states.

Suspension is not decryption: it temporarily changes how the volume unlocks. Do not leave fleets suspended indefinitely. Never clear a TPM merely to dismiss a warning when the recovery state is unknown.

Handle removable drives separately

BitLocker To Go recovery and custody do not automatically behave like managed operating-system drives in every environment. Decide whether the organisation permits removable storage, which systems must read it, where recovery material is stored and how a departed user’s media is recovered or destroyed.

Test cross-version compatibility and the exact user experience. A policy that blocks unencrypted removable media without providing a usable encryption and recovery workflow can encourage unsafe workarounds.

Close the lifecycle

Offboarding must address data ownership before disabling an account or wiping a device. Transfer required business data, remove personal access, verify recovery custody and choose a documented return, reuse or disposal path.

For reuse, rotate protectors and recovery material under the new ownership model. For disposal, follow the organisation’s verified sanitisation process; do not assume deleting a recovery record or removing a protector erases the data.

The operational scorecard is simple: required volumes encrypted, intended protectors healthy, current recovery material escrowed, retrieval least-privileged and audited, exceptions expiring, and recovered devices returned to a known protected state.