Manage FileVault with mobile device management
FileVault full disk encryption can be managed in organizations using a mobile device management (MDM) solution or, for some advanced deployments and configurations, the fdesetup command-line tool. Managing FileVault using MDM is referred to as deferred enablement and requires a log-out or log-in event from the user. MDM can customize options such as:
How many times a user can defer the enablement of FileVault
Whether to prompt the user at logout in addition to prompting them at login
Whether to show the recovery key to the user
What certificate is used to asymmetrically encrypt the recovery key for escrow to the MDM solution
Having a user be enabled to unlock the storage on APFS volumes requires that they have a secure token and, on a Mac with Apple silicon, that they be volume owners. For more information on secure tokens and volume ownership, see Use secure token, bootstrap token, and volume ownership in deployments. Information on how and when users are granted a secure token in specific workflows is provided below.
Enforcing FileVault in Setup Assistant
Using the ForceEnableInSetupAssistant key, Mac computers can be required to turn on FileVault during Setup Assistant. This ensures that the internal storage in managed Mac computers is always encrypted before being used. Organizations can decide whether to show the FileVault recovery key to the user or to escrow the personal recovery key. To use this feature, ensure that await_device_configured is set.
Note: Prior to macOS 14.4, this feature requires the user account created interactively during Setup Assistant to have the role of Administrator.
When a user sets up a Mac on their own
When a user sets up a Mac on their own, IT departments don’t perform any provisioning tasks on the actual device. All policies and configurations are provided using an MDM solution or configuration management tools. Setup Assistant is used to create the initial local account, and the user is granted a secure token. If the MDM solution supports the bootstrap token feature and informs the Mac during MDM enrollment, a bootstrap token is generated by the Mac and escrowed to the MDM solution.
If the Mac is enrolled in an MDM solution, the initial account may not be a local administrator account, but rather a local standard user account. If the user is downgraded to a standard user using MDM, the user is automatically granted a secure token. In macOS 10.15.4 or later, if the user is downgraded, a bootstrap token is automatically generated and escrowed to the MDM solution if it supports the feature.
If local user account creation in Setup Assistant is skipped altogether using MDM and a directory service with mobile accounts is used instead, the mobile account user is granted a secure token during login. With a mobile account, after the user is secure token enabled, in macOS 10.15.4 or later, a bootstrap token is automatically generated during the user’s second login and escrowed to the MDM solution if it supports the feature.
In any of the above scenarios, because the first and primary user is granted a secure token, they can be enabled for FileVault using deferred enablement. Deferred enablement allows the organization to turn on FileVault but defer its enablement until a user logs in to or out of the Mac. Itʼs also possible to customize whether the user can skip turning on FileVault (optionally a defined number of times). The end result is that the primary user of the Mac—whether a local user of any type or a mobile account—is able to unlock the storage device when encrypted with FileVault.
On Mac computers where a bootstrap token was generated and escrowed to an MDM solution, if another user logs in to the Mac at a future date and time, the bootstrap token is used to automatically grant a secure token. This means that the account is also enabled for FileVault and able to unlock the FileVault volume. To remove a user’s ability to unlock the storage device, use fdesetup remove -user.
When a Mac is provisioned by an organization
When a Mac is provisioned by an organization before being given to a user, the IT department sets up the device. The local administrative account, created either in the Setup Assistant or provisioned using MDM, is used to provision or set up the Mac, and is granted the first secure token during login. If the MDM solution supports the bootstrap token feature, a bootstrap token is also generated and is escrowed to the MDM solution.
If the Mac is joined to a directory service and configured to create mobile accounts, and if there is no bootstrap token, directory service users are prompted at first login for an existing secure token administratorʼs user name and password to grant their account a secure token. A currently secure token–enabled local administrator’s credentials should be entered. If secure token isnʼt required, the user can click Bypass. In macOS 10.13.5 or later, itʼs possible to suppress the secure token dialog completely if FileVault isn’t going to be used with the mobile accounts. To suppress the secure token dialog, apply a custom settings configuration profile from the MDM solution with the following keys and values:
Setting | Value | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Domain | com.apple.MCX | ||||||||||
Key | cachedaccounts.askForSecureTokenAuthBypass | ||||||||||
Value | True | ||||||||||
If the MDM solution supports the Bootstrap Token feature and one was generated by the Mac and escrowed to the MDM solution, mobile account users won’t see this prompt. Instead, they’re automatically granted a secure token during login.
If additional local users are required on the Mac instead of user accounts from a directory service, those local users are automatically granted a secure token when they’re created in Users & Groups (in System Settings in macOS 13 or later, or in System Preferences in macOS 12.0.1 or earlier) by a currently secure token-enabled administrator. If creating local users using the command line, the sysadminctl command-line tool can be used, and can optionally enable them for secure token. Even if not granted a secure token at time of creation, in macOS 11 or later, a local user logging in to a Mac is granted a secure token during login if a bootstrap token is available from the MDM solution.
In these scenarios, the following users can unlock the FileVault-encrypted volume:
The original local administrator used for provisioning
Any additional directory service users granted secure token during the login process, either interactively using the dialog prompt or automatically with the bootstrap token
Any new local users
To remove a user’s ability to unlock the storage device, use fdesetup remove -user.
When using one of the above described workflows, secure token is managed by macOS without any additional configuration or scripting being needed; it becomes an implementation detail and not something that needs to be actively managed or manipulated.
fdesetup command-line tool
MDM configurations or the fdesetup command-line tool can be used to configure FileVault. In macOS 10.15 or later, using fdesetup to turn on FileVault by providing the user name and password is deprecated and won’t be recognized in a future release. The command continues to function but remains deprecated in macOS 11 and macOS 12.0.1. Consider using deferred enablement using MDM instead. For more information about the fdesetup command-line tool, launch the Terminal app and enter man fdesetup or fdesetup help.
Institutional versus personal recovery keys
FileVault on both CoreStorage and APFS volumes supports using an institutional recovery key (IRK, previously known as a FileVault Master identity) to unlock the volume. Though an IRK is useful for command-line operations to unlock a volume or disable FileVault altogether, its utility for organizations is limited, especially in recent versions of macOS. And on a Mac with Apple silicon, IRKs provide no functional value for two primary reasons: First, IRKs can’t be used to access recoveryOS; and second, because target disk mode is no longer supported, the volume can’t be unlocked by connecting it to another Mac. For those reasons and more, the use of an IRK is no longer recommended for institutional management of FileVault on Mac computers. Instead, a personal recovery key (PRK) should be used. A PRK provides:
An extremely robust recovery and operating system access mechanism
Unique encryption per volume
Escrow to MDM
Easy key rotation after use
A PRK can be used either in recoveryOS or to start up an encrypted Mac to macOS directly (requires macOS 12.0.1 or later for a Mac with Apple silicon). In recoveryOS, the PRK can be used if prompted by Recovery Assistant, or with the Forgot All Passwords option, to gain access to the recovery environment, which then also unlocks the volume. When using the Forgot All Passwords option, resetting a password for a user isn’t required; the exit button can be clicked to start up directly into recoveryOS. To start up macOS directly on Intel-based Mac computers, click the question mark next to the password field, then choose the option to “reset it using your Recovery Key.” Enter the PRK, then press Return or click the arrow. After macOS starts up, press Cancel on the password change dialog. On a Mac with Apple silicon using macOS 12.0.1 or later, press Option-Shift-Return to reveal the entry field for the PRK, then press Return (or click the arrow).
There is only one PRK per encrypted volume, and during FileVault enablement from MDM, it can optionally be hidden from the user. When configured for escrow to MDM, MDM provides to the Mac a public key in the form of a certificate, which is then used to asymmetrically encrypt the PRK in a CMS envelope format. The encrypted PRK is returned to MDM in the security information query, which can then be decrypted for viewing by an organization. Because the encryption is asymmetrical, MDM itself may not be able to decrypt the PRK (and thus would require additional steps by an administrator). However, many MDM vendors provide the option to manage these keys to allow for viewing directly in their products. MDM can also optionally rotate PRKs as often as is required to help maintain a strong security posture—for example, after a PRK is used to unlock a volume.
A PRK can be used in target disk mode on Mac computers without Apple silicon to unlock a volume:
1. Connect the Mac in target disk mode to another Mac using the same or a newer version of macOS.
2. Open Terminal, then run the following command and look for the name of the volume (usually “Macintosh HD”). It should say “Mount Point: Not Mounted” and “FileVault: Yes (Locked).” Make note of the APFS Volume Disk ID for the volume, which look like disk3s2 but with likely different numbers—for example, disk4s5.
diskutil apfs list3. Run the following command, then look for the personal recovery key user and make note of the UUID listed:
diskutil apfs listUsers /dev/<diskXsN>4. Run this command:
diskutil apfs unlockVolume /dev/<diskXsN> -user <PRK UUID>5. At the passphrase prompt, paste or enter the PRK, then press Return. The volume is mounted in the Finder.