BitLocker Recovery: Access and Key Rotation

A BitLocker recovery screen can follow a legitimate hardware or boot change. It can also arrive with very little context: someone calls the helpdesk, gives a computer name and asks for the number that will unlock it.

Treat that request as access to the drive’s data. Verify the requester and the device before retrieving or sharing the recovery information.

Match the person, device and protector

Microsoft’s recovery overview distinguishes the 48-digit recovery password from other recovery mechanisms. Administration screens commonly describe it as a recovery key. Possession of that password can unlock the protected volume.

Ask for the recovery-key identifier shown on the device and match it to the intended device record. Check the asset record and the person’s authority to recover it. A familiar hostname is insufficient when devices have been rebuilt, renamed or reassigned.

Use an established identity-verification route. Do not treat knowledge of the asset’s serial number as proof that the caller is authorised to read its contents.

Record why the device entered recovery if known. Firmware maintenance, a changed component and an unexplained recovered laptop deserve different follow-up. The key should not become a substitute for investigating repeated recovery prompts.

Check who can reveal the password

The Intune BitLocker guidance identifies a Microsoft Entra permission for viewing recovery keys. Viewing the key and running an Intune rotation action involve different permissions.

Test the intended helpdesk role using a non-sensitive test device. Confirm that the operator can perform the required support task and that an account outside the approved role cannot reveal the key.

Avoid granting Global Administrator solely to solve a recovery lookup. Review the narrow role and scope that fit the support responsibility.

When the key is revealed, confirm that the corresponding audit event is available. Microsoft documents audit logging for recovery-key access. The ticket should identify the device, requester, reason and operator, without copying the secret into a broadly readable record.

Deliver the recovery information deliberately

Use the approved support channel after verification. Avoid attaching a screenshot containing the recovery password to a general ticket or team chat. Those records may have a longer life and wider readership than the support interaction.

Have the user confirm whether the recovery succeeds. If the displayed key identifier differs from the record you opened, stop and reconcile the mismatch. Sending every stored key in the hope that one works creates unnecessary disclosure.

Once Windows is accessible, check the device’s current management and encryption state. A successful unlock does not establish that the device has resumed the expected protection or can receive management actions.

For an unexplained physical-access event, agree with the incident owner whether the device should return to ordinary work at all.

Rotate and confirm the replacement

Microsoft provides an Intune BitLocker key-rotation action for the operating system drive on supported Windows devices. Confirm the documented platform, role and BitLocker policy prerequisites before using it.

The support record should distinguish requesting rotation from observing its completion. An offline device cannot provide immediate evidence of a newly applied management action.

Use a controlled test to establish the evidence your team will retain:

Keep identifiers and timestamps in the ordinary record, not the old and new passwords. If rotation fails, leave a specific follow-up task with an owner rather than marking it complete because the request was sent.

Prepare before the next firmware change

Choose a representative test device and rehearse recovery before a planned change that may affect startup trust. Confirm that authorised support staff can find the correct escrowed information while the user is unable to start Windows.

Document the supported maintenance procedure and verify protection afterwards. Repeatedly disclosing a recovery password for the same unresolved fault is a reason to investigate the fault.

Use the Secure Boot maintenance guidance for the wider certificate-change work. Keep the recovery process beside it so a device that takes the unexpected path can be handled without improvising access to its data.

References

• Microsoft — BitLocker recovery overview. Accessed 17 October 2026.
• Microsoft — Manage BitLocker encryption and recovery in Intune. Accessed 17 October 2026.
• Microsoft — Rotate BitLocker recovery keys. Accessed 17 October 2026.