BitLocker is the full-volume encryption feature built into Windows that encrypts entire drives so their data cannot be read when the device is lost, stolen or its disk is removed. In Windows security it protects data at rest: while the system is off or locked out, every sector of the protected volume, including free space, the page file and the hibernation file, is unreadable without the correct key.
BitLocker is available in the Pro, Enterprise and Education editions of Windows and on Windows Server, while Home editions offer a simplified variant called device encryption on qualifying hardware. It normally binds the encryption key to the Trusted Platform Module (TPM), so a correctly configured laptop unlocks transparently at startup but refuses to release the key if the boot chain has been tampered with.
How BitLocker encrypts and unlocks a drive
BitLocker uses a layered key hierarchy. The data on the volume is encrypted with a Full Volume Encryption Key (FVEK), which is itself encrypted by a Volume Master Key (VMK). The VMK is then protected by one or more key protectors, such as the TPM, a PIN, a startup key on a USB drive or a 48-digit recovery password.
This design means that changing a PIN or adding a protector only re-encrypts the small VMK, not the entire disk. During startup, the TPM measures firmware, boot manager and boot configuration into Platform Configuration Registers (PCRs) and releases the VMK only when these measurements match the values recorded when BitLocker was enabled.
The default cipher on current Windows versions is XTS-AES with a 128-bit key, with XTS-AES 256-bit available by policy. Removable drives that must be read on older systems can use AES-CBC instead, which is slightly weaker against manipulation of ciphertext.
Key protectors and authentication modes
The choice of key protector decides the balance between convenience and resistance to physical attack. The table below compares the common startup modes for an operating system drive.
| Protector | What the user does | Protection level |
|---|---|---|
| TPM only | Nothing, startup is transparent | Good against disk theft, weaker against advanced attacks |
| TPM and PIN | Enters a 4 to 20 digit PIN before Windows loads | Strong, blocks attacks on a powered-off device |
| TPM and startup key | Inserts a USB key at startup | Strong, but the key can be lost with the device |
| TPM, PIN and startup key | Uses both PIN and USB key | Highest, rarely used due to inconvenience |
| Recovery password | Types 48 digits when other methods fail | Emergency access, must be stored securely |
For data drives and removable drives, BitLocker can use a password, a smart card or automatic unlock tied to the operating system drive. The removable variant is known as BitLocker To Go and lets a USB drive be read on other Windows computers after the password is entered.
Organizations usually treat pre-boot PIN as the standard for high-risk devices such as laptops of executives or engineers, because TPM-only mode relies entirely on Windows sign-in to stop an attacker who has the whole device.
BitLocker compared with related protections
BitLocker is often confused with other Windows protections, but each addresses a different threat model. The comparison below places it among the neighboring features in Windows security.
| Feature | What it protects | Threat it addresses |
|---|---|---|
| BitLocker | Entire volumes at rest | Lost, stolen or removed drives |
| Device encryption | OS drive on Home editions | Same as BitLocker with fewer options |
| EFS | Individual files and folders per user | Other users on the same running system |
| Windows Hello | User sign-in | Password theft and phishing |
| Credential Guard | Secrets in memory | Credential theft from a running system |
| Controlled folder access | Selected folders | Ransomware writing to protected data |
The key distinction is that BitLocker does not protect a running, unlocked system. Once Windows has started and the volume is unlocked, files are decrypted transparently for every authorized process, including malware running as the signed-in user.
Deploying and managing BitLocker
In managed environments, BitLocker is configured through Group Policy or Microsoft Intune and its recovery passwords are escrowed automatically to Active Directory or Microsoft Entra ID. Escrow is the single most important management decision, because a device whose recovery key was never stored becomes permanently unreadable after a recovery event.
The manage-bde command-line tool and the PowerShell BitLocker cmdlets handle status checks, protector changes and suspension. The following table lists the main settings that administrators plan before a rollout.
| Setting | Common choice | Reason |
|---|---|---|
| Encryption method | XTS-AES 128 or 256 | Strong and efficient on modern CPUs |
| Used space only | Enabled on new devices | Much faster initial encryption |
| Startup authentication | TPM, or TPM and PIN for laptops | Matches device risk level |
| Recovery key escrow | Required before encryption starts | Prevents permanent data loss |
| Removable drive policy | Deny write unless encrypted | Stops unencrypted data leaving the network |
Initial encryption of a full volume runs in the background and can take from minutes to several hours, depending on drive size, speed and whether only used space is encrypted. On self-encrypting drives, hardware encryption was once possible, but current Windows versions default to software encryption after flaws were found in several drive firmware implementations.
Recovery events and common pitfalls
A recovery prompt appears whenever the TPM refuses to release the key, which is usually caused by legitimate changes rather than attacks. Administrators reduce these events by suspending BitLocker before firmware or boot changes, which leaves the data encrypted but temporarily stores the key in the clear until the next restart.
| Trigger | Why the TPM refuses | Prevention |
|---|---|---|
| UEFI or BIOS update | Firmware measurements change | Suspend protection before updating |
| Secure Boot change | Boot policy measurements change | Plan changes and suspend first |
| Moving the disk to another PC | Different TPM holds no key | Use the recovery password |
| Repeated wrong PIN entries | TPM anti-hammering lockout | Train users and reset the PIN |
| Boot configuration edits | Boot manager data changed | Avoid manual BCD edits on encrypted devices |
- Storing the recovery key on the same device defeats the purpose of encryption.
- Assuming sleep mode is protected is risky, because keys remain in memory while the system sleeps.
- Forgetting to escrow keys for devices encrypted manually leaves no recovery path.
A non-technical view
BitLocker turns everything stored on a Windows computer’s drive into scrambled data that only that computer can unlock. If a thief takes the laptop or pulls out its drive, the files look like random noise.
The computer keeps the unlocking key in a small security chip that checks the machine has not been tampered with before handing the key over. If something seems wrong, Windows asks for a long backup code. The essential lesson is to keep that recovery code somewhere safe, because without it even the owner cannot get the files back.
A concrete example
A regional accounting firm issues 120 laptops to staff who visit clients. The IT team enables BitLocker through Intune with XTS-AES 256, TPM plus a six-digit PIN, and automatic escrow of recovery passwords to Microsoft Entra ID before encryption begins.
Months later, an employee leaves a laptop on a train. The device holds tax records for several hundred clients. Because the drive is encrypted and the attacker would need the PIN before Windows even loads, the firm documents that the data was not readable, which significantly changes its obligations under data protection rules.
In the same year, a firmware update triggers recovery prompts on a dozen laptops. The help desk looks up each recovery password in Entra ID and restores access within minutes, and the team then adds BitLocker suspension to its firmware update procedure.