Securely introduce Sophos Fusion Device Encryption

Sophos Fusion Device Encryption centrally manages disk encryption for Windows and macOS. The actual encryption still comes from the operating system: BitLocker on Windows, FileVault on macOS. Sophos distributes the policy, records the status and manages recovery keys, but does not replace the encryption engine or the platform-specific requirements.

For a resilient rollout, five things must come together: a valid license entitlement, the installed device encryption component, an effective policy, a supported local state, and a functioning recovery process. A successful agent installation or the display of “100 percent” alone is not enough.

What Sophos manages – and what it doesn’t

Device Encryption protects startup volumes and, depending on the policy, fixed internal data volumes. Removable media is not included. Although BitLocker To Go can encrypt such volumes, Sophos Fusion does not manage status or recovery keys.

You can access the administration under My Products > Encryption. The two areas have different tasks:

• Under My Products > Encryption > Policies it is determined for whom Device Encryption is active and which volumes are included.
• Reported health, missing components, and recovery readiness are assessed under My Products > Encryption > Computers.

The policy is assigned to users or groups. Under Windows, the login of an assigned user is sufficient to initiate encryption; a user who logs in later without a suitable policy does not remove the protection. On a Mac, all intended users must be covered by the policy for user enablement and recovery management to work fully. Shared devices and local accounts are therefore expressly included in the pilot.

Requirements before the first policy

First, confirm whether the subscription includes device encryption. Contract and metering issues belong in the Sophos Fusion Licensing Overview. The most important thing for the rollout is that the function is available in the tenant and corresponds to the intended scope.

The operating system, architecture and lifecycle are then approved. This information changes more quickly than a rollout concept and should not be copied into the encryption documentation as a static version list. The procedure for this is described in Sophos Endpoint system requirements and lifecycle planning.

For an already encrypted device, the rollout doesn’t start from scratch. Before assignment, the local BitLocker or FileVault status, existing recovery keys, group policies or MDM specifications and a previous encryption product are inventoried. Two administrative systems must not enforce contradictory requirements at the same time. The appropriate takeover then takes place in the BitLocker process for Windows or in the FileVault process for macOS, not via a blanket on/off switch.

The component also has to actually exist. Under My Environment > Installers the complete Windows or macOS installer contains the endpoint products covered by the license. Device Encryption can be specifically selected via Choose Components…. On Mac, the Device Encryption Agent is installed separately. Completing the installation is still only an intermediate step: the policy, reported status and readiness for recovery are then crucial.

Treat license expiration as a recovery risk

After the encryption license expires, the Device Encryption page disappears from the Self Service Portal. Users can no longer retrieve recovery keys there themselves. Sophos also removes most of the encryption components from the device, but retains components that are needed for later reconnection.

This does not turn off BitLocker and FileVault and does not decrypt the drives. This is exactly where the risk lies: the data remains protected while central administration and self-service are restricted. If a BitLocker recovery key changes in this unmanaged phase, Central can initially still know the old key after a later reactivation.

License renewal and recovery must therefore not depend on the same single team. The responsible person, expiration date, escalation path, and an approved recovery path are determined before rollout. Retrieval, disclosure, and case documentation are described in Retrieve Recovery Key Securely.

Start the rollout so small that errors remain manageable

The base policy is not activated tenant-wide without being checked. A good pilot group represents the differences that actually influence the encryption process: hardware generations, notebook models, operating system versions, local account types, and already active encryption. It is equally important to include a device without existing encryption so that the new setup can also be checked.

A Device Encryption policy is created under My Products > Encryption > Policies and first assigned to this pilot group. Encrypt boot volume only determines whether fixed data volumes outside of the boot volume are covered by the Sophos policy. The choice depends on where the data actually resides on the devices. The Windows option Encrypt used space only shortens the initial encryption, but can leave deleted areas on already used disks unencrypted; it is therefore intended for newly deployed computers.

The further decisions are platform-specific. TPM, pre-boot authentication, BitLocker group policies and partitioning are specified in the Windows guide. FileVault users, local authorization and the personal recovery key belong in the Mac guide. This means the common policy remains understandable without mixing two different security models.

Don’t end a rollout at 100 percent

The technical acceptance connects Central with the local device. Verify the following for each pilot device:

1. The intended policy is effective on the correct user and device.
2. The volume covered by the policy is fully encrypted locally.
3. My Products > Encryption > Computers reports the expected status Encrypted.
4. The recovery path associated with this device and volume is available and organizationally approved.
5. Reboot, login and the intended pre-boot authentication work.
6. Alerts, responsibilities and escalation were tested using a safe test scenario.

The rules for readiness testing and key disclosure are in the central recovery flow; unlocking and follow-up control remain with the respective BitLocker or FileVault process. A pending user prompt, a necessary restart or a missing central key prevents acceptance even if the operating system is already showing encryption progress.

Read the seven Central status values correctly

The status under My Products > Encryption > Computers is a condensed Central view. It does not replace local checking, but helps route devices to the correct queue.

Pending is not an error code and Suspended is not a synonym for decrypted. If a status remains unchanged, contradicts the local state or the recovery key is missing, the case belongs in systematic device encryption troubleshooting instead of repeatedly switching the policy on and off.

Separate three similar-looking inventories

The term “unmanaged” can hide various causes in Central. Three cases are therefore separated for the cleanup:

• The status Unmanaged in the computer list means that Device Encryption is present, but no appropriate policy is in effect.
• The Computers without Device Encryption installed filter under My Products > Encryption > Computers shows managed computers that are missing the Encryption component.
• After an AD sync, the Unmanaged computers tab also contains devices that are known from Active Directory but do not have Sophos protection.

These groups need different measures. A policy assignment does not automatically install every missing component, and a computer known from AD is not yet a managed endpoint. Only the cause decides whether assignment, installation, inventory cleanup or a deliberate exception is correct.

Clearly separate responsibilities within the company

The Securely retrieve recovery key process handles the joint retrieval and secure output. This is followed by the BitLocker Guide or the FileVault Guide.

During a takeover or migration, the initial state is recorded first. Adopt or migrate Sophos Device Encryption then selects the appropriate Windows or macOS process. The old management and previous recovery path remain in place until the new status is accepted locally and in Central. Unknown SafeGuard versions or mixed modules are a stop signal and will be clarified before changes are made; historical release notes are not current support approval.

Retiring a device is also more than deleting a Central record. First, the encryption target, recovery responsibility and local uninstallation are clarified. Only then should you follow the Replace or decommission the Sophos Fusion device process. In particular, an agent uninstallation does not transfer a FileVault key to new management.

Password-protected file sharing on Windows is a standalone Device Encryption feature, not drive encryption or evidence of a successful BitLocker rollout. Therefore, plan and test the policy, delivery method, recipient process, and separate password transmission in this dedicated workflow rather than enabling the feature incidentally in the rollout policy.

Frequently asked questions