FileVault, BitLocker, Enforcement & Key Escrow

"All endpoints are encrypted at rest" is one of the most common controls in any security program — it appears in SOC 2, ISO 27001, and nearly every data-protection regulation. It is also one of the easiest to get wrong in a way auditors immediately spot, because the control has a second half that people forget: if the company enforces full-disk encryption but cannot recover a locked device, the encryption becomes a self-inflicted denial of service. This lesson covers the two encryption technologies you will meet, how they are enforced and verified, and the key-escrow detail that turns "we encrypt laptops" into a real, recoverable, auditable control.

What full-disk encryption protects against

Full-disk encryption (FDE) encrypts the entire drive so that, without the key, the data is unreadable. Its specific threat model is device loss or theft: a laptop left in a taxi, a stolen phone, a hard drive pulled from a decommissioned machine. With FDE on, the thief gets an encrypted brick instead of customer data.

It is equally important to know what FDE does not protect against. It does nothing once the device is unlocked and running — a logged-in, unlocked laptop with the disk decrypted in memory is fully readable to anyone using it or to malware on it. FDE is not a substitute for screen locks, EDR, or access controls; it is the specific defense for data-at-rest on lost or stolen hardware. Conflating "encrypted" with "secure" is a mistake; FDE closes one important door, not all of them.

FileVault and BitLocker

The two FDE technologies you will see on managed fleets:

• FileVault (macOS) — Apple's full-disk encryption. On modern Macs it leverages the hardware secure enclave; you enable it, and the disk is encrypted with the user able to unlock at login. Enforceable and verifiable through MDM.
• BitLocker (Windows) — Microsoft's full-disk encryption. It binds to the device's TPM (Trusted Platform Module) so the drive only unlocks on trusted hardware, optionally with a PIN. Enforceable and reportable through Intune/MDM and Group Policy.

Mobile devices have their own equivalents — iOS Data Protection and Android file-based encryption — generally on by default on modern devices, though you still verify rather than assume. The principle is identical across all of them: data on the drive is encrypted, and a key is required to read it.

Enforcement and verification

Two distinct things, and auditors test both:

Enforcement — the MDM pushes a policy that requires FileVault/BitLocker and turns it on (or refuses the device access until it is on). This is configuration management from Module 3.1: the encryption setting is a non-removable profile on corporate, supervised devices.

Verification — the MDM continuously reports per-device encryption status: enabled, disabled, or pending. This report is the evidence. As stressed earlier in the phase, enrolled is not encrypted — you need the encryption-status report, not the enrollment roster, to prove the control.

So the evidence chain is: encryption-enforcement policy (we require it) → encryption-status report (here is the per-device proof) → any non-compliant devices and their remediation (we detect and fix drift). That is exactly what a CC6.1 / Annex A.8 encryption-at-rest control expects.

Key escrow: the half everyone forgets

Here is the part that separates a real control from a fragile one. When FileVault or BitLocker encrypts a drive, it generates a recovery key — a secret that can unlock the drive if the normal credential fails (user forgets the password, TPM state changes after a firmware update, the account is locked out, the employee leaves abruptly). If that recovery key does not exist somewhere the company can retrieve it, the data is permanently unrecoverable. Encryption without recoverable keys is a time bomb: the first locked-out executive or departed employee with the only copy of a critical file turns your security control into data loss.

Key escrow is the practice of storing those recovery keys in a secure, company-controlled location so authorized personnel can recover a device when needed. In practice:

• The MDM escrows the recovery key automatically at encryption time — Intune stores BitLocker recovery keys (in Entra ID), and Jamf/Kandji/Intune escrow FileVault recovery keys. The key lands in the management system, not on a sticky note.
• Access to escrowed keys is itself controlled and logged — only authorized IT/security staff can retrieve a key, and retrievals are auditable. The escrow must not become an unguarded backdoor; a recovery key is, after all, the thing that unlocks the encryption.

So the full control has three parts, and an auditor checks all three:

1. Encryption is enforced on the devices in scope.
2. Encryption status is verified via report.
3. Recovery keys are escrowed to a controlled, access-logged location so devices are recoverable.

What to carry forward

Full-disk encryption (FileVault, BitLocker, and their mobile equivalents) protects data at rest against device loss and theft — and nothing more, so it complements rather than replaces other controls. A complete encryption control has three parts: enforced, verified, and recoverable. The recoverable part — key escrow to a controlled, access-logged location — is the piece teams forget and auditors reliably probe. Treat the recovery key as both a recovery mechanism and a sensitive secret in its own right.

In the final lesson of this phase, you will pull identity, posture, and these device controls together by designing conditional-access policies for a set of real-world scenarios.