Adopt or migrate Sophos Device Encryption

Do not adopt existing encryption based solely on the operating system. Four questions are crucial: Which technology encrypts the volume, which system manages it today, which recovery path works and which target state has been agreed upon? Choose a specific migration path only after confirming these points.

Quick decision: Existing native BitLocker or FileVault is usually adopted, not decrypted first. An unencrypted device is deployed in the usual way. SafeGuard BitLocker, SafeGuard Full Disk Encryption (FDE), and SafeGuard-managed FileVault are separate initial states. If there is an unknown SafeGuard version, mixed modules or no current confirmation from Sophos Support, the process stops and does not continue with historical instructions.

Before making a decision: preserve evidence and recovery access

The inventory is kept per device or homogeneous device group. A status such as Unmanaged in Sophos Central or Sophos Fusion only describes that Sophos Device Encryption does not manage the device. It neither proves that the volume is unencrypted nor who has an existing recovery key.

Before a policy is assigned, uninstalled or decrypted, at least the following evidence is recorded:

• Device identity, operating system, supported platform lifecycle and target tenant,
• each internal volume with encryption technology, encryption progress and local protection status,
• responsible management system: operating system or MDM, Sophos Fusion, SafeGuard Enterprise or unknown,
• installed encryption modules including the exact product version; for SafeGuard, also record FDE, BitLocker management and file-encryption components separately,
• effective policies, BitLocker protectors or FileVault pre-boot users,
• Recovery key ID and responsible storage without copying the key to inventory, ticket or screenshot,
• tested, authorized access to the currently appropriate recovery key,
• open processes for encryption, decryption or key escrow.

The system requirements and lifecycle limits for Sophos Endpoint are reviewed prior to technical planning. If the local encryption state is unknown, a process is still active or the recovery path cannot be tested, the device remains unchanged. Processing stops; a trial uninstallation is not a valid diagnosis.

Recognize initial state and choose path

The table only identifies the appropriate platform instructions. Click sequences, commands, protector changes, and decryption are described only there so that the same security-relevant process is not performed differently in several places.

For execution, always open the platform instructions linked in the table and use only the section for the documented initial state. If that section is missing or does not cover the detected version and installed modules, do not proceed with a general BitLocker or FileVault flow. Leave the state unchanged and provide the inventory to Sophos Support. Selecting a migration path never permits retaining a SafeGuard module or continuing to operate it in parallel.

Already Sophos managed

If the right device object in the right Fusion tenant reports an effective device encryption policy, no migration is necessary. Nevertheless, local status, Fusion status and assignment of the recovery key are compared. A green or encrypted status of a similarly named old device is not proof of the current device.

For Windows, validate the result under Manage BitLocker with Sophos Fusion - Verify activation. On Mac, use Manage FileVault with Sophos Fusion - Check encryption and recovery status.

Adopt native BitLocker or FileVault

With native BitLocker, the volume remains encrypted. The execution and consequences of changing the protectors and the recovery key can be found under Migrate existing BitLocker. As soon as Sophos has replaced the BitLocker protectors, the previous recovery keys are no longer a way back. The previous recovery path therefore remains available until immediately before the confirmed takeover. After that, it may no longer be planned as a return route.

With native FileVault no prior routine decryption is necessary either. The section Adopt an already active FileVault describes the local user confirmation, the generation of a new personal recovery key and the verification of the key deposit. The previous recovery method is only discarded when the new key that matches the Mac can actually be accessed in Fusion.

Only a device confirmed locally as unencrypted bypasses migration. For Windows, start with Check prerequisites and compatibility; for macOS, start with Requirements before first assignment. An Unmanaged or unknown inventory status alone is not sufficient for this classification. If the local check already shows BitLocker, FileVault, or SafeGuard, follow the appropriate adoption, migration, or support instructions instead; do not treat the device as unencrypted.

SafeGuard BitLocker: distinguish versions 6/7 from 8 or later

Although SafeGuard BitLocker uses BitLocker as the encryption technology, the management and protector states are version-dependent. Therefore, devices with SafeGuard 6 or 7 are not changed together with devices from SafeGuard 8.

• SafeGuard 6 or 7: Do not infer from historical guidance that an upgrade, interim release, or specific uninstall is still supported today. Without current written confirmation of the version found, the migration stops. If confirmation is available, work exclusively from SafeGuard Enterprise BitLocker 6.x or 7.x.
• SafeGuard 8 or newer: BitLocker is adopted without routine decryption. Here too, a current written confirmation must cover the exact SafeGuard status and the affected modules. The specific order is listed under SafeGuard Enterprise BitLocker 8.0 or newer, not in this decision aid.

Mixed estates are divided. If there are unknown versions, FDE and BitLocker components detected at the same time, or additionally installed file encryption modules, the migration stops. Such modules are neither retained nor reinstalled as a precautionary measure.

SafeGuard Full Disk Encryption: decrypt and re-encrypt

SafeGuard FDE is not just another management system for BitLocker. This initial state requires full decryption and re-encryption: the source encryption is completely decrypted via a currently confirmed written SafeGuard process, its completion is documented locally and only then is BitLocker deployed again under Sophos Fusion.

Without current written confirmation of the exact, time-limited FDE migration step, do not start this path or attempt to force it by continuing to operate or reinstalling old SafeGuard components. Instead, provide the version, module, volume, and recovery evidence to Sophos Support. If confirmation is available, work exclusively according to SafeGuard Enterprise Full Disk Encryption. The process described there must cover staged FDE decryption, local evidence of its completion, a limited unencrypted window, and the subsequent BitLocker deployment. If any of these steps are missing, the case remains stopped; general BitLocker decryption is not a substitute.

SafeGuard-managed FileVault

On a Mac, it is first proven that Apple FileVault actually encrypts and which SafeGuard modules only take over the administration. The order of decryption or decommissioning on Windows is not carried over to FileVault.

If Sophos Support confirms the time-limited migration step in writing, follow FileVault - SafeGuard initial state. Do not continue if there are unknown or mixed modules. This confirmation also does not permit a SafeGuard file encryption module to be retained, reinstalled, or operated in parallel. Such a project remains stopped until Sophos Support provides separate written clarification.

Verify the target state

The existing management system will only be decommissioned once all of the following criteria have been met for the specific device:

1. The device identity and the target tenant are correct.
2. The local volume status shows the agreed encryption state; no encryption or decryption process is unexpectedly open.
3. Fusion displays the intended policy and appropriate managed status.
4. An authorized admin can retrieve the new recovery key that matches the device and the displayed key ID without disclosing it in the acceptance report.
5. Pre-boot access and controlled reboot work with the intended users or protectors.
6. The current recovery and management path remains available until this evidence is complete.

If even one of these items is missing, do not continue the rollout. With BitLocker, do not plan to use the old key as a return route after a protector change. With FileVault, uninstalling the agent is never evidence that responsibility for the key has been transferred.

Rollback, decommissioning and escalation

Before the actual change, prepare the return path: stop policy assignment, limit the pilot, and maintain the previous recovery path. After a protector change or decryption has begun, there is no general return to the previous state. Preserve the current state, verify it again using the appropriate platform article, and continue only through a currently supported path. Do not reinstall or continue operating SafeGuard speculatively in an attempt to restore the previous state.

If the local Sophos endpoint agent also needs to be removed after successful encryption transfer, only the following platform-specific instructions apply:

• Uninstall Sophos Endpoint on Windows after the BitLocker target state and recovery responsibility are established,
• Uninstall Sophos Endpoint on macOS after the FileVault target state and tested recovery responsibility are established and the local evidence has been provided.

Subsequent deletion or restoration of the Fusion device record is a separate task. It is part of Replace or retire Sophos Fusion device. Neither deleting the record nor uninstalling the agent automatically decrypts a volume or transfers a FileVault key.

Escalation to Sophos Support occurs if the SafeGuard version or modules are unknown, a current product lifecycle approval is missing, the recovery cannot be tested before the switch, the responsible management system and the local encryption status conflict, or a key or protector switch has begun without suitable new recovery evidence. Device and volume identities, versions, module inventory, status times and error messages are provided—but no recovery key.