Disk Encryption Guide: BitLocker and FileVault Deployment

Full disk encryption is only as strong as its unlock method and its recovery keys, and most fleets get one of the two wrong. A laptop with TPM-only BitLocker can be unlocked by anyone who can boot it under the right conditions, and a FileVault or BitLocker recovery key sitting in a directory that half the help desk can read is a second way in. This guide covers BitLocker deployment and protector choice (including TPM-only risks such as bitpixie), recovery key escrow, access and rotation, FileVault deployment, Linux full disk encryption with LUKS and dm-crypt, and self-encrypting drives. It is written for endpoint engineers, security architects and the people who answer "was that lost laptop encrypted?". For encryption at every other layer, see the Encryption Guide.

Key takeaways

• Disk encryption protects powered-off devices. It defeats a thief with a switched-off laptop or a pulled drive; it does nothing against malware or a user session on a running machine.
• TPM-only is a convenience choice, not a strong one. Microsoft calls it "less secure than the other options"; use a BitLocker pre-boot PIN where physical attackers with time are in scope.
• Recovery keys are credentials. Escrow them before encryption completes, restrict who can read them, audit every read and rotate after use.
• Use the platform's native management. MBAM reached the end of extended support on 14 April 2026; Intune, Configuration Manager or Active Directory now carry remote BitLocker management, and an MDM carries FileVault.
• Prove it per device. Encryption status, protector type and escrow status reported from the device are the evidence that turns a lost laptop into a non-event.

What full disk encryption protects, and what it does not

NIST SP 800-111 groups storage encryption for end user devices into full disk, volume and virtual disk, and file and folder encryption. Full disk encryption protects data at rest on the device; once the volume is unlocked, the operating system and every process see plaintext.

For lost laptop encryption to count as a mitigation in a breach assessment, you need evidence that the specific device was encrypted, which protector it used and that its key was not exposed. See the Lost or Stolen Device Response Checklist.

BitLocker protectors: TPM-only versus pre-boot PIN

BitLocker is a Windows feature that "provides encryption for entire volumes", working with a TPM 1.2 or later that checks the device "hasn't been tampered with while the system is offline". With Secure Boot, BitLocker binds to the TPM PCR[7] measurement. Microsoft's countermeasures page lists the protector options:

Microsoft is explicit that the stronger settings "are not configured by default". For hardened administrative workstations it recommends TPM + PIN, disabling standby and shutting down or hibernating before the device leaves an authorised user's control. Enable "Allow enhanced PINs for startup" so users can choose alphanumeric PINs that make anti-hammering far more effective.

BitLocker bypass on TPM-only devices: bitpixie

CVE-2023-21563 is recorded by NVD as a "BitLocker Security Feature Bypass Vulnerability", published on 10 January 2023 with a Microsoft-assigned CVSS 3.1 score of 6.8 and a physical attack vector. Public research known as bitpixie showed that on devices without pre-boot authentication, an attacker with physical access and the ability to network boot could start an older, still trusted Windows boot manager and recover the volume master key from memory, with no hardware tampering. Patching alone did not close it, because the older boot manager remained signed by a certificate the firmware trusted.

• Require a pre-boot PIN on devices where a physical attacker is in scope. Without the PIN the TPM does not release the key, so the attack has nothing to recover.
• Revoke old boot managers: Microsoft's KB5025885 adds the "Windows UEFI CA 2023" certificate, moves devices to a boot manager signed with it and adds "Windows Production PCA 2011" to the DBX, with an optional Secure Version Number that "prevents an attacker from rolling back the Boot Manager to an older, non-updated version". Microsoft warns that "Some devices may go into BitLocker recovery" and that revocations "cannot be reverted", so test one device per hardware model and confirm recovery keys first.
• Close boot paths you do not use: disable network (PXE) boot and booting from external media in firmware, protected by a firmware password.

BitLocker deployment

Device encryption turns BitLocker on automatically on qualifying Windows devices, and from Windows 11 version 24H2 the DMA and HSTI or Modern Standby prerequisites are removed, so more devices qualify. It encrypts the OS and fixed drives, not USB drives, and backs the recovery key up to Entra ID, AD DS or the user's Microsoft account. Microsoft warns that a device using only local accounts "remains unprotected even though the data is encrypted", because nothing was escrowed. Managed fleets should replace it with explicit policy.

Intune silent encryption

Microsoft recommends the Endpoint security > Disk encryption policy. Silent BitLocker encryption needs an Entra joined or hybrid joined device with TPM 1.2 or later, native UEFI, Secure Boot and a working Windows Recovery Environment, and the device "must not require TPM startup PIN or startup key". Standard users additionally need "Allow Standard User Encryption". A common pattern is silent TPM-only encryption at enrolment, then a second policy that adds a BitLocker PIN for high-risk groups.

Settings to decide before rollout

• Cipher: "Choose drive encryption method and cipher strength" defaults to XTS-AES 128-bit; Microsoft recommends XTS-AES and suggests 256-bit where performance or regulation requires it. Changing method later means decrypting first.
• Startup authentication: "Require additional authentication at startup" with "Configure minimum PIN length for startup" for PIN groups.
• Used space or full encryption: "Enforce drive encryption type on operating system drives". Microsoft's FAQ says used space only can cut encryption time "by more than 99 percent" but is "not the most secure way"; use full encryption on reissued devices that may hold deleted data.
• DMA: "Disable new DMA devices when this computer is locked" on devices without hardware DMA protection.
• Suspension: suspend stores the key protector as a clear key on disk. Firmware updates suspend for a reboot; monitor devices that stay suspended.

BitLocker To Go and removable media

BitLocker To Go is BitLocker on removable drives (USB flash drives, SD cards and external disks formatted NTFS, FAT16, FAT32 or exFAT), unlocked with a password or smart card on other computers. "Deny write access to removable drives not protected by BitLocker" mounts unencrypted drives read-only. There is no automatic escrow of removable drive keys to Entra ID or AD DS, so decide whether users may encrypt their own drives or whether only issued, managed devices are allowed. See the Windows Endpoint Hardening Guide for the wider baseline.

BitLocker recovery keys: escrow, access and rotation

The recovery password is "a 48-digit number used to unlock a volume when it is in recovery mode", and Microsoft states that holding it "allows the holder to unlock a BitLocker-protected volume and access all of its data".

• Escrow first: set "Store recovery information in Microsoft Entra ID before enabling BitLocker" to Required (or the equivalent AD DS setting, "Choose how BitLocker-protected operating system drives can be recovered"), so no drive is encrypted without a stored key.
• Restrict readers: in Entra ID, reading keys needs microsoft.directory/bitlockerKeys/key/read, included in Cloud Device Administrator, Helpdesk Administrator and Global Administrator. Scope help desk access with administrative units or custom roles, and require Conditional Access for those roles.
• Self-service: Entra lets users retrieve keys for their own devices, which removes help desk calls but makes the user's account the key. Require phishing-resistant MFA if you enable it.
• Audit: Microsoft states "All BitLocker recovery key accesses are audited", logged under Key Management with the activity "Read BitLocker key". Alert on volume and on reads for devices not in a recovery ticket.
• Recovery key rotation: "Client-driven recovery password rotation" replaces a recovery password after it is used, and the Intune "BitLocker key rotation" remote action rotates on demand (Windows 10 1909 or later). Entra ID holds at most 200 recovery keys per device, after which silent encryption fails.
• Clean up AD DS: Active Directory keeps every historical recovery password, so retired keys accumulate on computer objects; restrict who can read them.

Recovery triggers and the help desk

Microsoft lists recovery triggers including firmware upgrades, changes to the boot manager, PXE boot, TPM clearing, moving a drive to a new computer and too many wrong PINs. Recovery prompts are therefore normal during firmware rollouts, and a social engineer can exploit that. Verify identity before reading out a key; see the Account Recovery and Help Desk Security Guide.

MBAM and remote BitLocker management

Microsoft BitLocker Administration and Monitoring (MBAM) 2.5 and 2.5 SP1 reached the end of extended support on 14 April 2026 under the Fixed Lifecycle Policy. Organisations still running it should move remote BitLocker management, key escrow, compliance reporting and self-service recovery to Intune (the Devices > Monitor > Encryption report), Configuration Manager or AD DS, and decommission the MBAM database once keys are migrated and verified.

FileVault deployment and recovery keys

FileVault 2, the full-volume encryption in macOS, uses AES-XTS; on Apple silicon and T2 Macs "all FileVault key handling occurs in the Secure Enclave" and keys "are never directly exposed to the CPU". Management is through MDM:

• Enforce at setup: Apple lets you "require Mac computers to turn on FileVault during Setup Assistant", holding the Mac until it is on. On macOS 26.4 and later FileVault is on by default in Setup Assistant and the bootstrap token can grant the user a secure token. Deferred enablement after enrolment waits for a logout or login.
• Personal recovery key (PRK): there is one PRK per volume, escrowed to the MDM encrypted with a certificate "in a CMS envelope format", and the MDM can rotate it "as often as required". Rotate after every use.
• Institutional recovery key (IRK): Apple says IRKs "provide no functional value" on Apple silicon and that "the use of an IRK is no longer recommended". Retire IRK-based processes and rely on escrowed PRKs.
• Secure token and bootstrap token: a user needs a secure token (and on Apple silicon must be a volume owner) to enable FileVault; the bootstrap token, escrowed at first login, lets the MDM grant secure tokens to later users.

Report FileVault and escrow status from the device rather than the profile assignment. See the macOS Security Guide for Enterprises.

Linux full disk encryption with LUKS and dm-crypt

The cryptsetup manual describes LUKS (Linux Unified Key Setup) as "a standard for disk encryption"; LUKS2 is the default format and supports memory-hard Argon2. The encryption itself "is performed transparently by the kernel's device-mapper dm-crypt driver".

• Key slots: LUKS holds several independent passphrases or tokens wrapping one volume key. Add a managed recovery key with luksAddKey, record slot use with luksDump and remove leavers' slots with luksKillSlot.
• Header backup: "If the header of a LUKS volume gets damaged, all data is permanently lost unless you have a header backup." Store header backups securely: a backup with an old passphrase slot still opens the volume.
• TPM2 unlock: systemd-cryptenroll enrols TPM2, FIDO2, PKCS#11, passwords and generated recovery keys. Its manual suggests binding to "some combination of PCRs 7, 11, and 14" and warns against PCRs 0 and 2, which change with firmware updates. Add --tpm2-with-pin for laptops at risk of physical attack.
• Servers: unattended servers need TPM binding or network-bound unlock; a passphrase typed at the console does not survive remote reboots.

Rotate the volume key with cryptsetup reencrypt if it may have been exposed; changing a passphrase does not change the volume key. See the Linux Server Hardening Guide.

Self-encrypting drives and TCG Opal

A self-encrypting drive encrypts in its own controller; the TCG Opal Security Subsystem Class specification defines what a drive claiming Opal compliance must implement. Encryption costs no host CPU and secure erase is instant, but you trust the drive firmware. Academic research published in 2019 found serious flaws in several vendors' implementations, and Microsoft's countermeasures page notes that a pre-boot PIN mitigates an attack vector against bootable eDrives. Use software encryption (BitLocker, FileVault or LUKS) as the control you rely on, and treat SED as an added layer or a fast decommissioning feature.

Choosing protection by device type

Small organisations can rely on Intune or an MDM for policy, escrow and reporting with TPM-only for most users and a PIN for a short list. Large estates need per-model testing of firmware and Secure Boot changes, scoped key reader roles, and integration of encryption status into conditional access.

Rolling out disk encryption

1. Inventory: list devices by OS, TPM version, firmware mode (UEFI, Secure Boot) and current encryption, and flag devices encrypted without escrow.
2. Escrow and access model first: configure escrow to Entra ID, AD DS or MDM, define reader roles and enable audit alerts before any new encryption.
3. Pilot ring: one device per hardware model; test encryption, a forced recovery, key rotation, a firmware update and, for KB5025885, the boot manager revocation.
4. Broad rollout: silent TPM-only encryption by ring, monitoring the encryption report daily; roll back a ring by pausing policy assignment (devices already encrypted stay encrypted).
5. Add PINs for high-risk groups with user communications and help desk scripts.
6. Enforce: require encryption and escrow for compliance in conditional access, and deny writes to unencrypted removable drives.
7. Retire legacy: migrate off MBAM and IRKs and remove stale keys.

Detection and measurement

• Coverage: devices encrypted with recovery key escrowed, by platform (target 100 per cent of managed endpoints).
• Protector strength: devices in high-risk groups with a pre-boot PIN, and TPM-only devices without the boot manager revocations applied.
• Key access: recovery key reads per week, and reads not matched to a recovery ticket (target zero).
• Rotation: used recovery keys rotated within 24 hours.
• Drift: devices suspended for more than one reboot or decrypted after enrolment.

Common failure patterns

• Encrypted but not escrowed: local-account device encryption or user-enabled BitLocker with no key in the directory, so a failed motherboard means lost data.
• Everyone can read keys: broad help desk or Global Administrator access with no alerting, turning one phished account into keys for the whole fleet.
• TPM-only everywhere including executive and administrator laptops, leaving them open to bitpixie-style attacks.
• Revocations applied without testing, pushing a hardware model into recovery during travel season.
• Trusting policy assignment instead of device-reported status when answering a lost device question.

Framework mapping

Practitioner checklist

• Require recovery key escrow before encryption on every platform, and find devices encrypted without escrow.
• Restrict recovery key readers to scoped roles, require strong MFA and alert on reads without a ticket.
• Enable client-driven recovery password rotation and rotate FileVault PRKs after use.
• Use TPM + enhanced PIN for administrators, executives and travellers; disable standby on those devices.
• Test and apply the KB5025885 boot manager revocations by hardware model, and disable unused network and external boot.
• Migrate off MBAM and institutional recovery keys.
• Back up LUKS headers securely and escrow a recovery key slot for every Linux device.
• Deny writes to unencrypted removable drives.
• Report encryption, protector and escrow status from devices into conditional access.

Standards and references

• NIST: SP 800-111, Guide to Storage Encryption Technologies for End User Devices
• Microsoft Learn: BitLocker countermeasures
• Microsoft Learn: BitLocker recovery overview
• Microsoft Learn: Encrypt Windows devices with BitLocker in Intune
• Microsoft Support: KB5025885, How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932
• NIST NVD: CVE-2023-21563, BitLocker Security Feature Bypass Vulnerability
• Apple Platform Security: Managing FileVault in macOS
• cryptsetup (man7.org): cryptsetup(8)

Related NHI Mgmt Group resources: Encryption Guide · Cryptographic Key Management Guide · Endpoint Security Guide · Mobile Device Security Guide