Sophos Device Encryption: Fix BitLocker and FileVault errors

Sophos Fusion (formerly Sophos Central) controls device encryption, but does not itself encrypt data: BitLocker works under Windows, and FileVault works under macOS. An error can therefore occur at four different levels: policy and user assignment, Sophos agent and synchronization, operating system, or recovery key management.

Safe shortcut: Record the Central status and the wording of the alert, check the local BitLocker or FileVault status in a read-only manner, and confirm that a valid recovery path exists. Only then investigate the affected branch. Switching the policy off and on repeatedly is not a diagnosis and can change the status, key management, or an ongoing encryption or decryption process.

Route standard recovery cases

This runbook diagnoses anomalies but does not retrieve or disclose a recovery key. A normal recovery request goes to Sophos Device Encryption: Securely retrieve recovery key.

After the authorized handover of the uniquely assigned key, unlocking takes place on the respective platform: on Windows in the article Managing BitLocker with Sophos Fusion, on macOS in the FileVault administration flow. The retrieval, disclosure and unlock steps are not duplicated here.

Do not confuse Central status and alert

The Encryption Status describes the state of the device last reported to Central. An Alert, on the other hand, reports a specific deviation. An old status with a current local display therefore initially indicates communication or synchronization, not automatically a defective encryption.

The seven status values

Pending does not mean “policy is basically waiting for application”, and Suspended does not mean “volume is decrypted”. Encrypted alone is not enough for acceptance: the recovery key must be available to the responsible recovery process.

The three device encryption alerts

Device is not encrypted means that a volume is not encrypted even though it should be encrypted according to the policy. One possible reason is that the user postponed encryption after policy assignment. Next, the affected volume, an open user prompt, and local encryption progress are checked.

Recovery key is missing means that Central cannot find a recovery key for an encrypted volume in its database. This is a recovery risk, not proof of an unencrypted drive. You check communication, last synchronization and the responsible recovery key inventory without recording the key in the case notes.

Device Encryption is suspended reports suspended BitLocker encryption. If this wasn’t done intentionally, Sophos gives three typical reasons:

• The recovery key has not yet been saved in Central. The endpoint requires a working internet connection.
• Pre-provisioned BitLocker is not activated yet. The user must define PIN, password or USB key depending on the intended mode.
• Windows updates are installed. BitLocker will automatically remove the suspension after the next reboot.

Only when these three cases have been ruled out will an unplanned administrative intervention or a deeper Windows error be looked for.

A process for each error pattern

1. Freeze state and secure recovery

Before the first change, note:

• Device name and Central device ID;
• Operating system, build and time of problem;
• assigned policy and affected user;
• exact status, alert text, error code and timestamp;
• affected volume and whether it is currently being encrypted or decrypted;
• whether the person responsible for recovery has confirmed a suitable, current key.

The work log only says Key present, Key missing or still unclear. The key itself and complete key IDs are not recorded.

2. Compare central and local status

Four results lead in different directions:

1. Both sides report the same condition: Troubleshoot the local symptom.
2. Locally correct, Central outdated: Check agent communication, policy timestamp and last synchronization.
3. Centrally correct, locally inconsistent: Check the specific volume and the native operating system display; do not draw conclusions about all volumes from an overall status.
4. Both sides unknown or conflicting: Do not perform a state-changing repair. Create and escalate a diagnostic package.

3. Check policy application

An installed component does not prove that a policy is in effect. Check that:

• Policy is turned on and assigned to the intended user or their group;
• the user logged in to the device is assigned to the correct device in Central;
• no higher priority or global default explains the visible setting;
• the time of the last policy application is newer than the last change;
• no GPO, MDM policy or previous encryption management enforces a different state.

Correct an assignment at its source. Setting local policies across the board to Not configured or repeatedly toggling a central policy only obscures which management system actually took precedence.

Windows: BitLocker does not start or remains pending

First check locally and only read

In an administrative command prompt, Windows shows the status of all BitLocker volumes:

manage-bde -status

What is important for each volume is Conversion Status, Percentage Encrypted, Protection Status, Lock Status and the existing Key Protectors. The output may be sanitized for support; recovery passwords and other secrets are removed.

The most important Sophos log is here:

C:\ProgramData\Sophos\Sophos Data Protection\Logs\CDE.log

In addition, review the relevant period in Windows Event Viewer, the TPM state, and the BitLocker group policies that are actually in effect. The first reproducible error after policy application or restart—not the number of warnings—determines the next step.

The user does not see an activation dialog

If the expected dialog is missing, the session type, logged in user, exact log text, time and pending restarts are only documented. Neither a specific session cause nor a service defect is derived from a single log entry. A change of session type or restart only takes place according to the current Sophos instructions applicable to the installed version; then manage-bde -status, the new CDE.log timestamp and Central are compared again.

Policy and GPO contradict each other

Typical conflict areas include startup authentication, allowed protectors, TPM requirements, FIPS, encryption method, and recovery key backup. You document the effective GPO and compare it with the central policy. Then correct the responsible management configuration. The troubleshooting case is not the place to circumvent the security concept with a local workaround.

Normal configuration, protector selection and GPO tuning are explained in Managing BitLocker with Sophos Fusion.

BitLocker is Suspended

Suspended does not indicate decryption, but rather suspended protection on at least one volume. First, a running Windows or firmware update, pending restarts, pre-provisioning and the central storage of the recovery key are checked.

• If a documented update process has not yet been completed, complete its intended restart sequence and then check again.
• If an administrator has knowingly suspended BitLocker, the person responsible for the change decides whether to resume protection.
• In the absence of an explanation, the suspension is considered a security deviation. Do not blindly force protection to resume; instead, record the time, event and protector state for the escalation.

Activation error with TPM, firmware or DMA context

For a hardware-related activation error, document the exact error code, current TPM/UEFI state, intended authentication mode, and firmware and driver versions. Do not infer a cause or repair without current instructions specific to the model and the Windows and Sophos versions. Older signatures are therefore classified only in the support-controlled historical section.

When reporting an unprotected DMA-capable device, the device manufacturer must confirm whether the bus and device are internal and secure. A registry entry under AllowedBuses, changes to ACLs, or blanket release of unknown buses are not a general repair. The behavior also differs between Windows versions. The registry will not be accessed without current, model- and version-specific OEM or Sophos instructions.

macOS: FileVault is waiting for user or recovery key

Diagnose user authorization

FileVault requires a locally authorized user. On Apple silicon, this includes a volume owner. The appropriate secure token status is also relevant for administration. Therefore, check:

• Is the currently locally logged in user covered by the device encryption policy?
• Can this user actually unlock FileVault on startup?
• Is the expected user visible in the Sophos Device Encryption app?
• Are secure tokens or volume owner authorization available?
• Is a Sophos dialog waiting for the macOS login password or for Encrypt, Create key or Proceed?

You do not create a new local or mobile account as a precaution and do not change user authorization until the missing requirement is clearly established. Supported authorization of additional users is covered in the FileVault management flow.

FileVault is active, but Central has no key

“FileVault active” and “Recovery Key managed in Central” are two different statements. For each volume required by the policy, local encryption status, recovery indication in the Sophos Device Encryption app, and last Central timestamp are compared.

The documented Sophos queries are read-only:

/usr/local/bin/seadmin status
/usr/local/bin/seadmin --device-encryption

status helps compare the last synchronization. --device-encryption shows the policy as well as the encryption and recovery status of the internal volumes. Do not accept an encrypted volume as a successful rollout without confirmed central key storage.

If Sophos displays a personal recovery key after a failed save, secure interim storage remains with the person responsible for FileVault. The key is not copied into the diagnostic package. The supported handling of this sole key and the later Central confirmation are in the linked FileVault article. This runbook does not replace the recovery process.

Encryption or decryption stops

An unchanged percentage value is not yet a reason to restart encryption management. First, compare the following over a meaningful interval:

• local progress of the specific volume;
• power supply, free disk space and pending reboot;
• last policy and agent timestamp;
• OS events at the same time;
• concurrent encryption management;
• expected target state: encrypt, adopt or decrypt.

In the case of a planned decryption, the person responsible for change confirms the target state, responsibility for the recovery key and platform flow. The Windows procedure is in the BitLocker article, and the macOS procedure is in the FileVault article. In the event of an unexpected decryption, the process is not overridden by hectic policy changes; device, policy change, and events are investigated as a security deviation.

Unmanaged, existing encryption and migration

Unmanaged simply means that the device encryption component is installed, but no device encryption policy is applied. The storage device can be encrypted or unencrypted. This is not an instruction to assign a policy immediately.

Before adoption or migration, the source state is inventoried:

1. Platform, volumes and local encryption state.
2. Active protectors or authorized FileVault users.
3. Previous management system and effective GPO/MDM specifications.
4. Verified recovery path under previous management.
5. Intended target state and exactly one responsible target system.

Then choose exactly one platform branch. Perform the work through the BitLocker or FileVault procedure. Do not discard the previous recovery path or decommission the old management system until the new recovery key is confirmed in the target system.

The lists in Central also have different meanings: Computers without Device Encryption installed shows managed devices without an encryption component. However, Unmanaged computers can contain computers synchronized from the directory without Sophos protection. Before taking an installation or policy action, determine which list contains the device and why it appears there.

Historical signatures: recognize, don’t repair yourself

The following signatures are from legacy Avanet operational experience. They help to classify a support case, but are not a current repair approval:

• ManagementStatus.InvalidNamespace, 0x8004100E or 0x80041002 related to Win32_EncryptableVolume;
• 0x803100B6 on devices detected as slate;
• System.BadImageFormatException at Sophos.Encryption.BitLockerService.exe;
• BitLocker error after MBR to GPT or legacy BIOS to UEFI conversion;
• Activation error when bootable ISO or disk is mounted;
• No UI user session available;
• 0x80310048 or FVE_E_FIRMWARE_TYPE_NOT_SUPPORTED;
• older DMA/AllowedBuses error images;
• Need for advanced DEBUG or TRACE logging.

The Microsoft class Win32_EncryptableVolume explains the WMI context but does not authorize a MOF re-registration or a WMI repair. Likewise, no DLLs are copied from caches, registry permissions are adopted, BCD/recovery partitions are changed or undocumented logging keys are set. Sophos Support must provide up-to-date instructions for the installed version, exact build and full signature.

Diagnostic package and escalation point

Windows

• export or screenshot of the Central alert without secrets;
• Device, policy and user mapping with timestamps;
• sanitized output of manage-bde -status;
• relevant excerpt from CDE.log;
• matching Windows events and actual effective BitLocker GPOs;
• TPM, UEFI and firmware status as well as last real reboot;
• Endpoint Self Help or Sophos Diagnostic Utility (SDU), if available in the agent used;
• short list of state-preserving checks that have already been carried out.

macOS

• Device, policy and user mapping with timestamps;
• macOS and Sophos component version;
• sanitized output of seadmin status and seadmin --device-encryption;
• status of affected volumes in the Sophos Device Encryption app;
• information about whether the user has Secure Token/Volume Owner and pre-boot authorization;
• time of the last successful Central communication;
• SDU package and reproducible process without recovery key.

Before sharing, user data is reduced to what is necessary and recovery keys, passwords, full key IDs and other secrets are removed.

Sophos Support is escalated if responsibility or availability of the recovery key remains unclear, the central and operating system report contradictory states after successful synchronization, the agent service fails repeatedly, there is a historical signature or the next step would change WMI, registry, program files, BCD or partitions. The case mentions the first observed deviation, not just the last subsequent error.

Frequently asked questions