Enforcing FileVault & BitLocker with Escrowed Recovery Keys

Full-disk encryption is the easy part. Every MDM can turn on FileVault or BitLocker with a checkbox. The part that separates a mature endpoint program from a fragile one is whether you can produce the recovery key for any device, on demand, months later — because an encrypted disk with no retrievable key is not security, it is a data-loss incident with a delay timer. After running encryption compliance for mixed Mac and Windows fleets in audited environments, here is how to enforce it so the keys are always there when you need them.

Key takeaways

“98% encrypted” and “98% encrypted with a key we can actually retrieve” are different claims, and the gap between them is where a lost laptop becomes a breach. Force encryption through policy, verify escrow with a “valid key present” report rather than the raw encryption flag, and rotate keys after every retrieval.

Enforce, then prove — they are different claims

Auditors and security frameworks ask two separate questions: is the device encrypted, and is the recovery key escrowed somewhere you control and can access. Your reporting has to answer both. “98% of the fleet is encrypted” is not the same statement as “98% of the fleet is encrypted with a valid key we hold,” and the gap between those two numbers is exactly where you get burned during an incident.

FileVault with Jamf Pro

Force enablement with a configuration profile that requires FileVault at login or logout, with a short grace period of deferrals before it becomes mandatory.
Escrow the key to Jamf using an escrow payload in the same profile. Choose an individual (personal) recovery key rather than an institutional key for most fleets — it is simpler and avoids managing a shared FileVault master keychain.
Rotate keys after viewing. Configure Jamf to generate a new recovery key automatically once an admin has retrieved the old one, so a key that has been seen is never the key that is still valid.
Build a Smart Group for “FileVault on and valid escrowed key present” and report against that group, not against the raw encryption flag.

FileVault with Microsoft Intune

Intune’s disk encryption policy for macOS enables FileVault, escrows the personal recovery key to Intune, and can hide the key from the end user or expose it through the Company Portal for self-service recovery. Two things to verify after you deploy: that keys are actually landing in Intune for every device (identity or network problems can block escrow silently), and that your help desk knows where to retrieve them. A key that escrowed successfully but that nobody on the support team can find is only marginally better than no key at all.

BitLocker with Intune

Policy baseline: XTS-AES 256-bit, TPM required, encrypt used space or full disk per your risk appetite.
Key escrow: store the recovery key in Entra ID (for Entra-joined devices) or Active Directory (for hybrid). Confirm the “store recovery information before enabling” option so a device cannot encrypt without first escrowing.
Silent enablement works only when the hardware cooperates: a usable TPM, no pre-existing third-party encryption, and — on some devices — a firmware setting. Machines that fail silent enablement fall back to prompting the user, and those are the ones that quietly never finish.

Recovery key retrieval is an access-control decision

Decide deliberately who can read recovery keys. In both Jamf and Intune, key access should be a scoped role held by the help desk and security team, not something every technician inherits. Turn on audit logging for key access — you want a record of which admin viewed which device’s key and when, both for incident response and because reviewers will ask.

The failures that actually happen

Keys that never escrow. The device encrypts locally but the key never reaches the MDM because of a certificate, identity, or connectivity problem. Only a “valid escrowed key” report catches this.
Secondary volumes. External drives and extra internal partitions that users encrypt themselves, with keys you never see.
Hardware without a TPM or older Macs where enforcement behaves differently — small in number, but they are the exceptions the audit finds.
Stale keys. A recovery key retrieved during a past incident and never rotated, now sitting in someone’s notes.

Bottom line

Treat encryption and escrow as two requirements, not one. Force FileVault and BitLocker through policy, verify that every key lands in Jamf, Intune, or Entra ID, rotate keys once they have been viewed, restrict and log who can retrieve them, and report on “encrypted with a valid key we hold” rather than on the encryption flag alone. Do that and a lost laptop is a hardware expense instead of a breach notification.