Manage FileVault with Sophos Fusion

Sophos Fusion Device Encryption manages Apple’s FileVault and the personal recovery key. Encryption, user authorization on pre-boot and unlocking the startup volume remain functions of macOS. A Mac is therefore only fully rolled out when policy, local FileVault status, authorized users and an actually available recovery key match.

Quick process

1. Check supported macOS and Sophos versions, APFS volumes, and existing FileVault and management health.
2. Ensure that the activating local user has a Secure Token. On a Mac with Apple silicon, they must also be a Volume Owner.
3. Install Sophos Endpoint and the Device Encryption Agent.
4. Create a device encryption policy under My Products > Encryption > Policies, enable Device Encryption is on and assign it to all intended users of the Mac.
5. Have the user log in locally. In the Sophos dialog, Encrypt starts a new encryption; if FileVault is already active, Create key creates a new personal recovery key managed by Sophos.
6. Check locally and under My Products > Encryption > Computers: expected volumes encrypted, intended accounts authorized at pre-boot, synchronization current and recovery key available in Sophos Fusion.

An assigned policy or a locally displayed “FileVault: On” is not sufficient for validation. An encrypted volume without a reliable recovery path remains an open security and operational case.

Prerequisites before the first assignment

Supported platform and agents

Supported macOS and Sophos versions are changing. Before the pilot and broad rollout, the current status is checked in accordance with Sophos Endpoint system requirements and lifecycle planning. Sophos Endpoint and the separate Device Encryption Agent must be installed on the Mac.

Sophos manages the APFS boot volume and, if the policy allows for this, fixed internal data volumes. Removable media and Windows partitions created with Boot Camp are not supported. Before assigning the policy, inventory all internal volumes using Disk Utility or diskutil apfs list. This makes it clear which volumes should be protected and whether an additional volume already has its own disk password.

Understanding Secure Tokens and Volume Owners

A FileVault user needs the appropriate Apple permission, not just a local account:

• The user who activates FileVault or unlocks a boot volume on pre-boot needs a Secure Token.
• On Macs with Apple silicon, a user must also be a Volume Owner to unlock the startup volume and authorize security-related startup operations.
• An admin name or policy assignment does not automatically grant these Apple permissions.

Apple describes these relationships in Manage FileVault with device management. For a local, read-only preliminary check, use the following commands in Terminal:

sysadminctl -secureTokenStatus <KURZNAME>
diskutil apfs listUsers /

<KURZNAME> is replaced with the local account name. The first command must report an activated Secure Token for the activating user. Check the APFS user list against the intended local FileVault users. On Macs with Apple silicon, also confirm volume owner authorization through the Apple or MDM verification process approved by the organization. If a permission is missing, correct it before rollout through the existing Apple administration process—not by repeatedly turning the Sophos policy on and off.

Clarify management and recovery responsibilities

Before the changeover, the current FileVault status, existing personal recovery keys, authorized pre-boot users and previous administration are documented. Two systems may not enforce conflicting FileVault policies at the same time. If an MDM or legacy encryption product is involved, the target state and key responsibility must be established before the change.

The common helpdesk process for retrieval, issuance and documentation is available at Retrieve Recovery Key Securely. Sophos does not recommend backing up the FileVault recovery key to iCloud Keychain.

A representative pilot group includes at least Intel and Apple silicon variants, the enrollment types actually used, a new Mac, a Mac with FileVault already active, and—if available—a Mac with additional internal APFS volumes.

Create and assign policies

The documented Central path is My Products > Encryption > Policies:

1. Select Add Policy and create a device encryption policy.
2. On the Settings tab, enable the Device Encryption is on option.
3. Decide whether to use Encrypt boot volume only. If the option is active, the policy ignores fixed internal data volumes. Otherwise, Sophos can also manage these volumes after the startup volume.
4. Enable the policy and assign it to the intended users.

The assignment is user-based. Sophos recommends assigning the policy to all users of a specific Mac. This prevents a shared Mac from remaining outside the desired scope of protection simply because of an incomplete assignment. The actual pre-boot authorization is still checked separately; policy assignment and FileVault user status are not the same thing.

If the policy is turned off or removed, Sophos does not perform a new encryption or decryption action. An already activated FileVault remains active. A recovery key previously transferred successfully to Sophos Fusion may still be accessible; however, this proves neither current key escrow capability nor the adoption of later key changes. “Policy off, FileVault on” is therefore not a clearly proven, centrally managed target state.

Encrypt a new Mac

After local login and successful synchronization, Sophos shows the activation dialog:

1. The user enters their macOS login password. This authorizes Sophos Device Encryption in the context of their local account.
2. With Encrypt, they start the encryption. Postpone only postpones the start. The Mac is not yet accepted.
3. The agent stores the personal recovery key in the local macOS Keychain and transfers it to Sophos Fusion.

During initial deployment, Sophos adds the endpoint’s existing authorized users to FileVault. If Encrypt boot volume only is not activated, the unencrypted fixed internal data volumes follow the boot volume. Status messages show progress per volume.

The user must be logged in locally on the Mac for activation and migration. Simply logging in remotely is not enough. If no dialog is displayed, first check the local session, policy assignment, last synchronization, secure token and, on Macs with Apple silicon, the volume owner status.

Adopt existing FileVault or SafeGuard

Already active FileVault

An already encrypted Mac does not need to be decrypted first for Sophos to adopt:

1. Document initial state, existing recovery path and pre-boot user.
2. Install Device Encryption Agent and assign the active policy.
3. Have an authorized user log in locally.
4. In the Sophos dialog, enter the macOS login password and select Create key.
5. Wait for Sophos to generate a new personal recovery key and transfer it to Fusion.
6. Only after the local status and central evidence are correct, deactivate the previous recovery path according to your own storage process.

An already encrypted internal data volume with its own volume password requires this password once. Sophos can then manage the volume and automatically unlock it at startup. If the password is unknown, adoption of this volume is stopped; a functioning login to the startup volume does not prove that the data volume can also be restored.

SafeGuard initial state

For a Mac managed by SafeGuard, first clearly record the product, version, installed modules, FileVault status, and existing recovery path. The Sophos migration guide requires removing the SafeGuard device encryption software before adoption; for SafeGuard Enterprise 8 or later, it describes an adoption process in which FileVault can remain encrypted.

However, historical SafeGuard release notes are not proof of current support for a continued or newly installed SafeGuard module. If the version is unknown, the modules are mixed or there is a plan to continue using a SafeGuard file encryption module, the migration will be stopped and the specific combination will be clarified with a current Sophos support statement. The safe principle remains: never let two managers control FileVault or its recovery key at the same time, and only abandon the old recovery method once the new key has been confirmed.

Authorize additional FileVault users

Anyone who is supposed to unlock the Mac at pre-boot must be authorized as a FileVault user. If new users are not added automatically, Sophos describes the following process:

1. The new user logs in locally, enters their macOS login password in the Sophos dialog and selects Proceed.
2. If no recovery key is yet saved in Fusion, they also select an already authorized FileVault user.
3. This existing user enters their own macOS login password and selects Proceed.
4. After a restart, check whether the new user can log in to FileVault pre-boot.

A missing secure token or—on Macs with Apple silicon—missing volume owner status cannot be replaced with the credentials of just any administrator. In this case, correct the Apple permission first and then repeat the Sophos process.

According to Sophos, removing a user from Central policy does not automatically remove them from FileVault. On shared Macs, policy assignment, local accounts, and actual pre-boot permission are therefore maintained separately. The following command shows the locally enabled FileVault users:

sudo fdesetup list

Verify status and recovery readiness

Read Central status correctly

Under My Products > Encryption > Computers the Mac is checked with its last communication and its encryption status. These states are particularly relevant for macOS:

• Encrypted: The encryption is complete. The recovery evidence is still checked separately.
• Pending: The policy is assigned, but encryption or user action is not yet completed.
• Plain: At least one expected volume is unencrypted or encryption has not yet started.
• Unmanaged: The agent exists, but no device encryption policy is in effect.
• Not supported: Platform or operating mode is not supported.
• Not available: Fusion does not know the status, for example because the component is missing or there is no usable message yet.

Suspended is a BitLocker state and not a FileVault acceptance or diagnostic value. Instead, on a Mac, policy, user authorization, volume health, synchronization and recovery key are evaluated together.

For rollout and proof of operation, status changes and key events are also evaluated under Reports > General Logs > Events for the affected Mac and time period. Events such as Device Encryption status changed, Received recovery keys, Key creation failed or Recovery key missing show the history, but do not replace the current check on the device and under Encryption > Computers. Filtering, exporting, and retaining the report are explained in Evaluate Sophos Endpoint events and reports.

Check locally

The Sophos Device Encryption app is located in the Applications folder and shows policy, user, volume and recovery status. The volume symbols mean:

• Green: fully encrypted and recovery key stored in Fusion.
• Yellow: fully encrypted but no key stored in Fusion; a managed key cannot yet exist for a volume that was encrypted locally without Fusion.
• Yellow with exclamation mark: fully encrypted volume required by the policy without an available recovery key.
• Red: not encrypted, although the policy requires encryption.
• Gray: not encrypted and not required by the policy or no policy exists.
• Progress bar: The volume is currently being encrypted or decrypted.

In addition, Sophos provides the /usr/local/bin/seadmin tool:

/usr/local/bin/seadmin help
/usr/local/bin/seadmin status
/usr/local/bin/seadmin --device-encryption

status shows the last synchronization and synchronization interval. --device-encryption shows the current policy as well as the encryption and recovery status of the internal volumes. Provide four pieces of evidence together for approval to operate:

1. The intended volumes are fully encrypted and locally green.
2. fdesetup status reports that FileVault is active; sudo fdesetup list contains the intended pre-boot users.
3. The Mac is currently synced with Fusion and reports Encrypted.
4. The approved retrieval path can deliver the recovery key for the correct Mac or the recovery key ID displayed there; the local FileVault acceptance remains separate.

Restore a Mac

Securely retrieve recovery key provides the key that has already been correctly assigned. This article begins with its use in FileVault.

Reset password on normal home screen

1. Click on the question mark in the password field and use the arrow to move to the recovery key field.
2. Enter the recovery key issued for this Mac.
3. Follow the macOS dialog to create a new login password.
4. If Create New Keychain is offered, create a new keychain. A FileVault recovery key does not automatically unlock the old keychain.
5. After login, check FileVault users, Sophos sync and recovery status again.

The recovery key ID is only displayed briefly at startup. The Mac must be restarted to display again. For users imported from Active Directory, the password is first reset in AD and a temporary password is assigned. In the macOS dialog, the user selects Cancel and then enters this temporary password.

Unlock APFS volume outside of normal boot

This fallback applies to an encrypted APFS volume when the normal boot screen is unusable. It replaces neither the identity check nor the clear assignment of the recovery key. Depending on the Mac model and macOS version, macOS Recovery, a supported external startup volume or the Apple-provided connection or disk sharing to a second Mac are available.

1. Open Utilities > Terminal in the selected recovery environment.

2. Show the APFS structure as read only:

   diskutil apfs list
   

3. Uniquely identify the target encrypted volume by name, role, and APFS volume ID. Cancel if assignment is unclear; System, data, preboot and recovery volumes should not be confused.

4. Interactively unlock the target volume:

   diskutil apfs unlockVolume <VOLUME-ID>
   

   <VOLUME-ID> is replaced by the identified identifier. Only enter the recovery key at the interactive password prompt; never write it as a command argument or in a script.

5. Use diskutil apfs list and the Finder to check whether the correct volume is mounted and the expected data is readable.

Successful unlocking only proves that this key matches this APFS volume. It does not repair the Sophos agent or the key transfer and does not authorize further changes to the volume. Data is then backed up or the underlying issue is addressed in a controlled manner.

If the recovery key is not saved

If the agent cannot save the new recovery key in macOS Keychain or Sophos Fusion, Sophos displays it to the user and prompts them to save a copy. In addition, Sophos creates an emergency backup that is only accessible to root:

/Library/Application Support/Sophos Encryption/.RecoverykeyEmergencybackup

The agent retries the transfer. Once successful, it informs the user that Fusion is managing a new key and the manual copy can be destroyed. Until then, keep the key secret and do not treat a yellow status as a successful rollout.

If the status remains yellow after local login, network connection and re-synchronization or if the app, seadmin and Fusion contradict each other, the time, macOS and agent version, policy, affected volume ID and status indicators are recorded without a recovery key. Further diagnosis and escalation are covered in Systematically fix Sophos Device Encryption errors.

Controlled target state and offboarding

For macOS, there is no proven general Sophos procedure along the lines of “remove policy, remove user, auto-decrypt.” Likewise, uninstalling the Endpoint Agent does not transfer a FileVault key to new management. Therefore, establish a controlled target state before handover, tenant change, or agent removal:

1. Determine whether FileVault should remain active or be deliberately disabled by a local authorized administrator.
2. Document the last local state with fdesetup status, the pre-boot users with sudo fdesetup list and the affected internal volumes.
3. If FileVault remains active, provide evidence of recovery responsibility and an approved recovery path suitable for the device to the future owner. An old Fusion entry alone is not a handover.
4. If you want to disable FileVault locally, first make sure that the device encryption policy for the Mac is no longer in effect. Removing or disabling the policy does not decrypt FileVault; it prevents Sophos from requesting activation again. Then secure recovery access and a maintenance window, run the decryption under macOS and check that it has been completed locally.
5. Only when the target state, local evidence and recovery responsibility are correct, carry out the local agent removal according to Uninstall Sophos Endpoint on macOS.
6. Cleaning the device object in Fusion remains a separate administrative step and is neither decryption nor key transfer.

When switching to another management system, first test its FileVault and escrow capabilities on a pilot group. Retain the old recovery option until the new system has demonstrably adopted the intended target state and provides a tested recovery path.

Diagnose common deviations

No Sophos dialog after login

First check that the login was local rather than remote, that the Device Encryption Agent is installed, the user and policy assignment, and the last synchronization. Then check the Secure Token and, on Macs with Apple silicon, Volume Owner status. Without these requirements, repeatedly switching the policy is not a useful test.

User can boot macOS but cannot log in to FileVault pre-boot

The local account is not automatically a FileVault user. Match sudo fdesetup list with the expected user list, check Apple permissions, and follow the documented process to add a user. Then test with a restart. Logging out and logging in during the current session is not enough.

Fusion shows Encrypted, locally a volume is yellow

Encrypted alone does not prove a complete recovery state. Determine the specific volume and its key status in the Sophos Device Encryption app and with seadmin --device-encryption. Until a suitable recovery key is proven, the Mac does not pass validation.

FileVault is active, Fusion shows Pending or Not available

Check last synchronization, component, local user action and policy. If FileVault is already active, check whether the user has completed Create key. If the local and central states remain contradictory after renewed synchronization, do not start key rotation or policy experiments; preserve the evidence and hand the case over for troubleshooting.

Frequently asked questions