BitLocker Recovery Explained – Restore your access NOW!

BitLocker recovery involves the procedure of regaining access to a drive that is protected by BitLocker, especially when it cannot be accessed normally.

Options available to restore the access:

During the recovery process, various options are available to restore access to the drive.

• During the recovery process, users have the option to provide the recovery password to unlock the encrypted drive. If permitted by the organization’s policies, users may have the ability to print or save the recovery password. In such cases, they can make use of a Microsoft account for online login. By logging in with their Microsoft account, users can enter the 48-digit recovery password that they had previously printed or saved on a USB drive.It’s important to note that the option to store a recovery password online using a Microsoft account is only available when BitLocker is used on a PC that is not a member of a domain. This feature provides users with flexibility in securely accessing their recovery password when needed, ensuring a smoother recovery process for non-domain member PCs.
• Data recovery companies have the capability to open encrypted drives using their authorized credentials. However, if the encrypted drive is an operating system drive, an additional step is required. The data recovery agent must first mount the drive as a data drive on a different machine before it can be unlocked and accessed. This process allows the data recovery company to handle the encrypted drive as a separate data storage device, enabling them to perform necessary recovery operations while ensuring the security of the data. By mounting the drive on a different machine, the data recovery agent can work on the drive without affecting the original system’s operation, providing a specialized environment for data retrieval.
• The recovery password stored in Active Directory Domain Services (AD DS) can be accessed by a domain administrator, who can utilize it to unlock the BitLocker-protected drive. It is recommended to store recovery passwords in AD DS to ensure that IT experts have the necessary access to recovery passwords in case they are needed. To enable this recovery method, it is essential to configure the BitLocker group policy settings accordingly. In the Local Group Policy Editor, navigate to Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives. From there, you can specify the options for restoring BitLocker-protected operating system drives, including the storage of recovery passwords in AD DS. By enabling this policy setting and storing recovery passwords in AD DS, organizations can ensure that authorized personnel have the means to retrieve and utilize recovery passwords when necessary, streamlining the process of unlocking BitLocker-protected drives in the event of recovery scenarios.

What causes BitLocker recovery to appear?

The following are some particular situations that will cause BitLocker to enter recovery mode when attempting to boot the operating system drive:

TPM related issues

• On TPM 1.2 devices, changing the BIOS or firmware boot device order has an impact on BitLocker recovery. On TPM 2.0-enabled devices, on the other hand, do not start BitLocker recovery in this situation. TPM 2.0 does not view a firmware change in boot device order to be a security issue because the OS Boot Loader is not compromised.
• Too many times entering the personal identification number (PIN) incorrectly, resulting in the TPM’s anti-hammering logic being activated. By prohibiting PIN submissions until a predetermined amount of time has passed, anti-hammering logic refers to software or hardware solutions that make brute force attacks on a PIN more difficult and expensive.
• The TPM can be turned off, disabled, deactivated, or cleared.
• TPM firmware upgrade.
• Maintaining the TPM’s operating system secrecy. It is possible to utilize specific BIOS or UEFI settings to stop the operating system from enumerating the TPM. This setting can make the TPM invisible to the operating system when it is enabled. The BIOS and UEFI secure boot are disabled when the TPM is buried, and the TPM is also unresponsive to software operations.
• Modifying the TPM validation profile’s Platform Configuration Registers (PCRs). Including PCR[1], for example, would cause BitLocker to measure most changes to BIOS settings, causing BitLocker to enter recovery mode even when non-boot critical BIOS parameters changed.
• The replacement of the motherboard with a new one that has a new TPM.
• Failing to pass the TPM self-test.
• Failing to adhere to the necessary Trusted Computing Group standards for a client computer’s BIOS, UEFI firmware, or option ROM component. For instance, a non-compliant implementation can store erratic data (such as time) in the TPM measures, resulting in various readings at startup and forcing BitLocker into recovery mode.
• Making a non-zero change to the TPM’s storage root key’s usage authorization.

General issues

• A computer that utilizes BitLocker Drive Encryption or a tablet or phone that only employs BitLocker Device Encryption will reboot and enter BitLocker recovery mode when an attack is detected. The Interactive logon: Machine account lockout threshold Group Policy setting, which can be located in Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options, allows administrators to enable this capability. To restrict the amount of unsuccessful password attempts before the device enters Device Lockout mode, they can also use the MaxFailedPasswordAttempts policy in Exchange ActiveSync, which is similarly customizable through Microsoft Intune.
• Putting the CD or DVD drive before the hard drive in the BIOS startup sequence, then inserting or removing a CD or DVD.
• Using a different keyboard that does not accurately enter the PIN or whose keyboard map does not match the pre-boot environment’s keyboard map. This issue may prohibit improved PINs from being entered.
• Inserting the BitLocker-protected drive into a new computer.
• Losing the USB flash drive with the startup key if startup key authentication is enabled.
• Changing the Windows Boot Manager’s (Bootmgr) test signing settings or deactivating the code integrity check.
• Pressing the F8 or F10 key while the computer is booting. (or any key to access the BIOS)
• Updating the firmware on add-in cards, or adding or uninstalling add-in cards (such video or network cards).
• Using a BIOS hot key to switch the hard drive’s position as the first boot device during the boot process.
• If using USB-based keys instead of a TPM, disable support for accessing the USB device in the pre-boot environment from the BIOS or UEFI firmware.
• Failure to use the hard drive before a network drive to boot.
• A portable computer’s docking or undocking process. In some circumstances, the docking condition of the portable computer is a component of the system measurement and must be consistent in order to authenticate the system status and unlock BitLocker (depending on the computer manufacturer and the BIOS). When BitLocker is activated, a portable computer must be attached to its docking station. When BitLocker is disabled, the same requirement could apply. On the other hand, when BitLocker is enabled, a portable computer may need to be disconnected from its docking station before it can be unlocked.
• Changes to the disk’s NTFS partition table, such as creating, removing, or resizing a primary partition.
• The relevant boot metrics alter when important early startup components, such as a BIOS or UEFI firmware upgrade, are upgraded.
• When PIN authentication is enabled, forgetting the PIN.
• Updating the firmware on the option ROM.
• Adding or deleting hardware, such as installing a new card in the computer, which includes some PCMIA wireless cards.
• Removing, inserting, or totally emptying the charge on a portable computer’s smart battery.
• Changes to the disk’s master boot record.
• Changes to the disk’s boot manager.

In certain situations, such as planned hardware or firmware changes / upgrades, it is possible to temporarily suspend BitLocker protection to prevent the initiation of the recovery process. It is important to understand that suspending BitLocker does not compromise the encryption of the drive, ensuring that its security remains intact. Once the intended task is completed, BitLocker security can be promptly resumed. The advantage of suspending and resuming BitLocker is that the encryption key is resealed without requiring the entry of the recovery key.

By activating the BitLocker network unlock feature, a secondary authentication factor can be used in situations where computers lack an on-premises user. This additional authentication method is particularly useful when software maintenance requires a computer restart and two-factor authentication is in place.

Recovery is often associated with unplanned or undesirable events. However, it is important to note that recovery can also be a deliberate outcome in certain production scenarios, such as access control management. For instance, when desktop or laptop devices are reassigned to different departments or employees within the company, BitLocker can be configured to initiate recovery before the machine is handed over to a new user.

Testing Bitlocker recovery

Before implementing a comprehensive BitLocker recovery process, it is recommended to perform tests to assess the functionality of the recovery procedure for both end users and administrators. These tests help ensure that users can effectively navigate the recovery process in the event of a recovery situation. Administrators can assist end users in obtaining the recovery password smoothly. To expedite the recovery process during testing, the manage-bde.exe command line option “-forcerecovery“ can be utilized. This option helps streamline the recovery process and allows for a more efficient evaluation of the recovery functionality.

How to force the recovery for a local computer?

1. Click on the Start button and type “cmd” in the search bar.
2. Next, right-click on “cmd.exe” or “Command Prompt” and select “Run as administrator”.
3. Once the command prompt window opens, you can enter the following command:

manage-bde.exe -forcerecovery <BitLockerVolume>

How to force the recovery for a remote computer?

1. Click on the Start button and type “cmd” in the search field.
2. Next, right-click on “cmd.exe” or “Command Prompt” and choose the option “Run as administrator”.
3. Once the command prompt window opens, you can proceed by entering the following command:

manage-bde.exe -ComputerName <RemoteComputerName> -forcerecovery <BitLockerVolume>

Preparation for the recovery process

Before initiating the BitLocker recovery process, it is crucial to consult the latest guidelines provided by the company regarding the retrieval of sensitive data. This includes understanding the procedures in place for handling forgotten Windows passwords and resetting smart card PINs. Adhering to these best practices and utilizing available resources, such as knowledgeable individuals and tools, can greatly assist in developing an effective BitLocker recovery model.

For organizations utilizing BitLocker Drive Encryption and BitLocker To Go to protect data on multiple computers and removable drives running Windows 11, Windows 10, Windows 8, or Windows 7 (including Windows to Go), implementing the Microsoft BitLocker Administration and Monitoring (MBAM) Tool version 2.0 is recommended. MBAM, included in the Microsoft Desktop Optimization Pack (MDOP) for Microsoft Software Assurance, facilitates the deployment and management of BitLocker implementations. It allows administrators to configure and monitor encryption for operating systems and fixed drives. MBAM prompts users before encrypting fixed drives and securely stores recovery keys for both fixed and removable drives, simplifying recovery management. MBAM can be used as a standalone solution or integrated as part of a Microsoft System Center implementation.

During the BitLocker recovery process, users can regain access to protected data by utilizing a recovery password. It is important to consider both self-recovery options and the availability of recovery password retrieval mechanisms for the organization.

When the process for recovery has been determined:

• Become familiar with how a recovery password can be retrieved:

1. Self-recovery
2. Recovery password retrieval

• Determine a series of steps for post-recovery, including analyzing why the recovery occurred and resetting the recovery password:

1. Post-recovery analysis

Self-recovery

In certain situations, individuals may have a hard copy or a USB flash drive containing the recovery password, allowing them to perform self-recovery. It is important for the organization to establish a self-recovery policy outlining the appropriate procedures. If self-recovery involves using a password or recovery key stored on a USB flash drive, users should be cautioned against storing the USB flash drive in close proximity to the computer, especially while traveling. For example, if both the PC and the recovery items are kept together in a bag, an unauthorized individual could easily gain access to the PC and the recovery information.

Another policy to consider is requiring users to contact the Helpdesk either before or after performing self-recovery in order to verify the underlying issue and ensure proper documentation of the recovery process. This additional step can help ensure that the recovery is performed correctly and that any potential underlying issues are addressed.

Recovery password retrieval

Users should have the ability to retrieve the recovery password from an online source if it is not already documented or stored on a USB flash drive. If the PC is part of a domain, the recovery password can be stored in AD DS (Active Directory Domain Services). However, it is important to note that the recovery password is not automatically backed up to AD DS. Before installing BitLocker on the PC, the appropriate group policy settings must be configured to enable the backup of the recovery password to AD DS.

To access the BitLocker group policy settings, navigate to Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption in either the Local Group Policy Editor or the Group Policy Management Console (GPMC). These settings determine the recovery procedures that can be used to regain access to a BitLocker-protected drive in case an authentication method fails or cannot be used. By configuring these settings, administrators can ensure that recovery options are available and properly documented for each BitLocker-protected drive.

• Choose how BitLocker-protected operating system drives can be recovered
• Choose how BitLocker-protected fixed drives can be recovered
• Choose how BitLocker-protected removable drives can be recovered

To determine the BitLocker recovery details that should be stored in Active Directory Domain Services, choose the option “Save BitLocker recovery information to Active Directory Domain Services” within the applicable policies. If the objective is to prevent users from activating BitLocker until the drive’s recovery information has been successfully backed up to AD DS and the machine is connected to the domain, select the checkbox labeled “Do not enable BitLocker until recovery information is stored in AD DS.”

The BitLocker Recovery Password Viewer for Active Directory Users and Computers tool allows domain administrators to retrieve BitLocker recovery passwords for specific computer objects in Active Directory.

The provided list can be used as a framework for creating a procedure to recover lost passwords. In this particular example, the BitLocker Recovery Password Viewer for Active Directory Users and Computers utility is utilized.

• Note the user’s computer’s name.
• Establish the user’s identity
• Search AD DS for the recovery password.
• Collect data to determine the cause of the recovery
• Send the recovery password to the user.

Note the user’s computer’s name

To locate the recovery password in AD DS, follow these steps:

1. Search for the user’s PC in Active Directory by its name.
2. If the user is unsure of the computer’s name, in the BitLocker Drive Encryption Password Entry user interface, ask them to read the first word of the Drive Label. Typically, when BitLocker was enabled, this word was used as the computer’s name and is likely still the same today.

Establish the user’s identity

It is crucial to verify the authenticity of the person requesting the recovery password and ensure that the computer associated with the given name belongs to them.

In order to maintain security and prevent unauthorized access, it is important to perform the following checks:

1. Verify the identity of the individual requesting the recovery password to confirm that they are the legitimate user of the computer.
2. Validate the ownership of the computer provided by the user, ensuring that it belongs to them and not someone else.

These measures are necessary to protect sensitive data and ensure that recovery passwords are only provided to authorized users.

Establish the user’s identity

Find the computer object in AD DS that has the same name. Since computer object names are included in the AD DS global catalogue, even in a multi-domain forest, the item should be able to be found.

Various recovery passwords

When multiple recovery passwords are stored under a computer object in AD DS, the BitLocker recovery information object includes the date when each password was created.

To ensure the correct password is provided and prevent the user from supplying the wrong one, it is advisable to ask them to read the eight-character password ID displayed in the recovery console.

By executing a query using this password ID, the corresponding recovery password associated with the encrypted volume can be retrieved. The password ID serves as a unique identifier that is linked to each recovery password stored in AD DS.

Collect data to determine the cause of the recovery

Before providing the user with the recovery password, it is important to gather information that will assist in determining the reason for the recovery requirement. This data will be valuable during the post-recovery investigation to analyze the root cause.

By collecting relevant information upfront, it becomes possible to examine the underlying factors contributing to the need for recovery. This proactive approach enables a thorough investigation and helps prevent similar incidents in the future.

Send the recovery password to the user

Due to the length of the recovery password, which consists of 48 digits, it may be necessary for the user to write it down or enter it on a different computer. This is because such a lengthy password can be challenging to remember or input accurately.

When utilizing MBAM (Microsoft BitLocker Administration and Monitoring) or Configuration Manager BitLocker Management, the recovery password will be generated once it is retrieved from the respective database (MBAM or Configuration Manager). This approach is implemented to mitigate the security risks associated with using an unmanaged password.

By generating the recovery password from a managed database, the security of the BitLocker encryption process is enhanced, ensuring better protection for the encrypted data.

Post-recovery analysis

When a volume is unlocked using a recovery password, two important actions take place. First, an event is logged in the event log to record this activity. Second, the platform validation measurements in the Trusted Platform Module (TPM) are reset to the current configuration.

Unlocking the volume with the recovery password makes the encryption key available for dynamically encrypting data being written to the volume and decrypting data being read from it. Regardless of the method used to grant access, BitLocker operates in the same manner once the volume is unlocked.

If an administrator notices that a computer consistently requires the recovery password to be unlocked, they may choose to conduct a post-recovery analysis. This analysis aims to identify the underlying cause of the repeated recovery requirements. Additionally, the administrator may consider refreshing BitLocker platform validation to prevent the user from having to enter the recovery password during each boot-up of the computer. For further details refer to:

• Identify the recovery’s root causes.
• Fix the root issue

Identify the recovery’s root causes

In the event of a user requiring disc recovery, it is crucial to promptly identify the underlying cause. Conducting a thorough analysis of the computer’s condition and investigating any potential manipulation can reveal threats that pose significant risks to company security.

For the organization, the following inquiries should be examined and addressed:

1. Determine if the end user needs to bring the computer holding the recovered disc on-site for further investigation, as remote investigation may not be sufficient in certain cases.
2. Identify the active BitLocker protection mode—TPM,TPM + PIN, TPM + startup key, or startup key only—and determine the current PCR profile used by the PC.
3. Determine if the recovery was triggered due to a lost startup key or a forgotten PIN. If a missing token exists, ascertain its possible location.
4. Investigate whether an update to the boot file triggered the recovery, especially if TPM mode was active.
5. Determine if it was the result of malicious software or a planned human activity, such as a BIOS upgrade.
6. Determine the last successful startup time of the computer and analyze any changes that may have occurred since then.
7. Assess whether the user may have used potentially harmful software or left the machine unattended since the previous successful startup.

It is essential to address these questions to understand the root cause of the disc recovery and take appropriate actions to mitigate risks and prevent future incidents.

You can check the current settings and protection mode using the BitLocker command-line tool to assist with these inquiries:

manage-bde.exe -status

Look for occurrences in the event log that can assist explain why recovery was started (for instance, if a boot file update was place). These two functions can both be carried out remotely.

Fix the root issue

After identifying the root cause of the recovery, it is necessary to reset the BitLocker protection to prevent further recovery prompts during startup.

The specifics of this reset process may vary depending on the underlying reason for the recovery. If the root cause cannot be determined or if there is suspicion of malicious software or a rootkit infecting the machine, the helpdesk should follow best-practice virus policies to respond appropriately.

By resetting the BitLocker protection, the system can be restored to a secure state, reducing the risk of recurring recovery incidents. Implementing proper virus policies ensures that any potential threats are addressed effectively and helps safeguard the integrity of the machine and the organization’s overall security.

• Unknown PIN
• Lost startup key
• Modifications to the boot files

Unknown PIN

To stop BitLocker from starting recovery each time the machine is restarted if a user has forgotten the PIN, the PIN must be reset while logged in to the computer.

To prevent continued recovery due to an unknown PIN

1. Utilise the recovery password to unlock the machine.
2. Set the PIN back:
   a. Hold down the drive selection while choosing Change PIN.
   b. Reset a lost PIN may be done via the BitLocker Drive Encryption dialogue. Admin credentials must be supplied now if the account used to sign in is not an administrator account.
   c. Give and confirm the new PIN to be used in the PIN reset dialogue box before choosing Finish.
3. You can use the new PIN to unlock the drive the next time.

Lost startup key

The USB flash drive must be opened using the recovery key if the USB flash drive containing the startup key has been lost. Then, a new startup can be established.

To avoid further recovery as a result of a misplaced starting key

1. Log on to the lost startup key PC as an administrator.
2. Activate Manage BitLocker.
3. Select Save after inserting a clean USB device onto which the key will be copied and choosing Duplicate start up key.

Modifications to the boot files

If there is a change in the firmware, it can result in an error. As a best practice, it is recommended to disable BitLocker before performing any firmware modifications. Once the firmware upgrade is completed, BitLocker protection should be reactivated.

Suspending BitLocker prevents the machine from entering recovery mode. If firmware modifications were made while BitLocker protection was enabled, the recovery password can be used to unlock the drive. However, it’s important to note that the platform validation profile will be modified to prevent future recovery prompts.

To summarize:

1. Disable BitLocker before performing firmware modifications to prevent errors.
2. After the firmware upgrade, reactivate BitLocker protection.
3. Suspending BitLocker during firmware changes prevents recovery mode.
4. If modifications were made while BitLocker was enabled, use the recovery password to unlock the drive.
5. The platform validation profile will be adjusted to prevent future recovery prompts.

Following these steps ensures a smoother firmware upgrade process while maintaining the security and integrity of BitLocker protection.

Windows RE and BitLocker Device Encryption

If the Windows Recovery Environment (Windows RE) has been modified, such as disabling the TPM, the BitLocker-protected drives will remain locked until the BitLocker recovery key is provided. In cases where Startup Repair cannot run automatically from the PC, and Windows RE needs to be manually started from a repair disk, the BitLocker recovery key becomes essential to unlock the BitLocker-protected drives.

During a “Remove everything” reset initiated from Windows RE on a system using TPM + PIN or Password for OS drive protection, the BitLocker recovery key will also be requested. If BitLocker recovery is initiated on a keyboardless device with TPM-only security, Windows RE, not the boot manager, will prompt for the BitLocker recovery key. Once the recovery key is entered, Windows RE troubleshooting tools can be accessed, or Windows can be launched normally.

The BitLocker recovery screen displayed in Windows RE includes accessibility features like a narrator and an on-screen keyboard to assist in entering the BitLocker recovery key. However, these tools may not be available if the BitLocker recovery key is requested by the Windows boot manager.

To enable the narrator during BitLocker recovery in Windows RE, press Windows + CTRL + Enter. To open the on-screen keyboard, tap a text input control.

These features aim to provide assistance and accessibility options during the BitLocker recovery process within the Windows Recovery Environment.

BitLocker recovery screen

During the BitLocker recovery process, Windows displays a personalized recovery message to the user. This message aims to provide helpful information and offers clues to locate the location where a recovery key can be found. These enhancements are specifically designed to assist users in successfully navigating the BitLocker recovery process and recovering access to their encrypted data.

Customised recovery message

Starting from Windows 10, version 1511, BitLocker Group Policy settings offer users the ability to set up a personalized recovery message and URL on the BitLocker recovery screen. This feature allows for the inclusion of specific details like the BitLocker self-service recovery portal address, the internal IT website, or a support hotline number.

To configure this policy, you can utilize Group Policy Objects (GPO) by navigating to Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives > Configure pre-boot recovery message and URL.

Alternatively, this feature can also be configured using mobile device management (MDM), including Intune, by leveraging the BitLocker Configuration Service Provider (CSP).

<LocURI>./Device/Vendor/MSFT/BitLocker/SystemDrivesRecoveryMessage</LocURI>

These options provide administrators with the flexibility to customize the recovery message and provide relevant information or resources to users during the BitLocker recovery process.

Example of a customized recovery screen:

Hints for BitLocker recovery keys

Starting from Windows 10, version 1903, notable improvements have been implemented in BitLocker metadata. These enhancements involve the inclusion of additional information pertaining to the backup of the BitLocker recovery key, such as the backup’s time and location.

It’s important to note that this specific information is not accessible through the user interface (UI) or any public application programming interface (API). Instead, it is exclusively utilized by the BitLocker recovery screen to provide hints that aid users in locating the recovery key for a particular volume.

On the recovery screen, these hints are displayed, indicating the specific location where the recovery key has been saved. These hints are visible on both the modern (blue) and legacy (black) recovery screens, and they are applicable to both the boot manager recovery screen and the Windows Recovery Environment (WinRE) unlock screen.

By presenting these hints, the BitLocker recovery screen assists users in identifying the potential location where they can find the recovery key, thereby facilitating the recovery process.

During the recovery process, specific rules govern the order in which hints are displayed to assist users in locating the recovery key. These rules are as follows:

1. If a custom recovery message has been configured using Group Policy Objects (GPO) or Mobile Device Management (MDM), it is always displayed to the user.
2. A generic hint is always shown as part of the hint sequence.
3. If multiple recovery keys exist on the volume, the last-created recovery key that has been successfully backed up takes precedence in the hint sequence.
4. Recovery keys that have been successfully backed up are prioritized over keys that have never been backed up.
5. Backup hints for remote locations are prioritized in the following order: Microsoft Account, Azure AD, and Active Directory.
6. If a recovery key has been both printed and saved to a file, a combined hint is displayed, indicating the user should look for a printout or a text file containing the key.
7. If multiple backups of the same type (remote vs. local) have been performed for the same recovery key, the backup information with the latest backed-up date is given priority in the hint sequence.
8. There is no specific hint for recovery keys saved to an on-premises Active Directory. In such cases, either a custom message (if configured) or a generic message stating “Contact your organization’s help desk” is displayed.
9. If there are two recovery keys on the disk, but only one has been successfully backed up, the system prompts the user to provide the backed-up key, even if the other key is newer.

These rules ensure that the most relevant hints are presented to the user during the recovery process, increasing the likelihood of successfully locating the required recovery key.