FileVault encrypts the startup disk on a macOS device to protect data in the event of loss or theft. When FileVault isn't behaving as expected, the issue usually falls into one of four categories — use the sections below to identify and resolve the problem.
- FileVault Not Automatically Enabling
- User Unable to Enable FileVault / User Not Showing at the FileVault Login Screen
- Incorrect Password at the FileVault Login Window (Unable to Login)
- FileVault Recovery Key Did Not Escrow
FileVault Not Automatically Enabling
Start by checking the current FileVault status on the device. From the Devices page (or GoLive > Scripts tab), paste the following into the Run Command box and click Send:
fdesetup status
Interpret the output as follows:
- "FileVault is Off" — The encryption process has not been initiated. If you expect FileVault to be enabled by an Addigy MDM configuration (Device Setting), confirm that the Device Setting is actively deployed to a policy assigned to the device.
- "FileVault is Off. Deferred enablement appears to be active for 'username'" — The encryption process has been initiated via deferred enablement. The user shown in the output is the one who must complete the process. They will be prompted to do so at their next logout or login.
Note: FileVault deferred enablement is tied to the user who was logged in at the time the Device Setting or command was deployed. If you need to change which user completes the process, you must first remove the deployed payload (FileVault Device Setting).
If you need to reassign deferred enablement to a different user:
- If FileVault was enabled via a Device Setting, remove the Device Setting from the device.
- If FileVault was initiated via GoLive > Security, run the following command to deactivate deferred enablement:
fdesetup disable
- Ensure the desired user is logged in, then re-apply the FileVault Device Setting or re-initiate it via GoLive > Security.
- Have the user log out and back in to begin disk encryption.
User Unable to Enable FileVault / User Not Showing at the FileVault Login Screen
The most common cause of this issue is a missing SecureToken. FileVault requires SecureToken to be enabled for a user before they can complete the encryption process or appear at the FileVault login screen.
Note: The FileVault login screen and the regular macOS login screen are separate. The user must authenticate at the FileVault login screen to decrypt the disk before macOS loads. This screen does not allow any internet connection, by Apple's design. Only users with SecureToken will appear here.
Users created by any method other than Apple's GUI in System Settings > Users & Groups (including those deployed via Addigy OS Users) will not have SecureToken enabled by default until they log in for the first time — this is an intentional Apple security measure to prevent unauthorized users from gaining device access..
Step 1: Check SecureToken Status
Run the following script from the Devices page (or GoLive > Scripts tab) as a Saved Script to check SecureToken status for all users on the device:
#!/bin/bash
for user in $(dscl . list /Users UniqueID | awk '$2 = 500 {print $1}'); do
sysadminctl -secureTokenStatus "$user" 2&1 | awk -F'] ' '{print $2}'
doneStep 2: Enable SecureToken
How you enable SecureToken depends on whether the device is enrolled in Addigy's MDM.
If the device is enrolled in Addigy MDM: Addigy escrows a Bootstrap Token upon MDM enrollment, which allows SecureToken to be granted automatically when a user logs in. For example, if you deploy a user via OS Users, that user will not have SecureToken until someone physically logs into that account on the device for the first time. To verify the Bootstrap Token was escrowed correctly, run:
sudo profiles status -type bootstraptoken
A healthy result will show both lines as YES (Bootstrap Token supported on and escrowed to server). If the second line shows NO (Bootstrap Token escrowed to server: NO), attempt a manual escrow with:
sudo profiles install -type bootstraptoken
Once the Bootstrap Token is confirmed, have the affected user log out and back in — SecureToken will be granted automatically on login.
If the device is not enrolled in Addigy MDM (or the user was not deployed via Addigy): This process must be completed locally on the device.
- Log in to a user account that already has SecureToken enabled.
- Open Terminal and run the following command, replacing
usernameandpasswordwith the credentials of the user you want to enable SecureToken for:
sysadminctl interactive -secureTokenOn username -password password
-
When prompted, enter the current user's password and click Unlock.
-
A "Done!" confirmation in the terminal output indicates the command completed successfully.
- Verify the result by running the following command, replacing
usernamewith the target user's account name:
sysadminctl -secureTokenStatus username
Once SecureToken is enabled, the user should be able to complete the FileVault process and will appear at the FileVault login screen.
Incorrect Password at the FileVault Login Window (Unable to Login)
If a user's correct password is being rejected at the FileVault login screen, the most likely cause is a broken SecureToken chain — typically the result of a password reset that was performed in a way that didn't preserve the chain of trust (for example, resetting the password via GoLive > Users).
Here's what happens: SecureToken ties a user's disk encryption to their password at the time SecureToken was established. If the password is later reset outside of that chain of trust, the FileVault login screen continues to expect the old password, while the user's account now has a new one. For example, if a user's password is password123 and you reset it to A Kinda Better !!!! Password via GoLive > Users, the FileVault login window will still expect password123 at the next restart.
To resolve this, follow the steps in: Fixing Broken Keychains (Secure Tokens) using Recovery Mode.
FileVault Recovery Key Did Not Escrow
If the recovery key did not automatically escrow after FileVault was enabled, follow the steps in: FAQ: Escrowing a FileVault Recovery Key Not Currently in Addigy.