Retire Sophos Mobile containers: hand over data and devices safely

In brief: Do not deploy the unsupported Sophos Container with Sophos Secure Email and Sophos Secure Workspace on new devices. A Samsung Knox Container policy is a separate management path: the end of Sophos Container does not mean Samsung Knox Workspace has ended across the board. For existing devices, first identify the container type, management mode, and business data. Neither a new enrollment nor removal of the old device automatically transfers container data.

Which container is affected?

Sophos Container: Sophos Container with Secure Email and Secure Workspace has reached end of support. Sophos identifies Android Enterprise work profiles and Apple User Enrollment as future management approaches for the respective Android and Apple scenarios. These are target management models, not a promise that files, messages, accounts, or app settings will be transferred.

On May 6, 2024, the Sophos Secure Workspace apps for Android and iOS stopped being able to download work documents from Sophos Mobile. On October 7, 2024, Sophos announced it was removing the ability to create new Android/iOS container policies and to add or update work documents. On October 21, 2024, Sophos said it was starting to delete Secure Workspace work documents previously uploaded to Sophos Mobile. This does not prove that every copy was deleted or establish a supported way to recover documents now; a file-list entry is not proof that its contents remain retrievable from the service.

Samsung Knox Container: Sophos pages that can still be found for Knox container policies describe Samsung Knox containers: password requirements, restrictions, and an email account. They do not establish current support for a new Knox deployment on a particular device.

Samsung distinguishes obsolete CL/COM containers, Knox Workspace as a managed container, and Android Enterprise work profiles. Even though Samsung continues to describe Knox Workspace as a managed container on eligible devices, this guarantees neither support by Sophos Mobile in your own tenant nor the availability of new Knox features.

Android Device administrator is a legacy mode in Sophos Mobile, available only for Android 9 or earlier. None of these statements establishes a general Knox shutdown date.

Inventory without making changes

Create a working inventory for each device, including the responsible people and approval status:

1. Record the device, ownership (company-owned or personal), model, Android/iOS version, user, and business unit. Compare the actual container type and management mode on the device with those in the tenant. On the Sophos Show device page, Status, Policies, Device properties, Installed apps, and, for Samsung devices, Knox apps and Knox system apps can provide clues; a visible app entry is not a data backup.
2. Review assigned Knox policies for Password, Restrictions, and Email account without changing them. Record which business accounts, files, attachments, and apps are in the container and who owns the data. A documented Exchange account entry proves neither that sign-in currently works nor that email can be exported locally.
3. Ask the data owner whether the content resides in the original service or only locally in the container, whether an authorized backup already exists, and whether access works today. For Knox, check the device-specific license and its expiration: an expired Workspace license can block access, particularly on older Android versions, without necessarily deleting the data. This does not imply a universal recovery method.

Stop if data cannot be accessed: Do not guess passwords or reset a container. A Knox password policy may wipe the container after too many failed attempts. The old ResetContainerPassword self-service path now contains only a notice that Sophos Container support has ended and a referral to IT, not reset or recovery instructions.

Approve the data handoff before unenrollment

Before making a change, IT, the user, and the data owner must determine an authorized, application-specific export method or server-side way to regain access, and the new destination, for each affected type of data, taking account of device ownership and data-protection requirements.

A list of filenames or installed apps is not enough: for a small pilot group, open the approved documents and required messages at the destination using the intended identity, and check access permissions. Claim that data can be restored from backup only when an approved backup-and-restore method actually exists and has been demonstrated. Reopening a document on the server is not a restoration of locally deleted container data.

Backup gate: For every device, required data type and intended identity, verify either independent authorized access at the approved new destination or a backup that was actually restored to an independent, approved target in the pilot. Check the restored contents and permissions with the data owner; document and obtain their explicit sign-off on any excluded local-only content. Restoring only onto the old device does not clear that device for reset, unenrollment or deletion. If any required item is unaccounted for, stop and keep the old device unchanged.

If access fails, or if a required restoration cannot be demonstrated, do not unenroll or delete anything; escalate the case to the appropriate Sophos/Samsung contacts and the data owner, providing the device type, mode, license status, and symptoms. The fallback may be to leave the old device unchanged; technical recovery must not be assumed. No general present-day download method or recovery of deleted service documents has been established for Secure Workspace.

The Knox Allow data export option permits personal apps to access container data; it is neither a ready-made backup feature nor blanket approval to move business data into personal apps. Allow all certificates in the historical Knox email profile is likewise not an acceptable workaround for sign-in or certificate problems. Do not enable either as a precaution.

Approval and pilot

Only after the pilot data is readable at the new destination and an approach for failed transfers has been agreed should you plan the appropriate management method for each device. A successful pilot does not prove that data stored only locally is accessible on every other device. For each affected device and each type of data, check its own approved access method and data-owner approval before unenrollment, deletion, policy or app removal, or a wipe.

Management path by ownership

Before either route, obtain the per-device data access and data-owner approvals above. For a legacy Device administrator enrollment, Unenroll disables the Sophos Mobile Control device administrator, removes server login credentials and other data received from the server, and resets Sophos Intercept X for Mobile; Delete then removes the device record and its data stored by Sophos Mobile. Unenroll before Delete: deleting an enrolled device first can make it unusable. This sequence does not transfer local Knox or Sophos Container content. Do not apply it to an existing Android Enterprise work profile: removing that profile deletes all apps and data inside it. Unenrolling an Android Enterprise fully managed device requires a factory reset. Verify the actual mode and authorize potential data loss before any of these actions.

Destructive-action preflight (before choosing Wipe or Delete): On an Android Enterprise fully managed device, Delete itself triggers a factory reset; Unenroll-before-Delete is not a way around that reset. For that exact device, confirm the authorized reset/re-enrollment owner, device identity, approved data disposition and Factory Reset Protection (FRP): validate the configured Google account identifiers and that the responsible custodian can actually use/recover the account credentials after reset. Invalid FRP accounts or unknown credentials can leave the device unusable. If any custody or account check is unresolved, stop and escalate without Wipe, Unenroll or Delete. A work-profile removal instead deletes the apps and data in that profile; the legacy Device administrator sequence below applies only after verifying that legacy mode.

For company-owned Android devices already enrolled in Sophos Mobile in Device administrator mode, the Sophos-documented transition to Android Enterprise fully managed mode requires a factory reset first (Show device in the admin console: Actions > Wipe), followed by reenrollment. Before the wipe, set up Android Enterprise, verify the device identity and potential data loss, and establish data access and data-owner approval for each device; without this evidence, do not wipe. For personal Android devices, the different documented sequence applies only to existing enrollment in Device administrator mode: after setting up Android Enterprise, go to Show device in the admin console and select Actions > Unenroll first, then Actions > Delete, then reenroll with an Android Enterprise work profile. This is not an SSP action for removing an existing work profile. Both are management paths, not migrations of local Knox or Sophos Container content.

Unenroll, Delete, policy removal, app removal, and Wipe have different effects; a wipe in particular can irretrievably remove data. Do not treat successful completion of a console task alone as a complete data handoff.

Final checks and stop condition

After the controlled transition on pilot devices, separately check sign-in, the work profile or User Enrollment, managed apps, and access to the approved business data.

Stop for each device: Before any change, both the required approval and either confirmed, authorized access to the approved business data at the new destination or, where applicable, a demonstrated restoration from backup are necessary. If access is missing and no applicable restoration has been demonstrated, leave the old device untouched and escalate the case. Leave it untouched if approval is missing, too. Neither the pilot nor unenrollment proves that deleted local data can be recovered.

A backup restored only on the old device never satisfies this stop condition. For every needed data type and identity, require an independently accessible approved destination or a validated backup restored on a separate approved target during the pilot, plus data-owner sign-off for any excluded local-only data. No demonstrated independent access, applicable FRP custody or approval means no destructive action.