How to Deploy macOS FileVault Key Escrow via MDM for Institutional Recovery

Apple FileVault provides robust, hardware-accelerated XTS-AES-128 encryption for the macOS startup disk, tightly integrated with the Secure Enclave Coprocessor (SEP). When a user enables FileVault, their local login password acts as the cryptographic unlock key. However, this creates a catastrophic enterprise risk: if the user forgets their password, or if the employee is terminated and the Mac is locked, all corporate data on the disk is mathematically irretrievable.

To prevent permanent data loss, enterprise environments must deploy FileVault Key Escrow. This mechanism intercepts the FileVault Personal Recovery Key (PRK) at the moment of encryption and securely transmits it to a Mobile Device Management (MDM) server (such as Jamf Pro or Microsoft Intune). The key is stored securely in the cloud, allowing IT administrators to decrypt the drive during a recovery event.

This guide explains how to architect and deploy a silent, mandated FileVault policy with secure PRK escrow using MDM configuration profiles.

Understanding FileVault Escrow Architecture

Historically, macOS supported “Institutional Recovery Keys” (IRK)—a single, static master certificate that could unlock every Mac in the fleet. This architecture has been largely deprecated due to massive security risks (if the IRK was leaked, the entire fleet was compromised).

The modern, secure architecture uses the Personal Recovery Key (PRK).

1. The MDM server pushes a configuration profile to the Mac containing the com.apple.MCX.FileVault2 payload.
2. This payload contains an Escrow Location (a secure HTTPS endpoint hosted by the MDM).
3. The profile enforces deferred enablement. The next time the user logs in or logs out, macOS prompts them to enable FileVault.
4. macOS generates a unique, alphanumeric PRK (e.g., ABCD-1234-EFGH-5678-IJKL-9012).
5. Before displaying the key to the user (or hiding it entirely, based on policy), macOS encrypts the PRK and securely transmits it to the MDM Escrow Location.
6. The disk encrypts in the background, and IT holds the fallback key.

Step 1: Creating the MDM Configuration Profile

To enforce FileVault, you must construct the appropriate payload within your MDM console. The following steps use generic MDM terminology applicable to Jamf, Intune, or Kandji.

1. Navigate to your MDM’s Configuration Profiles section and create a new macOS profile.
2. Select the FileVault payload (sometimes labeled Security & Privacy > FileVault).
3. Require FileVault: Set to Yes or Require.
4. Enable at Next Login: Set this to Require at Login (or Logout). This forces the prompt; the user cannot bypass it.

Step 2: Configuring the Escrow Settings

Within the same payload, you must define how the recovery key is handled.

• Recovery Key Type: Select Personal Recovery Key (PRK). Do not use Institutional Recovery Key.
• Escrow Personal Recovery Key: Set to Yes. This automatically populates the MDM’s secure HTTPS receiver URL into the profile payload.
• Display Personal Recovery Key to User: In enterprise environments, this is almost always set to No (Do not display). Showing the key to the end-user encourages them to write it down on a sticky note, creating a physical security vulnerability. The user should rely on IT for recovery.

Step 3: Escrow Certificate Verification

To ensure the Mac is securely transmitting the key, the payload requires an Escrow Certificate. The Mac uses this public certificate to encrypt the PRK before transmitting it over the network. Only the MDM server holds the corresponding private key to decrypt it and store it in the database.

Modern MDMs automatically inject this certificate into the payload when you check the “Escrow” box. If you are building a custom XML payload, you must extract the MDM’s public certificate and embed it in the profile as a base64 string.

Step 4: Deploying and Monitoring the Policy

Assign the Configuration Profile to a dynamic Smart Group (e.g., “Macs without FileVault Enabled”).

The End-User Experience:
The next time the user restarts or logs out of their Mac, they are intercepted by the macOS Setup Assistant. They are prompted: “Your administrator requires that you enable FileVault.” The user enters their password to authorize the encryption. The process completes instantly, and the disk begins encrypting in the background.

IT Monitoring:
Within the MDM console, you should monitor the device inventory records.

1. Verify the FileVault Status changes from Unencrypted to Encrypting to Encrypted.
2. Verify that the FileVault Personal Recovery Key field is populated. If a Mac is encrypted but the escrow failed, you have a critical, unrecoverable endpoint.

Step 5: Performing a Key Rotation (Post-Recovery)

If a user forgets their password and contacts the IT Helpdesk, the IT technician will read the PRK from the MDM console and provide it to the user. The user types the PRK into the macOS login screen, bypassing their password and unlocking the disk.

Critical Security Rule: Once a PRK has been used, it is compromised. It must be rotated immediately.

macOS supports automatic PRK rotation. The MDM can issue an MDM command (RotateFileVaultKey) to the Mac. The Mac will silently generate a brand new PRK, encrypt it, send the new key to the MDM escrow endpoint, and destroy the old key—all without any end-user interaction.

Conclusion

Mandating full-disk encryption without a centralized escrow strategy guarantees data loss. By utilizing the native MDM FileVault Escrow payload, IT security teams can seamlessly enforce zero-trust encryption standards across massive macOS fleets, securely capturing cryptographically robust recovery keys while remaining completely invisible to the end user.