Skip to main content

How to Back Up a BitLocker Recovery Key in Batch Script

The BitLocker Recovery Key is a 48-digit numerical code that acts as the emergency access to your encrypted drive. If the TPM chip fails, if a BIOS update changes the boot seal, if the motherboard is replaced, or if a user forgets their startup password, this key is the only way to unlock the drive. Losing this key means losing access to the data permanently, as there is no master key, no backdoor, and no recovery service. A Batch script can use the manage-bde command to extract and back up recovery keys to files, network shares, or Active Directory, ensuring your safety net is always in place.

This guide will explain how to back up BitLocker recovery keys programmatically.

Why Recovery Key Backup Is Critical​

ScenarioWithout Recovery KeyWith Recovery Key
TPM chip fails or is clearedData permanently lostUnlock drive and re-seal TPM
Motherboard replacedData permanently lostUnlock drive on new hardware
BIOS/firmware update changes boot configurationData permanently lostUnlock and resume BitLocker
Startup password forgottenData permanently lostUnlock and reset password
Drive moved to another computerData permanently lostUnlock on the new machine

Every single one of these scenarios is common in enterprise environments. Hardware failures, motherboard replacements, and firmware updates happen regularly. Without the recovery key, each event results in permanent data loss.

Method 1: Back Up to a Local File with Verification​

This method extracts the recovery key and saves it to a specific location, with verification that the key was actually captured.

@echo off
setlocal

set "Drive=%~1"
set "BackupDir=%~2"

if "%Drive%"=="" (
    echo Usage: %~nx0 ^<drive_letter:^> [backup_directory]
    echo.
    echo Examples:
    echo   %~nx0 C:
    echo   %~nx0 C: E:\KeyBackups
    echo   %~nx0 D: "\\Server\BitLockerKeys"
    endlocal
    exit /b 1
)

if "%BackupDir%"=="" set "BackupDir=%~dp0KeyBackups"

:: Verify admin privileges
net session >nul 2>&1
if errorlevel 1 (
    echo [ERROR] Reading BitLocker protectors requires administrator privileges. >&2
    endlocal
    exit /b 1
)

:: Verify manage-bde is available
where manage-bde >nul 2>&1
if errorlevel 1 (
    echo [ERROR] manage-bde not found. BitLocker is not available on this edition. >&2
    endlocal
    exit /b 1
)

:: Verify BitLocker is enabled on the target drive
manage-bde -status %Drive% 2>nul | findstr /i "Fully Encrypted Encryption.in.Progress" >nul
if errorlevel 1 (
    echo [ERROR] BitLocker is not enabled on %Drive%. No recovery key to back up. >&2
    endlocal
    exit /b 1
)

:: Create backup directory
if not exist "%BackupDir%\" (
    mkdir "%BackupDir%"
    if errorlevel 1 (
        echo [ERROR] Could not create backup directory: %BackupDir% >&2
        endlocal
        exit /b 1
    )
)

:: Generate timestamped backup filename
for /f "delims=" %%t in (
    'powershell -NoProfile -Command "Get-Date -Format ''yyyyMMdd_HHmmss''"'
) do set "Stamp=%%t"

set "BackupFile=%BackupDir%\BitLocker_%COMPUTERNAME%_%Drive:~0,1%_%Stamp%.txt"

echo [INFO] Backing up BitLocker recovery key for %Drive%...

:: =============================================
:: Extract recovery key information
:: =============================================
(
    echo ==================================================
    echo   BITLOCKER RECOVERY KEY BACKUP
    echo ==================================================
    echo.
) > "%BackupFile%"

for /f "delims=" %%t in (
    'powershell -NoProfile -Command "Get-Date -Format ''yyyy-MM-dd HH:mm:ss''"'
) do echo Backup Date:    %%t >> "%BackupFile%"

echo Computer:       %COMPUTERNAME% >> "%BackupFile%"
echo Drive:          %Drive% >> "%BackupFile%"
echo Backed Up By:   %USERNAME% >> "%BackupFile%"
echo. >> "%BackupFile%"
echo --- Recovery Password --- >> "%BackupFile%"
echo. >> "%BackupFile%"

:: Extract only the recovery password protector
manage-bde -protectors -get %Drive% -type recoverypassword >> "%BackupFile%" 2>&1

echo. >> "%BackupFile%"
echo ================================================== >> "%BackupFile%"

:: Verify the backup contains a recovery password
findstr /i "Recovery Password:" "%BackupFile%" >nul 2>&1
if errorlevel 1 (
    echo [WARNING] No recovery password protector found on %Drive%. >&2
    echo The drive may use only TPM or password protection without a recovery key. >&2
    echo Consider adding one: manage-bde -protectors -add %Drive% -recoverypassword >&2
    del "%BackupFile%" 2>nul
    endlocal
    exit /b 1
)

:: Verify the backup file is not empty/corrupt
for %%f in ("%BackupFile%") do (
    if %%~zf lss 100 (
        echo [ERROR] Backup file appears corrupt or incomplete. >&2
        endlocal
        exit /b 1
    )
)

echo [OK] Recovery key saved to: %BackupFile%
echo.
echo [IMPORTANT] Move this file to a secure location immediately:
echo   - USB drive stored in a locked safe
echo   - Encrypted network share with restricted access
echo   - Printed copy in a fireproof safe
echo.
echo [WARNING] Do NOT leave recovery key files on the encrypted drive itself.
echo           If the drive locks, the key file becomes inaccessible.

endlocal
exit /b 0

Why -type recoverypassword is important:​

manage-bde -protectors -get C: without the -type filter shows ALL protectors, including TPM metadata, external key references, and other technical information. The recovery password (the 48-digit code) is the only protector that a human can manually enter during recovery. Filtering by type ensures the backup contains exactly what's needed for emergency access.

Why the backup is verified:​

If the drive has no recovery password protector (e.g., it was set up with TPM-only or password-only protection), the backup file would contain no useful recovery information. The findstr verification catches this and warns the administrator to add a recovery password protector.

Method 2: Back Up to Active Directory​

In a domain-joined environment, recovery keys can be stored directly in the computer's Active Directory object. This is the enterprise-standard approach, as keys are centrally managed, access-controlled by AD permissions, and searchable by domain administrators using the BitLocker Recovery Password Viewer.

@echo off
setlocal

set "Drive=%~1"
if "%Drive%"=="" set "Drive=C:"

net session >nul 2>&1
if errorlevel 1 (
    echo [ERROR] Administrator privileges required. >&2
    endlocal
    exit /b 1
)

where manage-bde >nul 2>&1
if errorlevel 1 (
    echo [ERROR] manage-bde not available. >&2
    endlocal
    exit /b 1
)

:: Verify the machine is domain-joined
powershell -NoProfile -Command ^
    "if ((Get-CimInstance Win32_ComputerSystem).PartOfDomain) { exit 0 } else { exit 1 }" >nul 2>&1

if errorlevel 1 (
    echo [ERROR] This machine is not domain-joined. AD backup requires domain membership. >&2
    echo Use Method 1 (file backup) or Method 3 (Azure AD) instead. >&2
    endlocal
    exit /b 1
)

echo [INFO] Backing up BitLocker recovery key to Active Directory...

:: Find all recovery password protector IDs
set "BackedUp=0"
for /f "tokens=*" %%k in (
    'powershell -NoProfile -Command ^
        "$vol = Get-BitLockerVolume -MountPoint ''%Drive%'' -ErrorAction SilentlyContinue;" ^
        "if ($vol) {" ^
        "    $vol.KeyProtector | Where-Object KeyProtectorType -eq ''RecoveryPassword'' |" ^
        "    ForEach-Object { $_.KeyProtectorId }" ^
        "}"'
) do (
    echo [INFO] Backing up protector: %%k
    manage-bde -protectors -adbackup %Drive% -id %%k
    if not errorlevel 1 (
        echo [OK] Protector %%k backed up to Active Directory.
        set /a "BackedUp+=1"
    ) else (
        echo [ERROR] Failed to back up protector %%k. >&2
        echo Check AD connectivity and permissions. >&2
    )
)

if %BackedUp% equ 0 (
    echo [ERROR] No recovery keys were backed up. >&2
    echo Possible causes: >&2
    echo   - No recovery password protector exists on %Drive% >&2
    echo   - AD DS does not have BitLocker key backup configured >&2
    echo   - Insufficient permissions to write to the computer object >&2
    endlocal
    exit /b 1
)

echo.
echo [OK] %BackedUp% recovery key(s) backed up to Active Directory.
echo [INFO] Retrieve with: Get-ADObject -Filter {objectclass -eq 'msFVE-RecoveryInformation'}

endlocal
exit /b 0

Prerequisites for AD backup:​

  • Machine must be joined to an Active Directory domain.
  • AD DS schema must include BitLocker attributes (present by default in Windows Server 2008 R2+ domains).
  • Group Policy should be configured to require AD backup before enabling BitLocker: Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Store BitLocker recovery information in Active Directory Domain Services.
  • The computer account must have permission to write to its own AD object.

How administrators retrieve keys from AD:​

Domain administrators can search for recovery keys using:

  • Active Directory Users and Computers: Right-click the computer object > Properties > BitLocker Recovery tab (requires BitLocker Recovery Password Viewer RSAT tool installed).
  • PowerShell: Get-ADObject -Filter {objectclass -eq 'msFVE-RecoveryInformation'} -SearchBase "CN=ComputerName,OU=Computers,DC=domain,DC=com" -Properties msFVE-RecoveryPassword

Method 3: Fleet-Wide Recovery Key Backup​

For auditing and ensuring every machine in your fleet has its recovery key backed up, this method collects key backup status to a central CSV.

@echo off
setlocal

set "CSVFile=\\Server\BitLocker\key_backup_status.csv"
set "KeyDir=\\Server\BitLocker\Keys"

if not exist "%CSVFile%" (
    echo "Timestamp","Computer","Drive","HasRecoveryKey","KeyID","BackupStatus" > "%CSVFile%" 2>nul
)

if not exist "%KeyDir%\" mkdir "%KeyDir%" 2>nul

net session >nul 2>&1
if errorlevel 1 (
    echo [ERROR] Administrator privileges required. >&2
    endlocal
    exit /b 1
)

for /f "delims=" %%t in (
    'powershell -NoProfile -Command "Get-Date -Format ''yyyy-MM-dd HH:mm:ss''"'
) do set "Timestamp=%%t"

echo [INFO] Checking BitLocker key backup status for %COMPUTERNAME%...

powershell -NoProfile -Command ^
    "$volumes = Get-BitLockerVolume -ErrorAction SilentlyContinue;" ^
    "if (-not $volumes) {" ^
    "    Write-Output ('\"%Timestamp%\",\"%COMPUTERNAME%\",\"N/A\",\"No BitLocker\",\"N/A\",\"N/A\"')" ^
    "} else {" ^
    "    foreach ($v in $volumes) {" ^
    "        $rp = $v.KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword';" ^
    "        if ($rp) {" ^
    "            foreach ($key in $rp) {" ^
    "                $status = 'BackedUpToFile';" ^
    "                $keyFile = '%KeyDir%\%COMPUTERNAME%_' + $v.MountPoint.Replace(':','') + '_key.txt';" ^
    "                manage-bde -protectors -get $v.MountPoint -type recoverypassword |" ^
    "                    Out-File -FilePath $keyFile -Force;" ^
    "                Write-Output ('\"' + '%Timestamp%' + '\",\"' + '%COMPUTERNAME%' + '\",\"' + $v.MountPoint + '\",\"Yes\",\"' + $key.KeyProtectorId + '\",\"' + $status + '\"')" ^
    "            }" ^
    "        } else {" ^
    "            Write-Output ('\"' + '%Timestamp%' + '\",\"' + '%COMPUTERNAME%' + '\",\"' + $v.MountPoint + '\",\"No\",\"N/A\",\"MISSING - No Recovery Password\"')" ^
    "        }" ^
    "    }" ^
    "}" >> "%CSVFile%" 2>nul

echo [OK] Key backup status recorded for %COMPUTERNAME%.

endlocal
exit /b 0

What to look for in the fleet CSV:​

  • HasRecoveryKey = No: Critical finding. These drives have no recovery password protector. If the TPM fails, data is permanently lost. Add one immediately: manage-bde -protectors -add C: -recoverypassword.
  • BackupStatus = MISSING: The key exists but hasn't been backed up to a central location.
  • Multiple entries per computer: Normal, as there is one per encrypted volume and one per recovery protector (if a key was rotated, there may be an old and new protector).

How to Avoid Common Errors​

Wrong Way: Saving the Key on the Encrypted Drive​

:: USELESS: if the drive locks, you can't access this file
manage-bde -protectors -get C: > C:\BitLocker_Key.txt

The recovery key exists to unlock the drive when you can't access it normally. Saving the key on the encrypted drive defeats its entire purpose.

Correct Way: Save to an external location: USB drive, network share, Active Directory, Azure AD, or a printed physical copy.

Wrong Way: Backing Up All Protectors Instead of Just Recovery Password​

:: NOISY: includes TPM metadata, external key paths, and other technical data
manage-bde -protectors -get C: > backup.txt

The full protector dump includes information about the TPM binding, which is not useful for manual recovery and adds confusing technical detail.

Correct Way: Use -type recoverypassword to extract only the 48-digit code that a human needs to type during recovery.

Problem: No Recovery Password Protector Exists​

If BitLocker was enabled with TPM-only or password-only protection without adding a recovery password, there is nothing to back up, and no way to recover if the primary protector fails.

Solution: Check for the protector's existence before backup (as shown in Method 1), and add one if missing:

manage-bde -protectors -add C: -recoverypassword

Problem: AD Backup Fails Silently​

manage-bde -protectors -adbackup may report success but fail to write to AD if the schema is not configured, the computer object lacks write permissions, or network connectivity is interrupted.

Solution: After backup, verify the key exists in AD using the retrieval methods documented in Method 2. Configure Group Policy to require AD backup before BitLocker can be enabled.

Problem: Old Keys After Rotation​

When you use a recovery key to unlock a drive and then generate a new one, the old key remains as a protector unless explicitly removed. The backup may contain the old key instead of the current one.

Solution: After rotating a key, remove the old protector and re-run the backup:

:: List all recovery password protectors to find the old one
manage-bde -protectors -get C: -type recoverypassword

:: Remove the old protector by ID
manage-bde -protectors -delete C: -id {OLD-KEY-ID}

:: Back up the new key
manage-bde -protectors -get C: -type recoverypassword > new_key.txt

Best Practices and Rules​

1. Never Store Keys on the Encrypted Drive​

The key's purpose is to unlock the drive when normal access fails. If the key is on the drive, it is inaccessible exactly when you need it.

2. Use Multiple Backup Locations​

A single backup location is a single point of failure. For critical systems:

  • Back up to Active Directory or Azure AD (primary)
  • Save a file copy to a secured network share (secondary)
  • Print a physical copy and store in a safe (tertiary)

3. Rotate Keys After Recovery Use​

If a recovery key is used to unlock a drive, consider it exposed. Generate a new recovery password and back it up immediately:

manage-bde -protectors -add C: -recoverypassword

Then back up the new key using Method 1 or 2.

4. Verify Backups Are Complete​

After backing up, verify the backup file contains the 48-digit recovery password (not just headers and metadata). Method 1 includes this verification.

5. Restrict Access to Key Backup Locations​

Recovery key files and network shares must have strict access controls. Only IT security personnel should be able to read the keys. On network shares, use NTFS permissions limited to the security team. In AD, the BitLocker Recovery tab is visible only to domain administrators by default.

6. Schedule Regular Backup Audits​

Run Method 3 monthly to verify every encrypted machine has its recovery key backed up centrally. New machines, re-encrypted drives, and rotated keys can create gaps in your key inventory.

Conclusions​

Backing up BitLocker recovery keys is the most critical follow-up action after enabling encryption. Without the recovery key, every hardware failure, firmware update, or password reset on an encrypted drive results in permanent data loss. By automating key extraction with proper verification, centralizing backups in Active Directory or secured network shares, and auditing backup completeness across your fleet, you ensure that encryption protects your data without creating an availability risk.

Table of Contents