## TL;DR
The key ID identifies the key; the recovery key unlocks the drive. The agent must fetch both, label them explicitly, read only the 48-digit recovery key to the caller, and confirm the key ID matches the one on the user's recovery screen first.

## Steps
1. Fetch the recovery key record and keep the key ID and the recovery key in separate labeled fields.
   Expected: The two values are never mixed in one string.
2. Ask the caller to read the key ID from their recovery screen and match it to the record.
   Expected: The right key for this exact encryption is confirmed.
3. Read the 48-digit recovery key in small groups and have the caller read it back.
   Expected: The caller enters the correct key.
4. Log which key ID was disclosed, to whom, and when.
   Expected: The disclosure is audited.

## When to use
- The agent retrieves BitLocker keys for locked-out users
- Keys are read over the phone or chat
- The device shows a recovery screen with a key ID

## When not to use
- The user unlocks with a PIN or TPM (no key needed)
- The key is delivered through a secure self-service portal
- The agent only reports whether a key exists

## Why this happens
BitLocker shows an 8-character key ID on the recovery screen and stores a 48-digit recovery key; they look related and agents conflate them. Reading the ID to the user wastes the call at best, and reading the wrong key's digits fails the unlock.

## Edge cases
- Multiple keys per device mean the ID match is mandatory, not optional.
- Read-back confirmation catches transcription errors before the user gets frustrated.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cixMyOwm94QRbPhstuXEHQ