Skip to content
Avanet

Manage BitLocker with Sophos Central

Sophos Central Device Encryption activates and manages Microsoft BitLocker. Windows continues to provide the underlying encryption and pre-boot authentication. Microsoft hardware and Group Policy requirements therefore apply alongside the Sophos policy.

Prepare the system

Check the following before activation:

  • a supported Windows edition and current patches,
  • TPM is present, enabled and operational,
  • UEFI or BIOS and Secure Boot are in the intended state,
  • system and recovery partitions have sufficient space,
  • no competing encryption management is active,
  • the recovery key can be stored securely in Central.

Repeatedly enabling the Sophos policy does not resolve a TPM fault. Windows Events, TPM Management and BitLocker status reveal the cause.

Choose the authentication mode

Depending on the policy and platform, TPM only, TPM plus PIN, Passphrase or USB Key may be available. Not every mode is equally suitable for every Windows and hardware combination.

TPM only is convenient, but provides less protection against an attacker who has the device and a signed-in or unlockable environment than an additional PIN. TPM + PIN strengthens pre-boot protection, but increases support and recovery effort.

The choice is based on the risk model, hardware capability and user process, not on a generic maximum-hardening approach.

For a PIN or passphrase, account for the pre-boot keyboard: Sophos documents support for the US English layout only. Special characters may therefore be on different keys at the next startup. If a USB key is required, format it as NTFS, FAT or FAT32. Test both options on the actual hardware before deploying the policy widely.

Check Group Policy

Windows GPOs can enforce BitLocker algorithms, authentication, recovery and hardware requirements. Conflicting GPO and Central settings result in pending encryption or errors.

Sophos does not override existing settings under Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives. Values set by Sophos are not necessarily visible in Local Group Policy Editor, but are stored under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE.

Before rollout, export or document local and domain policies. Pre-boot authentication, compatible TPM, recovery-key backup and the encryption method are especially relevant.

Central Device Encryption always encrypts new volumes using software and AES-256 by default; Group Policy can select AES-128. Existing hardware-based BitLocker encryption isn’t converted automatically, and an existing GPO that requires hardware encryption isn’t overridden. A BitLocker smart-card requirement isn’t supported by Central Device Encryption and generates an error event.

Understand the limitations

Dynamic Disks are not supported for the system volume; data volumes on Dynamic Disks are ignored. Windows partitions created on a Mac through Boot Camp are also unsupported.

Do not perform initial enforcement through a Remote Desktop session alone. Sophos does not display the required prompts there, and the user must be able to test pre-boot authentication locally.

Network Unlock cannot be configured through Sophos Central. An existing, correctly configured BitLocker Network Unlock infrastructure can, however, continue to operate alongside it.

Validate activation

If the required BitLocker system partition is missing, Sophos runs BdeHdCfg.exe, prepares the drive and requires a real restart. Encryption doesn’t begin while the user postpones the restart or authentication-mode dialog. After a successful hardware and pre-boot test, the system volume is encrypted first, followed by the selected fixed data volumes. The diagnostic logs CDE.log and CDE_trace.xml are stored under %ProgramData%\Sophos\Sophos Data Protection\Logs.

After the policy is assigned, the user signs in and follows the Sophos prompt if one appears. The administrator verifies:

  1. BitLocker status locally with Windows tools.
  2. Central reports the device as encrypted.
  3. The recovery key is present and can be retrieved.
  4. Restart and the intended pre-boot authentication work.
  5. Hardware change and recovery have been simulated on a test device.

Retrieve a recovery key

Release a recovery key only after the defined identity check. The administrator opens the affected device or user and follows the recovery workflow provided by Central.

After recovery, determine why BitLocker Recovery was triggered. A BIOS update, TPM change, Secure Boot change and suspected tampering require different responses.

If the organisation supports Self Service, the most recent Central user to sign in can retrieve the key through the enabled Self Service Portal. When the Helpdesk provides a key, compare the device, user and displayed recovery-key ID.

Read a failed computer from another device

If an encrypted computer no longer starts because of a hardware failure, connect the BitLocker drive to another BitLocker-capable Windows system. On the locked drive, select Unlock Drive > More options > Enter recovery key and note the displayed Key ID.

In Central, My Products > Encryption > Computers > Retrieve Recovery Key can locate the correct key even if the original computer has already been deleted or its hostname is unknown. Enter the Key ID, select the matching volume and use Show Key only after the required identity and approval check. Enter the key directly on the recovery system and do not store it permanently in a ticket.

Renew a PIN or passphrase

The policy can prompt users to change their PIN or password at a defined interval. A change can also be triggered immediately for an individual computer. Sophos generates an Alert after five dismissed prompts.

Test an enforced change in a pilot group first. The Helpdesk and users must know that the new secret applies at the next pre-boot.

Migrate existing BitLocker

For an already encrypted device, check protection status, protectors and recovery-key escrow before adoption. A migration from Sophos SafeGuard Enterprise or another management platform follows the current Sophos migration path.

Do not retire the previous management platform until Central manages the recovery key reliably.

Decryption

Trigger planned decryption through the supported workflow and monitor it to completion. First remove all users of the device from the Device Encryption policy. A local Windows administrator can then use Manage BitLocker > Turn off BitLocker. While an Encryption policy remains effective, Sophos Central overrides a manual decryption attempt and the drive stays encrypted. Consider laptop power, the time required and data risk.

Simply removing the Central policy or agent does not prove that BitLocker is disabled or the drive has been decrypted.

Specific error codes for TPM, WMI, the Slate GPO, suspended BitLocker and the CDE service are covered in Systematically troubleshoot Sophos Device Encryption.

Frequently asked questions

Why does BitLocker not start despite an assigned Sophos policy?

TPM state, Windows edition, partitioning or conflicting Group Policy commonly prevent activation. Check the Central assignment and local BitLocker status together.

Is TPM only always the best setting?

No. It is convenient, but has a different risk profile from TPM plus PIN. The choice depends on the threat model, hardware and support process.