How to Set Up BitLocker Encryption Properly

This sets up full-disk encryption with BitLocker properly — with particular attention to the one step people most commonly skip and later regret: actually saving the recovery key somewhere external and durable.

Step 1: confirm your system meets the requirements

BitLocker works best with a TPM 2.0 chip present and enabled in firmware — check your current status:

Get-Tpm

TpmPresent      : True
TpmReady        : True
TpmEnabled      : True

If TpmPresent is False, check your system BIOS/UEFI settings — many machines have a TPM chip physically present but disabled by default, and BitLocker (or a device-encryption feature using it) may need it explicitly enabled there first.

Step 2: enable BitLocker on your system drive

Settings → Privacy & Security → Device Encryption (on machines meeting the modern device encryption requirements), or for more control:

Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -UsedSpaceOnly

-UsedSpaceOnly encrypts only currently-used disk space rather than the entire drive including empty space — considerably faster on a mostly-empty drive, at the minor cost of newly-written data being encrypted as it’s written rather than the whole disk being pre-encrypted upfront. For maximum thoroughness on an older drive that’s had unencrypted data on it historically, omit this flag to do a full encryption instead.

Step 3: save the recovery key — the step that actually matters most

You’ll be prompted to save a 48-digit recovery key, needed if the TPM detects an unexpected change (a firmware update, certain hardware changes) and refuses to auto-unlock, or if you ever need to recover the drive on different hardware:

(Get-BitLockerVolume -MountPoint "C:").KeyProtector

Save this recovery key in at least two of the following: a Microsoft account online (the default suggested option), a printed physical copy stored securely, and/or a password manager entry — never only on the same encrypted machine, since a key saved solely on the drive it protects is useless in exactly the scenario where you’d need it.

BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId (Get-BitLockerVolume -MountPoint "C:").KeyProtector[0].KeyProtectorId

Step 4: let encryption complete

Get-BitLockerVolume -MountPoint "C:"

Check the EncryptionPercentage field periodically — the drive remains usable during this process, but avoid unnecessary reboots or sleep/hibernate cycles until it reaches 100%.

Step 5: verify protection status once complete

Get-BitLockerVolume -MountPoint "C:" | Select-Object MountPoint, VolumeStatus, ProtectionStatus, EncryptionPercentage

Confirm ProtectionStatus reads On and EncryptionPercentage reads 100.

Step 6: test that you can actually locate your recovery key

Before considering this done, actually go find the recovery key wherever you saved it (your Microsoft account’s device page, your password manager, your printed copy) and confirm it’s genuinely there and matches the key protector ID from step 3 — don’t assume the save succeeded without checking.

Step 7: understand what triggers recovery mode

BitLocker can prompt for the recovery key unexpectedly after certain firmware updates, a motherboard replacement, or (in some cases) a major Windows Update — this is expected, protective behavior rather than a malfunction, and is exactly the scenario the saved recovery key from step 3 exists for.

Why saving the key externally is non-negotiable

A recovery key saved only locally on the encrypted machine, or not saved at all past the initial setup prompt, means a hardware change that triggers recovery mode can permanently lock you out of your own data with no way back in. This is the single highest-consequence mistake in the entire BitLocker setup process, and it’s also the easiest one to avoid — which is exactly why it deserves more attention here than the encryption process itself, which is otherwise fairly hands-off once started.

Encrypting a secondary data drive, not just the system volume

Enable-BitLocker -MountPoint "D:" -EncryptionMethod XtsAes256 -UsedSpaceOnly -RecoveryPasswordProtector

BitLocker isn’t limited to the system drive — a secondary internal or external data drive gets its own independent encryption and its own separate recovery key, unlocked either automatically once Windows itself has booted and authenticated (for an internal secondary drive, configured via -AutoUnlock) or via password/recovery key prompt each time it’s connected (the more common pattern for a removable external drive). Treating a secondary drive holding genuinely sensitive data with the same deliberate care as the system volume — including saving its own distinct recovery key externally — closes an easy-to-overlook gap where a system drive is properly protected but an external backup or secondary data drive containing equally sensitive information is left unencrypted entirely.

Choosing between TPM-only, TPM+PIN, and password-based unlock

By default, a TPM-equipped machine unlocks BitLocker automatically and silently at boot, using the TPM alone to validate that the boot chain hasn’t been tampered with — convenient, but it means physical possession of a powered-on, logged-out machine is sufficient to reach the login screen without any BitLocker-specific challenge at all. Adding a PIN requirement (Set-BitLockerActiveProtectionStatus combined with -Pin on Enable-BitLocker for a TPM+PIN configuration) requires that additional secret be entered at every boot before Windows even starts loading, meaningfully raising the bar against a stolen-laptop scenario specifically, at the cost of a genuinely different, slightly less convenient boot experience than fully automatic TPM-only unlock provides. Organizations with a real threat model involving device theft commonly mandate TPM+PIN specifically for this reason, while TPM-only remains a reasonable default for lower-risk, less exposure-prone deployments.

Suspending BitLocker temporarily for maintenance that would otherwise trigger recovery mode

Suspend-BitLocker -MountPoint "C:" -RebootCount 1

Certain maintenance operations — a BIOS/UEFI firmware update, some driver-level changes — can alter the exact boot-chain measurements BitLocker’s TPM protector is checking against, triggering an unwanted recovery-key prompt on the next boot even though nothing malicious actually happened. Suspend-BitLocker temporarily disables the TPM check for a specified number of reboots (encryption itself stays intact throughout, only the pre-boot check pauses) specifically so planned maintenance doesn’t unnecessarily trigger recovery mode — resuming automatically after the specified reboot count, or explicitly via Resume-BitLocker, restores full protection once the maintenance window has passed.

Related:

Sources: