FileVault Disk Encryption for Mac Admins
Managing FileVault 2 at scale — enabling, escrowing recovery keys, institutional keys, and fleet deployment strategies
Overview
FileVault 2 is Apple’s full-disk encryption technology for macOS, using XTS-AES-128 encryption to protect the entire startup volume. When FileVault is enabled, all data on the disk is encrypted at rest, and the system requires authentication at the pre-boot stage before the volume can be unlocked and macOS can load. For Mac admins, FileVault is typically a mandatory compliance requirement and one of the most common fleet security controls to manage.
How FileVault Works
FileVault encrypts the entire APFS (or CoreStorage on older systems) volume. On Apple Silicon Macs, hardware encryption is always active at the storage controller level. FileVault adds a layer of software encryption on top and ties the decryption key to user authentication. This means:
- Without FileVault: The disk is hardware-encrypted, but the key is available without authentication – anyone who possesses the Mac can access the data.
- With FileVault: The decryption key is protected by the user’s password. The disk cannot be read without a valid credential or recovery key.
Enabling FileVault
Via Command Line
# Enable FileVault and output the recovery key
sudo fdesetup enable
This command prompts for a user password and generates a personal recovery key. The key is displayed in the terminal – capture and store it securely.
# Enable FileVault for a specific user with a deferred enablement
sudo fdesetup enable -defer /path/to/output.plist
Deferred enablement is the standard approach for fleet deployments. The user is prompted to enable FileVault at their next logout, and the recovery key is written to the specified plist for escrow.
Via MDM Configuration Profile
The recommended approach for fleet management is deploying a FileVault configuration profile through your MDM. This profile can:
- Force FileVault enablement at next logout
- Automatically escrow the recovery key to the MDM server
- Set recovery key type (personal or institutional)
- Configure deferred enablement behavior
Checking FileVault Status
# Check if FileVault is enabled
fdesetup status
# Check if FileVault encryption/decryption is in progress
fdesetup status -extended
# List FileVault-enabled users
fdesetup list
# Check APFS crypto users on Apple Silicon
diskutil apfs listCryptoUsers /
The diskutil apfs listCryptoUsers command is particularly useful on Apple Silicon Macs. It shows all crypto users (authentication credentials) associated with the encrypted volume, including:
- Local Open Directory User – Standard user accounts
- Personal Recovery User – The personal recovery key
- Institutional Recovery User – The institutional recovery key (if configured)
- MDM Bootstrap Token External Key – Used by MDM for escrow and key rotation
Recovery Key Types
Personal Recovery Key
A 24-character alphanumeric string generated when FileVault is enabled. Each Mac gets a unique key. This is the most common type used in fleet management.
Example format: XXXX-XXXX-XXXX-XXXX-XXXX-XXXX
Institutional Recovery Key
A FileVault master identity (certificate-based) that can unlock any Mac in the organization. This requires creating a FileVault master keychain and deploying the certificate via MDM.
Note: Institutional recovery keys add complexity and risk. If the master keychain is compromised, every encrypted Mac in your fleet is at risk. Most modern MDM deployments rely on personal recovery keys with escrow instead.
Escrowing Recovery Keys to MDM
Recovery key escrow is the process of sending the FileVault recovery key to your MDM server for safekeeping. This is critical – without key escrow, a forgotten password on an encrypted Mac means permanent data loss.
How Escrow Works
- MDM pushes a FileVault configuration profile with escrow settings
- When FileVault is enabled (or the key is rotated), macOS sends the recovery key to the MDM server via a secure
SecurityInfocommand - The MDM stores the key and makes it available to admins through the console
Verifying Key Escrow
In most MDM platforms, you can verify escrow status per device. Additionally, you can check locally:
# Verify a recovery key is valid (requires the key)
sudo fdesetup validaterecovery
This prompts for the recovery key and confirms whether it can unlock the volume.
Recovery Key Rotation
Recovery keys should be rotated periodically and after any use. Most MDM platforms support automatic key rotation:
# Rotate the personal recovery key (generates new key, invalidates old)
sudo fdesetup changerecovery -personal
When using MDM, key rotation can be triggered remotely, and the new key is automatically escrowed. Common rotation triggers include:
- After a recovery key is used to unlock a Mac
- On a scheduled interval (quarterly, annually)
- After an employee leaves the organization
- After a security incident
Apple Silicon vs Intel Considerations
| Feature | Intel Mac | Apple Silicon Mac |
|---|---|---|
| Hardware encryption | Only with T2 chip | Always active |
| Pre-boot authentication | EFI-based login screen | Recoverable via recoveryOS |
| Bootstrap token | Supported (macOS 10.15+) | Required for FileVault enablement via MDM |
| Crypto user management | fdesetup only | fdesetup + diskutil apfs listCryptoUsers |
| Secure token requirement | Yes (macOS 10.15+) | Yes |
Bootstrap Tokens
On Apple Silicon Macs, MDM requires a bootstrap token to manage FileVault. The bootstrap token is automatically escrowed to MDM during enrollment and is used to grant Secure Tokens to MDM-created accounts.
# Check if a bootstrap token has been escrowed
profiles status -type bootstraptoken
Secure Tokens
A user must have a Secure Token to be a FileVault-enabled user. Secure Tokens are automatically granted to the first user created during Setup Assistant. Additional users need to be granted a Secure Token by an existing Secure Token holder.
# Check if a user has a Secure Token
sysadminctl -secureTokenStatus username
Troubleshooting Common Issues
FileVault fails to enable: Ensure the user has a Secure Token. Check with sysadminctl -secureTokenStatus.
Recovery key not escrowed: Verify the MDM profile is installed and the device can communicate with the MDM server. Try rotating the key to trigger a new escrow attempt.
User not listed in fdesetup: The user may lack a Secure Token. Grant one using sysadminctl -secureTokenOn username -password -.
Encryption stuck in progress: Check fdesetup status -extended for percentage. Encryption can take hours on large volumes and pauses when the Mac is on battery.
Compliance Requirements
FileVault encryption is required by most security frameworks:
- CIS Benchmarks for macOS – Level 1 requires FileVault enabled
- NIST 800-171 – Requires encryption of CUI at rest
- SOC 2 – Requires encryption controls for endpoint devices
- HIPAA – Requires encryption of ePHI at rest
- PCI DSS – Requires strong cryptography on storage of cardholder data
Key Takeaways
FileVault is a non-negotiable baseline for any managed Mac fleet. Deploy it via MDM configuration profiles, always escrow recovery keys, ensure all users have Secure Tokens, and implement key rotation. On Apple Silicon Macs, make sure bootstrap tokens are escrowed early in the enrollment process to avoid FileVault management failures later.