Manage BitLocker recovery keys and user self-service options
BitLocker protects data when a Windows device is lost, stolen, or locked by a recovery event. Recovery also creates an operational responsibility: users and support teams need a secure way to retrieve recovery information, verify the request, and prevent a disclosed key from remaining valid. In this unit, you configure recovery key escrow, enable controlled self-service, and apply key rotation practices that reduce helpdesk effort without weakening device protection.
| Configuration step | Purpose | Result |
|---|---|---|
| Escrow recovery information to Microsoft Entra ID | Store recovery passwords in a managed directory location | Administrators and eligible users can retrieve keys when recovery occurs |
| Require backup before encryption starts | Prevent unmanaged encryption from starting without a recoverable key | Devices do not encrypt until recovery information is available |
| Enable user self-service only for trusted scenarios | Let users retrieve keys for their managed devices | Users resolve common lockout events with less helpdesk dependency |
| Rotate recovery passwords after disclosure | Replace a recovery password after it is viewed or used | A previously exposed key no longer unlocks the device |
Configure escrow so recovery keys are available when users need them
Recovery key escrow stores BitLocker recovery information in a central, managed location. Escrow means that the device backs up the recovery password to a trusted service before or during encryption. For cloud-managed Windows devices, Microsoft Entra ID provides the directory location that Intune uses to store and display BitLocker recovery information.
Escrow matters because a recovery password is sensitive. A user needs it only when BitLocker cannot unlock the drive through the normal protector, such as the Trusted Platform Module (TPM), a startup PIN, or a startup key. If the organization does not escrow recovery information, the helpdesk might not be able to unlock the device without data loss.
Use Intune BitLocker policy to save recovery information to Microsoft Entra ID and to require the device to store that information before BitLocker enables protection. This approach supports both standard and silent encryption scenarios because the recovery path exists before the user experiences a lockout.
| Recommended configuration | Why it helps | Setting area |
|---|---|---|
| Save BitLocker recovery information to Microsoft Entra ID | Keeps recovery information with the managed device record | Recovery information storage |
| Require recovery information to be stored before BitLocker starts | Prevents encryption when no managed recovery path exists | Pre-encryption backup |
| Require a 48-digit recovery password | Supports the recovery screen and helpdesk retrieval workflow | Recovery password format |
| Define who can retrieve keys and how requests are verified | Reduces unauthorized disclosure of recovery information | Recovery planning |
Important
Treat each recovery password as sensitive information. Anyone who has the recovery password can unlock the encrypted drive. Store recovery information only in approved locations and limit access through role-based access control.
Enable self-service recovery with the right guardrails
Self-service recovery allows a user to retrieve the BitLocker recovery key for a managed work or school device without contacting the helpdesk. This option is useful when the user has access to another trusted device and can sign in with the same work or school account.
The Company Portal recovery experience gives the user a direct path to the key for an enrolled, BitLocker-encrypted device. The user signs in, selects the locked Windows device, and selects Get recovery key. The service displays the key for a limited session, which reduces the chance that the key remains visible on a shared or unattended screen.
Self-service does not replace helpdesk recovery. Some recovery events still need support validation, especially when the device ownership is unclear, the key is missing, the user cannot sign in, or the organization restricts user access to recovery keys. In those cases, the helpdesk verifies the user, locates the device, retrieves the key, and records the reason for recovery.
| Recovery path | Best fit | Guardrail |
|---|---|---|
| Company Portal website | User has an enrolled, BitLocker-encrypted work or school device | User signs in with the registered work or school account |
| Company Portal app | User uses a supported mobile or desktop Company Portal app | User selects the managed Windows device before viewing the key |
| Microsoft Entra self-service | Device is associated with the user in Microsoft Entra ID | Tenant settings control whether users can view keys for owned devices |
| Helpdesk recovery | User cannot use self-service or the request needs validation | Support verifies identity, device ownership, recovery reason, and key ID |
A clear self-service policy also explains when users need helpdesk assistance. For example, a user contacts support when the Company Portal does not show the device, the key is not available, the recovery screen shows a key ID that does not match or the device belongs to another user.
Retrieve keys securely through Intune and Microsoft Entra roles
Administrative recovery requires the correct permissions. Intune can show BitLocker key IDs and recovery keys for managed Windows devices and each key access creates an audit record. Audit records help security teams understand who viewed a key, when the key was viewed and which recovery process triggered the request.
Use the least privilege principle when delegating recovery access. Least privilege means that each administrator has only the access needed for their task. Built-in roles such as Helpdesk Administrator or Cloud Device Administrator can read BitLocker recovery keys in Microsoft Entra ID, and custom roles can include the specific microsoft.directory/bitlockerKeys/key/read permission.
| Admin task | Where to perform it | Permission or role consideration |
|---|---|---|
| View recovery keys for an Intune-managed device | Microsoft Intune admin center, device Recovery keys page | Requires permission to read BitLocker keys |
| Assist a user during recovery | Microsoft Intune admin center or Microsoft Entra admin center | Use helpdesk roles that allow key retrieval and device lookup |
| Scope access for a support team | Microsoft Entra roles or custom roles | Grant only key read access and device visibility needed for support |
| Review disclosure events | Microsoft Entra audit logs | Monitor key read activity under key management events |
A reliable helpdesk process starts with identity verification.
- The support technician:
- Confirms the user
- Records the device name
- Records the recovery key ID from the BitLocker recovery screen
- Locates the matching recovery password
- Documents the reason for recovery and provides the 48-digit value carefully
This process reduces mistakes and supports later investigation.
Rotate recovery passwords after disclosure
Recovery password rotation replaces the current recovery password with a new one. Rotation is important because a recovery password becomes disclosed when a user, administrator, or technician views it. After disclosure, the old value should not remain reusable.
Intune supports remote BitLocker key rotation for supported Windows devices. An administrator selects the device, chooses the BitLocker key rotation remote action and confirms the request. The device generates a new recovery password and stores it in Microsoft Entra ID according to the BitLocker policy configuration.
Automatic rotation provides another layer of protection. When policy enables client-driven recovery password rotation, Microsoft Entra joined and hybrid joined devices can rotate the recovery password after the password is used. This behavior limits the value of a copied or recorded key after recovery completes.
| Rotation trigger | Action | Security benefit |
|---|---|---|
| A helpdesk technician reads a recovery key | Start BitLocker key rotation in Intune | Prevents reuse of a key shared during support |
| A user retrieves a key through self-service | Rely on configured password rotation behavior | Reduces risk from key exposure during lockout |
| A device changes owner or returns from service | Rotate the recovery password | Removes access tied to previous support or ownership events |
| A key appears in an incident review | Rotate immediately and investigate the access event | Limits exposure while the root cause is reviewed |
Note
Configure automatic rotation with Configure Recovery Password Rotation in the BitLocker section of the Windows BitLocker policy. The setting options are Not configured or Refresh off (default), which does not rotate the recovery password automatically after recovery; Refresh on for Entra ID-joined devices, which rotates after a recovery password is used on Microsoft Entra joined devices; and Refresh on for both Entra ID-joined and hybrid-joined devices, which enables rotation across all supported join types. This setting requires Windows 10 version 1909 or later, or Windows 11. Manual key rotation through the Intune remote action remains available regardless of this setting.
Key rotation works best when it is part of the recovery process rather than an afterthought. Document the expected trigger, assign the correct Intune role and review audit logs after recovery activity. This practice keeps recovery available while protecting the organization from stale, reused or overexposed recovery passwords.
Note
Microsoft Entra ID stores BitLocker recovery keys with the device record. If a device shows no key, confirm that policy backs up recovery information before encryption and that the device checks in successfully.
Check your configuration
Use the following checklist to validate the recovery experience before you deploy BitLocker broadly.
| Check | Success looks like this |
|---|---|
| Recovery information escrow | A test device shows a BitLocker key ID and recovery key in the admin center |
| Self-service access | A test user can retrieve the key only for an eligible managed device |
| Helpdesk access | A support role can locate the device and read the recovery key without broader admin access |
| Audit trail | Key retrieval appears in audit logs with the requesting user and key activity |
| Rotation | A disclosed key rotates through policy or the Intune remote action |