Systematically troubleshoot Sophos Device Encryption
Sophos Central orchestrates BitLocker and FileVault, but encryption itself remains an operating system function. A correctly assigned policy can therefore fail because of the TPM, firmware, Windows WMI, Group Policy, the user session or recovery-key management. Repeatedly enabling and disabling the policy tends to obscure the state rather than repair it.
Start the diagnosis with the Central alert and work through to the local error code. On Windows, the most important Sophos log is:
C:\ProgramData\Sophos\Sophos Data Protection\Logs\CDE.log
Also check manage-bde -status, the Windows Application Event Log, TPM status and the effective BitLocker GPOs. On macOS, consider the FileVault, user, Secure Token and recovery-key states together.
Distinguish the state first
| Display or error | Actual meaning | Next check |
|---|---|---|
Pending | Policy is active; encryption is waiting or running | User prompt, local session, GPO, TPM |
Suspended | Volume is encrypted, but its protector is currently suspended | Update, restarts, local administrator, manage-bde |
Recovery key is missing | Central does not hold a valid key | Communication, local key management, user change |
Device is not encrypted | At least one expected volume is unencrypted | Policy, supported volumes, local error code |
| Service does not start | Agent component is damaged or incompatible | Event Log and component log |
Before making a repair, record the device, user, policy, time, volume, error code and current recovery method. Do not decrypt a production system while the existing recovery-key state is unclear.
Use Endpoint Self Help in the correct order
Under About > Endpoint Self Help > Device Encryption, first resolve warnings in Services and Management Communication. Without a running Device Encryption service and current MCS communication, later encryption results are not reliable. Restarting the computer alone does not repair a missing service or communication path.
Then check installation, BitLocker Error, policy timestamp and volumes. For each volume, ESH shows encryption progress, lock state, protector and errors. Compare this local state with the effective policy and the device’s last activity in Central.
Frequent conflicts come from GPOs for encryption type, permitted protectors, TPM requirements, FIPS or recovery-key backup to Active Directory. Establish which policy source sets each option before changing Sophos or Windows settings.
BitLocker is Suspended
Suspended does not mean decrypted. The drive remains encrypted, but temporarily does not require a TPM PIN or password at startup. Windows or firmware updates can automatically suspend BitLocker for a specified number of restarts and then resume it. Sophos Central reports this state, but does not generally cancel an intentionally configured suspension itself.
The local status shows whether unprotected restarts remain:
manage-bde -status
Once the update is complete, or if an administrator suspended BitLocker, re-enable the protector in a controlled manner:
manage-bde -protectors -enable C:
Then restart, synchronise Central and check the status again. Investigate a suspension without an explainable change as a security event.
TPM-only fails with 0x80310048
The FVE_E_FIRMWARE_TYPE_NOT_SUPPORTED error means that Windows does not support the TPM-only protector because of the firmware or BIOS. The Sophos policy is not the cause. First update the BIOS or UEFI and the TPM firmware according to the manufacturer’s instructions.
If the hardware cannot provide a suitable TPM mode, a deliberately chosen policy without a TPM protector can fall back to password mode. This is a security decision, not a silent workaround. Check existing recovery keys before making changes.
Another TPM-only case simply needs the correct restart: if CDE prepared the hardware test, encryption starts only after Restart now in the Sophos prompt. Shutdown and a later cold start do not necessarily complete the same workflow.
A DMA-capable device blocks BitLocker
If Windows reports that BitLocker cannot be enabled because a DMA-capable device is not protected from external access, the block comes from Windows DMA security rather than Sophos. First identify the device or bus in Windows Event Viewer and confirm its purpose with the hardware vendor.
On Windows 10 and Windows 11 through 24H1, after that confirmation the vendor bus can be entered under HKLM\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses. Windows 11 24H2 and later ignore this allowlist, so firmware, driver and device compatibility must be corrected instead. Never broadly allow unknown buses, because this weakens the pre-boot threat model.
InvalidNamespace 0x8004100E
If CDE.log reports that volume information is missing because of ManagementStatus.InvalidNamespace, and manage-bde -status also returns 0x80041002, the WMI class Win32_EncryptableVolume is often registered incorrectly.
Re-register the Microsoft MOF file from an administrative command prompt:
mofcomp.exe C:\Windows\System32\wbem\win32_encryptablevolume.mof
manage-bde.exe -status
Only when the second command returns valid volume data again should the device be restarted and the PIN prompt repeated.
A tablet or slate does not accept a pre-boot protector
On devices detected as slates, Windows blocks a protector that requires keyboard input if the appropriate BitLocker policy is missing. A typical symptom is 0x803100B6 while creating the recovery protector.
Under Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives, enable Enable use of BitLocker authentication requiring preboot keyboard input on slates. Then run gpupdate /force or wait for the normal GPO refresh.
No UI prompt over RDP or Hyper-V Enhanced Session
The No UI user session available line in CDE.log often does not indicate a service error. Sophos intentionally displays the BitLocker dialogue only in a local interactive Windows session. A Network-Type sign-in over RDP or Hyper-V Enhanced Session must not activate encryption and then leave the device in an unusable pre-boot state.
The affected user must therefore sign in at the local console and complete the PIN, password or protector setup there. Remote operation can resume afterwards.
Boot media prevents startup
An inserted bootable CD or DVD, or a bootable ISO mounted in a VM, can block the BitLocker hardware test. If the test repeatedly returns to the initial state after restart, remove the boot medium, verify the boot order and repeat the Sophos prompt at the local console.
Device Encryption service with BadImageFormatException
If the Application Event Log shows that Sophos.Encryption.BitLockerService.exe terminates with System.BadImageFormatException, log4net.dll in the Sophos Data Protection directory may be damaged. The official Sophos KBA uses the intact copy from the AutoUpdate cache.
After preserving the logs and confirming the exact matching error pattern, replace the damaged file in
C:\Program Files (x86)\Sophos\Sophos Data Protection\
with log4net.dll from
C:\ProgramData\Sophos\AutoUpdate\Cache\decoded\enc\ProgramFilesFolder\Sophos\Sophos Data Protection\
After restarting, the Sophos Device Encryption Service must run again. If the cached file is missing or the error differs, do not improvise this repair. Collect an SDU and contact Sophos Support.
FileVault recovery key is missing or does not work
On an already managed Mac, a user can generate a new personal FileVault key locally. If the Sophos agent cannot validate that key, Central removes the now-invalid key from its database. The new key must then be obtained from the user or the management system that actually took ownership.
Linking the local user to an Apple ID or iCloud later can also change FileVault key management. Working FileVault encryption locally therefore does not prove that Central holds a current recovery key. Check the user, Secure Token, Volume Owner, MDM escrow and the time of the Central key together.
If an AD-bound Mac uses only a network account, that account cannot start encryption directly. Sign in with the network account once to create its local mobile account, then have an existing Secure Token administrator authorize it. Only after that does the user activate FileVault and the Sophos agent escrow the new key.
BitLocker does not start after MBR-to-GPT conversion
When a Windows 10 system with TPM 2.0 is converted from MBR and Legacy BIOS to GPT and UEFI, the recovery references stored in Boot Configuration Data may no longer match. Device Encryption then remains pending even though the disk and TPM appear ready.
Before repair, preserve the recovery key, BCD and current reagentc /info state. Then disable and re-enable Windows RE with reagentc /disable and reagentc /enable, verify the new recovery location and restart. Do not continue if Windows RE cannot be enabled or the recovery key is not secured. After the restart, check CDE.log and reagentc /info again before allowing the encryption process to continue.
Increase Device Encryption logging
CDE.log and the trace file can be configured from FATAL through TRACE using the documented 32-bit or 64-bit registry keys. The key path must match the installed agent architecture, and the Device Encryption service is restarted after the change.
Enable DEBUG or TRACE only for a narrow reproducible period because logs contain user, volume and policy information and can grow quickly. Restore the previous level after capture and transfer the files as sensitive diagnostic data.
When should the issue be escalated?
Open a support case if recovery-key availability is unclear, the repair does not precisely match the Sophos error pattern, or the service and encryption status remain contradictory after a restart. Include CDE.log, the SDU, manage-bde -status, effective BitLocker GPOs, the Central event, the exact time and all steps already performed.
The platform fundamentals are covered in Manage BitLocker with Sophos Central and Manage FileVault with Sophos Central.