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 or not to prompt the user at logout in addition to prompting them at login
Whether or not 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, 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.
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. If the user is downgraded, in macOS 10.15.4 or later, 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 into or out of the Mac. Itʼs also possible to customize if the user can skip turning on FileVault (optionally a defined number of times). The end result is the primary user of the Mac—whether a local user of any type or a mobile account—being 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, meaning 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 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 MDM 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 inmacOS 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 MDM.
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). macOS starts up.
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 (TDM) on Mac computers without Apple silicon to unlock a volume:
1. Connect the Mac in TDM to another Mac using the same or 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 mounts in the Finder.