Manage BitLocker with Sophos Fusion

Sophos Device Encryption enables and manages Microsoft BitLocker. The actual drive encryption and pre-boot authentication still come from Windows. Therefore, Windows hardware, firmware, BitLocker group policies and Sophos policy must fit together.

Quick path: Create a Device Encryption policy under My Products > Encryption > Policies, assign users or groups, set the Windows settings and activate the policy. An assigned user then logs on locally to the pilot device, handles the Sophos dialogs and reboots, and runs the pre-boot test. The rollout is only complete when the local BitLocker status, Sophos Fusion status and a suitable recovery key are confirmed.

Check requirements and compatibility

At least the following points must be approved before activation:

• Windows edition, build, patch level and lifecycle status according to System requirements and lifecycles for Sophos Endpoint. The historical protector matrix below does not approve old Windows versions.
• Sophos Core Agent installed and communicating with the Device Encryption component covered by the license.
• BitLocker support for the Windows edition and an authentication mode that matches the device.
• Activated, ready TPM; with TPM 2.0, a GPT-formatted system disk and UEFI mode.
• Sufficient space for system and recovery partition. Volumes that are 64 MB or smaller are ignored by Sophos.
• No second instance managing BitLocker protectors, encryption method or recovery keys at the same time.
• Established recovery process and authorized people before the first protector is replaced.

Dynamic Disks are not supported for the system volume; data volumes on dynamic disks are ignored. Windows partitions created using Boot Camp on a Mac are also not supported. Windows can encrypt removable media with BitLocker To Go, but Sophos Fusion does not manage status or recovery keys.

Sophos Device Encryption supports pre-provisioned BitLocker and pre-encrypted drives. It encrypts new volumes using software. It does not automatically change existing hardware encryption. BitLocker that has already been managed may only be adopted in a controlled change window and without parallel protector management. Sophos replaces the previous recovery keys. The old keys are then invalid and explicitly cannot be used to roll back. The complete, orderly procedure is available at Adopt existing BitLocker.

A TPM error will not be resolved by repeatedly turning the policy on and off. TPM readiness, Windows events, and local BitLocker status are checked first.

Configure device encryption policy

1. Open My Products > Encryption > Policies, select Add Policy and create a Device Encryption policy.
2. Assign users or user groups. On Windows, local login of an assigned user triggers the setup. The drive remains encrypted even if a user logs in without this policy.
3. In the Settings tab, activate the Device Encryption is on option.
4. Deliberately select or clear Encrypt boot volume only. If the option is switched off, supported fixed data volumes will also be encrypted after the system volume.
5. Under Advanced Windows settings, determine whether Require startup authentication is necessary. The option is active by default. If turned off, Sophos uses TPM only on compatible devices.
6. Use Encrypt used space only exclusively for newly provided devices. The initial encryption is faster, but previously deleted data in supposedly free areas can remain unencrypted.
7. If required, define the change interval for PIN or passphrase with Require new authentication password/PIN from users. This function is available under Windows from Device Encryption 2.0 and is switched off by default.
8. Save the policy, turn it on and first assign it to a representative pilot group.

If a setting is locked, it may come from a global preference set by the Sophos partner or enterprise administrator. Confirm its source before treating the local policy as incorrect.

Select authentication mode

The type of protector installed depends on the device, BitLocker GPO and Require startup authentication. 1 denotes Sophos’ first choice in the following matrix. 1* only applies if Require startup authentication is switched off. If the option is active, TPM only is not available and TPM + PIN is preferred on a compatible device.

Windows 7 and 8.1 are only included here so that the protector mapping documented by Sophos remains complete. They are not a current deployment recommendation and are checked separately against the linked lifecycle. The USB key is therefore only a historical Windows 7 matrix option, not a recommendation for a new rollout. In Windows FIPS mode, Sophos documents this BitLocker management for Windows 8.1, 10 and 11. This also does not constitute current operating-system approval. Windows 7 cannot store a FIPS-compliant BitLocker recovery password in Active Directory Domain Services.

• TPM only requires a prepared TPM and a GPO that allows this protection; in addition, Require startup authentication must be switched off. The mode does not cause any additional pre-boot step. This is operationally friendly, but less protective against an attacker who controls the device and an unlockable Windows environment.
• TPM + PIN requires a prepared TPM and a GPO that allows this protection. The PIN contains 4 to 20 characters and consists only of numbers, unless the GPO Allow enhanced PINs for startup also allows letters and special characters. All users of the same computer share this PIN. They then log in with their personal Windows credentials. Windows Single Sign-on is not supported. The mode increases pre-boot protection, but also implementation, help desk and recovery effort.
• Passphrase requires Windows 8 or later and a GPO that allows passphrase mode. The passphrase must be 8 to 100 characters long. It is the Sophos option for the non-TPM systems listed. Only the US English keyboard layout applies to the passphrase and PIN in the pre-boot environment. Special characters are therefore tested on the real hardware.
• USB Key must be connected, writable and formatted with NTFS, FAT or FAT32 at every boot; exFAT is not supported. This legacy option is not used as a fallback for an unsupported current device.

The selection follows the threat model, hardware and support process, not a blanket maximum hardening. If the applied protector differs from the expected line, Require startup authentication, TPM readiness, and BitLocker GPOs are checked first.

Clean up BitLocker Group Policies

Windows GPOs can specify authentication, algorithms, recovery storage, and hardware encryption. If the relevant authentication settings are set to Not configured, Sophos can set the GPO values to allow the intended modes. However, a manually configured default under Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives is not overwritten. Values set by Sophos also do not necessarily appear in the Local Group Policy Editor; they are below HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE.

Before the pilot, effective domain and local policies are documented with their provenance. The following are particularly checked:

• allowed startup protectors and TPM requirements,
• Recovery password and its additional storage, for example in Active Directory,
• Encryption method and software or hardware specifications,
• Smart card requirements and other settings that Sophos does not support.

Sophos encrypts new volumes by default using software-based AES-256; AES-128 is possible via group policy. An existing GPO that requires hardware encryption is not overwritten. Sophos Device Encryption does not support a smart card requirement for BitLocker and reports an error event. If the GPO and Sophos policy contradict each other, the encryption typically remains pending or ends in an error. Then the conflict is resolved instead of repeatedly reassigning the policy.

Network Unlock cannot be configured or managed with Sophos Fusion. A separately correctly set up BitLocker network unlock infrastructure can be used in parallel.

Guide the rollout and user prompts

Initial enforcement and pre-boot checking occur at the local console. The required dialogs are not displayed via Remote Desktop and the device encryption policy is not enforced. Pre-boot authentication cannot be carried out via Remote Desktop either.

The process on the device is:

1. The assigned user logs in locally; the agent connects and synchronizes with Sophos Fusion.
2. If the TPM is not yet enabled, the flow requests a firmware/BIOS action and a reboot. The agent tries to prepare an active but not yet initialized TPM and missing endorsement keys.
3. If the BitLocker system partition is missing, Sophos BdeHdCfg.exe starts, prepares the drive and requests a real reboot. No encryption will begin without a successful restart.
4. If startup authentication is active, the user sets the PIN, passphrase or USB key in the Sophos Device Encryption dialog. The prompt can be postponed with Do this later; however, encryption then remains pending.
5. Restart and Encrypt starts the pre-boot hardware test. If the entry fails before the first encryption, the user can start normally with Esc and will be prompted again the next time they log in.
6. After a successful test, Sophos first encrypts the system volume and then—if configured in the policy—fixed data volumes in the background. Their automatic unlocking is tied to the system volume.

The diagnostic logs CDE.log and CDE_trace.xml are located under %ProgramData%\Sophos\Sophos Data Protection\Logs. They are used for root cause analysis, but are not a replacement for the local BitLocker status.

Verify status and reporting

Under My Products > Encryption > Computers the device list can be filtered by encryption status and method. The computer details page shows the encryption method and algorithm per volume; under Windows additionally Encrypted since. For adopted or upgraded devices, this date may indicate the installation or upgrade time and is therefore not always the original encryption date.

For local, read-only checks, use an administrative command prompt or PowerShell:

manage-bde -status

Get-BitLockerVolume

For every intended volume, check at least the conversion or volume status, protection status, lock status, encryption method, and existing key protectors. Acceptance includes:

1. The system volume and all fixed data volumes covered by the policy are fully encrypted; the protection is active.
2. The actual installed protector corresponds to policy, GPO and risk approval.
3. Sophos Fusion shows the device under My Products > Encryption > Computers in the expected state and with a plausible method.
4. The recovery key associated with this volume is stored in Sophos Fusion. The rules for Show Key and readiness tests are available at Securely Retrieve Recovery Key.
5. Reboot and intended pre-boot authentication work on the real hardware.
6. A separate test device has gone through the agreed recovery process and a typical firmware/TPM change.

A progress value of 100 percent alone is not enough: without active protection and proven recovery readiness, the device cannot be accepted. Encryption events can also be evaluated under Reports > General Logs > Events; filtering, export and retention are described in Evaluate Sophos Endpoint Events and Reports.

Renew PIN or passphrase

A change interval is set in the device encryption policy with Require new authentication password/PIN from users. If the user closes the dialog, it reappears after every restart; after five closed requests, Sophos generates an alert.

For a single device, the admin opens the computer details page and uses the Trigger change of password/PIN action under Device Encryption in the Summary tab. The prompt appears again on the endpoint until the user sets a new secret; here too, closing it five times results in an alert. Pilot a forced change, and ensure that the helpdesk and users know the new secret will apply from the next pre-boot.

Restore Windows after key retrieval

The authorized retrieval and assignment is carried out by Retrieve recovery key securely. This section begins on the Windows BitLocker screen with the key already assigned and describes its use only.

For the actual Windows restore:

1. Restart the computer and press Esc at the BitLocker prompt.
2. Record the complete Recovery Key ID displayed on the screen and compare it with the retrieved key.
3. Enter the recovery key directly on the device.
4. Follow the on-screen instructions and set a new secret for PIN or passphrase operation.
5. Log in normally, synchronize and check that Sophos has stored a new recovery key.

If a data volume remains locked afterwards, the process is repeated with its own recovery key ID. A system volume key is not automatically the key of a data volume.

In the event of a hardware defect, the BitLocker drive can be connected to another BitLocker-enabled Windows system. There select Unlock Drive > More options > Enter recovery key and use the key ID shown. Before TPM wipe, protector manipulation or other state-changing workarounds, first ensure that a suitable recovery key is actually available.

After each recovery, the cause is clarified. A forgotten PIN, a BIOS update, a deactivated or deleted TPM, secure boot changes, a mainboard replacement and suspected manipulation require different follow-up actions.

Adopt existing BitLocker

Adopt BitLocker in this order:

1. Document per volume encryption method, protection status, protectors, recovery key ID and previous management. Check the currently usable recovery path and open a controlled change window.
2. Disable Protector changes from previous management before Sophos takes over management. Two administrations may never change protectors at the same time.
3. Install the Sophos component, assign an effective device encryption policy, and complete the local prompt.
4. Record when Sophos has replaced the existing BitLocker protectors and recovery keys. From this moment on, the previous keys are invalid and must not be treated as a way back; retaining the old key data does not make those keys usable again.
5. Keep the change window open and the old management infrastructure inactive but available. Verify in Sophos Fusion that the device appears correctly and the new Fusion key matches the tested volume. Demonstrate locally active protection and a successful restart with pre-boot input.
6. Only after this evidence can the old instance be taken out of operation.

A later switch to a third-party administration also takes place without parallel Protector administration in the change window described below.

Separate SafeGuard migration paths by initial state

Before each SafeGuard migration, the version, installed modules and actual drive encryption are inventoried. An unknown or mixed installation is a stop condition. Historical SafeGuard documentation does not provide evidence of current product support.

Lifecycle limit: There is currently no reliable current approval to continue operating or reinstalling SafeGuard Enterprise or SafeGuard File Encryption modules after migration. This article recommends neither. If file-based SafeGuard modules or files encrypted with them still exist, the migration will be stopped until Sophos Support confirms the specific version and module in writing and a verified access path for these files has been established.

SafeGuard Enterprise BitLocker 6.x or 7.x

This branch does not allow direct adoption. The system drive must first be decrypted using the procedure approved for the existing SafeGuard version. Recoverability, power supply, and free disk space are checked beforehand. Only after decryption has been fully confirmed and the old drive management has been removed in a controlled manner is Sophos Device Encryption installed, the policy assigned, and BitLocker re-encrypted. The new Fusion key and pre-boot authentication must be validated before the old recovery infrastructure is removed.

SafeGuard Enterprise BitLocker 8.0 or newer

With this branch, the SafeGuard BitLocker module can be removed without decrypting the BitLocker volumes:

1. Under Control Panel > Uninstall a program, select the Sophos SafeGuard Client with the right mouse button and open Change.
2. Only remove the BitLocker component in the SafeGuard installation wizard. Then confirm locally that the volume is still encrypted and accessible.
3. Install Sophos Device Encryption and assign an activated policy.
4. Verify synchronization, the new protector, the matching Fusion recovery key, protection status, and reboot.

This step applies only to the clearly identified BitLocker branch for version 8.0 or later. It does not permit any conclusions about continued operation of other SafeGuard modules. For those modules, the lifecycle limit above applies.

SafeGuard Enterprise Full Disk Encryption

Full Disk Encryption is technically a different branch and should not be treated like SafeGuard-BitLocker 8+. During assisted removal of the SafeGuard Client, the volumes encrypted with it are decrypted; File-based encrypted files can remain encrypted. This is precisely why installed modules and data access are clarified before removal. If file-based modules are involved, the above-mentioned stop condition applies until the written lifecycle and migration approval.

All Sophos Device Encryption and BitLocker prerequisites are prepared before decryption begins. The unencrypted window begins with the confirmed full SafeGuard decryption and only ends when BitLocker protection and the Fusion recovery key that matches the volume have been validated. This window is limited in time in the change plan and kept as short as possible.

During the unencrypted window, the device remains in controlled maintenance mode: it is not used productively, only those authorized to change it are granted access, and network access and data transfers are limited to the extent required for installation and acceptance. After the approved removal, Sophos Device Encryption is installed, the policy is assigned and the volume is immediately re-encrypted with BitLocker. The change window remains open until local BitLocker protection is active, the appropriate Fusion Recovery Key has been proven and the restart and intended pre-boot authentication have been successful. The entire migration consists of decryption and re-encryption; it is not a direct protector adoption.

Decrypt and decommission in a controlled manner

First, the target state is determined: Should the device be completely decrypted, or should BitLocker remain active under successor management? Agent uninstallation, device record deletion, and decryption are three different operations.

This order applies to a planned decryption:

1. Depending on the type of policy, remove all users or the computer from the effective device encryption policy and confirm the synchronization.
2. With the local Windows administrator account in Windows Explorer, select Manage BitLocker > Turn off BitLocker on the volume.
3. Ensure power and maintenance windows and monitor decryption until completion.
4. Use manage-bde -status or Get-BitLockerVolume to confirm that each intended volume is fully decrypted and protection is off.
5. Only after complete decryption has been verified should the local agent be removed according to Uninstall Sophos Endpoint on Windows. Any subsequent deletion or restoration of the Fusion device record is carried out separately by following Replace or retire Sophos Central device.

If a local administrator attempts decryption while the device encryption policy is still active, Sophos Fusion overrides the local command and the drive remains encrypted. Conversely, simply removing a policy or agent does not prove that BitLocker is deactivated or that decryption has been completed.

If BitLocker is to remain in place, transfer its management in this order:

1. Open a non-overlapping modification window. Prove current local BitLocker protection and a current Sophos recovery key that matches the volume; BitLocker stays on.
2. Remove or disable local Sophos management only according to Uninstall Sophos Endpoint on Windows.
3. Only then immediately include the device in the successor management. No two administrations may change protectors at the same time.
4. Generate a new, suitable recovery key in the successor administration and keep it safe.
5. Check the local protection status and reboot. Only after this evidence has been provided can the Sophos custody of the recovery key be released and the change window closed.

Subsequent deletion or restoration of the record in Sophos Fusion remains a separate administrative action performed by following Replace or decommission Sophos Central device; it is not a local uninstall.

If the acceptance fails

Do not experiment with repeated policy turning on and off, TPM clearing, or protector changes. First narrow down the symptom and level:

• No prompt: Check user/policy assignment, local instead of RDP login, agent synchronization and installed device encryption component.
• Prompt postponed: The user closes the dialog and completes a real reboot at the local console.
• Pre-boot test failed: Check TPM/firmware, keyboard layout, effective GPO and Windows event; it is not yet encrypted.
• Locally encrypted, not accepted in Fusion: Check device synchronization, recovery key receipt and volume mapping. The central recovery process applies to the secure retrieval check.
• Unexpected protector or algorithm: Compare effective domain and local group policies and existing hardware encryption with the Sophos policy.
• Recovery after firmware change: First preserve the appropriate key and confirm the cause. Only then should you consider a state-changing repair.

Concrete alerts, TPM, WMI and service errors as well as secure log collection are covered in Sophos Device Encryption errors systematically.

Frequently asked questions