Skip to content
Avanet

Lost device in Sophos Mobile: lock it, remove work data, or reset it?

Sophos Mobile

Do not rush to click “Wipe” or “Delete.” Depending on the interface and management mode, “Wipe” can reset the entire device or remove only an Android work profile. For “Delete” of a still-managed, fully managed Android Enterprise device, Sophos documents an automatic factory reset, not just inventory cleanup. Device-side unenrollment occurs only at the next synchronization; neither unenrollment nor a reset is therefore confirmed on an offline device. A pending task is not proof that data on a lost device has been erased.

This decision aid explains what to check before authorizing a device action. It does not replace an incident procedure tested on the specific device. Route every missing-device report through the internal security process for incident triage, even if theft is not suspected. Assess escalation and measures for identity, session, and application access under your incident policy, independently of the device’s status. Request personal location data only with appropriate authorization and in accordance with your privacy policy.

Before taking any device action

  1. Identify the specific device in the correct tenant using a stable device identifier and assigned user. In Sophos Fusion > My Environment > Mobile Devices, click the device name. On the Summary tab, check Owner and Management mode under Device summary, and Management status under Device health. This field shows whether Sophos Mobile manages the device; for an unmanaged device, it also shows why the device is not managed. Check the displayed reason rather than inferring from the status alone that unenrollment or erasure has already occurred. Also check the platform and last synchronization, and inspect the device view in Sophos Mobile. “Personal” does not necessarily mean an Android work profile, and “Corporate” does not necessarily mean full management.

  2. Record who is responsible, the loss report, and authorization for the action. Check whether the device is company-owned or personal, whether Sophos actually manages it through MDM or only has a security app installed, and whether the user may already have recovered it. Do not initiate a destructive action if the management mode is unclear.

  3. Before irreversible steps, establish the backup status, which work data is needed, and the specific recovery path:

    • Android, fully managed: Check the intended reset path, configured internal Google IDs, valid, known credentials for the authorized FRP accounts, and effective FRP state. The specific checks are in “Mobile Admin: reset the device only with separate authorization”. Do not equate the FRP choice offered by Wipe in Sophos Mobile Admin with “Delete” or a Wipe in the Fusion view.
    • Apple devices: Verify supervision, current enrollment status, and an authorized Activation Lock recovery path that is actually usable before resetting. Sophos Mobile requires existing enrollment for “Remove Activation Lock”. This path is not supported on devices with at least two SIM/eSIM slots. Apple Business requires the device to have been added to the organization before the lock was enabled and not released from it. A bypass code requires the setting to have been enabled beforehand and a subsequent device synchronization. The Apple article explains Activation Lock settings, code verification, and authorized reactivation paths.
    • Mac: Securely retain the required unlock PIN.

    Keep credentials and codes only in the designated secure process, not in this article or an incident log. If suitable recovery means or authorizations cannot be demonstrated, stop and escalate. Reactivation is not guaranteed.

  4. Document the time, selected action, and expected scope of data affected. A recent or old “Last active” value shows only a synchronization, not execution of a newly sent task.

The available management modes depend on the device type; the mode is set during enrollment. Under Summary > Device summary, Last Sophos Mobile Control sync and Last Intercept X for Mobile sync show the last synchronization of each app. The Control field is available only when Sophos Mobile manages the Control app. The Intercept X field shows Never if Sophos Mobile does not manage that app. Open in Sophos Mobile opens Show device, with further information and actions, switching you to Mobile Admin. Do not apply its dialogs and field names to Fusion or the SSP.

Apple Business: review release from the organization separately

Stop before “Release from Organization” in Apple Business. A missing device is an incident, not grounds for automatically releasing it from the organization. This separate Apple Business action cannot be undone. It is neither Sophos Unenroll/Delete, removal of Activation Lock, nor an Erase/Wipe. It does not erase the device or turn off the lock by itself.

Review the prerequisites only outside the lost-device response:

  • Clarify ownership and the offboarding decision.
  • Check separate release authorization or the release permission of a linked device management service.
  • Establish the lock status and type: whether it is user-linked or organization-linked.
  • Verify an authorized path to reactivate or remove the lock that is actually available for this device.

Apple Business can remove either type of lock on an eligible organizational device with the appropriate authorization. The Apple Business action matrix rules out only direct removal of a user-linked lock by an external device management service.

Distinct from that is the path using a bypass code previously retrieved from the supervised device and securely stored. According to Apple’s deployment guide, a suitably capable device management service can use it to remove a user-linked lock remotely. The code can also be entered directly on the device.

This does not establish a remote code action in Sophos Mobile. Sophos separately documents the Actions > Remove Activation Lock task for eligible devices that remain enrolled and entering the code on the device. Before release or reset, verify the path actually available, secure custody of the code, and, where applicable, completion of the Sophos task or Apple Business activity for this device. If the status or recovery path is unclear, do not release the device; escalate.

After release, Apple Business can no longer manage its Activation Lock or assign the device to a device management service. The device may later be added again, but that does not undo release. The erase/restore step Apple calls for afterward is a separate destructive action requiring its own authorization, not proof that erasure has already occurred.

Which action fits the management mode?

Android Enterprise, fully managed

Consider a device lock if it is available in the specific tenant. Clarify recovery and FRP.

Unenroll requires a factory reset. For Delete of a still-managed device, Sophos also documents an automatic factory reset. The next-synchronization and offline-execution limits described below apply; deleting the record does not confirm a reset on the device. Do not treat this as harmless inventory cleanup.

Android Enterprise, work profile only

Distinguish Lock from Set container access > Deny. Lock locks the whole device; Set container access > Deny locks only the work profile. Apps in the locked work profile are unavailable, and their notifications are not displayed.

For an authorized work-profile lock in Sophos Mobile Admin, use the following procedure. It does not apply to fully managed Android Enterprise devices:

  1. Open Devices, click the blue triangle next to the unambiguously identified device, and select Show.
  2. Open Actions > Set container access and select the access rights:
    • Deny: Locks the work profile; its apps and data are no longer accessible.
    • Allow: Unlocks the work profile. After recovering the device, use this only with authorization.
    • Auto mode: A violated compliance rule with the Lock container action locks the work profile. This is the default behavior when no access rights have been set; it is not an unconditional unlock.
  3. Confirm with Yes. The setting takes effect at the subsequent synchronization, not when you click. Check synchronization and the actual profile state; escalate if the action is not executed.

Record the previous access rights so you can select them again in the same dialog after authorization. Allow explicitly unlocks the profile; Auto mode returns the decision to the compliance rules. The compliance actions therefore remain relevant. Users can also lock their work profile locally through Quick Settings. This is a device feature, not an administrator or SSP workflow.

Wipe Android work profile in Sophos Mobile Admin or Actions > Wipe in the Fusion device view removes the work profile, including work apps and data. It does not remove personal apps or data. Full remote device erasure in Sophos Mobile Admin is unavailable for this mode.

iPhone/iPad, supervised

Consider a lock. With appropriate authorization, Managed Lost Mode with contact information and a verified path to turn it off may be an option. Perform a full reset only after checking backups and Activation Lock.

Managed Lost Mode cannot be turned off through iCloud. After a restart without connectivity, the separate Turn off Managed Lost Mode command to end the mode may fail. That is not a command to turn off the device.

iPhone/iPad, Apple User Enrollment

Involve the user and responsible administrators. Assess only actions that are actually available and authorized.

Sophos Mobile cannot perform a full remote wipe in this mode. Unenrollment may remove managed apps, policies, and MDM certificates, but must not be presented as recovery of personal data. Do not assume supervised Managed Lost Mode or an Activation Lock bypass is available.

Mac

Trigger an available lock only with a documented six-digit unlock PIN. According to Sophos Mobile, a Mac already locked remotely cannot be wiped remotely. Plan for an unlock PIN when wiping as well.

Windows / Chromebook

Coordinate a platform-specific security response outside the Mobile lock action. Sophos Mobile cannot remotely Lock Windows computers or Chrome devices in Mobile Admin either; the action is also unavailable in the Fusion Mobile view.

On Windows, deleting the Mobile record does not automatically unenroll the device. Manual unenrollment is required, or a separately authorized factory reset if Forbid manual MDM unenrollment is enabled in the device policy.

Check Self Service permissions before an incident

The availability of an action in the Sophos Central Self Service Portal does not replace administrator authorization: depending on assigned permissions, users may be able to lock, locate, remove the work profile, or reset the device themselves. Before an incident, check the Self Service permissions actually assigned and app unenrollment settings: hiding Unenroll in Sophos Mobile Control does not by itself prevent unenrollment in the Self Service Portal; the app setting takes effect only after synchronization. The SSP “Reset device” loses all device data and cannot be undone. Work-profile removal is also irreversible, but affects only the work profile.

For the following SSP branches, the user’s effective Self Service configuration matters, not just access to the portal. Administrators must check the assigned user groups and authorized Actions under Setup > Self Service Portal. If several configurations match, the one with the highest priority applies. In particular, Managed Lost Mode, Play Lost Mode sound, Locate device, and Delete unmanaged device are separate permissions; do not assume any of them is granted. If a required action is unavailable, escalate to the responsible administrators rather than switching to Wipe or another interface.

Hide and restore app unenrollment

Sophos Mobile Control offers Unenroll by default on Android devices, iPhones, and iPads. The following setting controls this app workflow, not every unenrollment path. Before changing it in the correct tenant, record the previous value, affected Control-managed devices, and change approval; do not treat the setting as a single-device action.

  1. In Sophos Mobile Admin > Setup > General, open the SMC app tab.
  2. Select Disable unenrollment through app to hide Unenroll in the app. Clear the checkbox to show it again.
  3. Select Save. Both changes take effect on the device only at its next synchronization with Sophos Mobile.

After an approved change, separately verify a synchronization after Save and inspect the app menu on a device you are authorized to access: with the checkbox selected, Unenroll should be absent; after clearing it, the option should reappear where the device type supports it. Do not trigger Unenroll as a test. For a device that remains missing or offline, do not claim that the option has actually been hidden. If the result differs from expectations, check the saved value and last Control synchronization, then escalate.

To reverse the approved setting change, restore the previously recorded value on the same tab, select Save, and check the menu again after the next synchronization. Showing the option again does not undo unenrollment or data loss that has already occurred.

Disable SSP unenrollment separately

To block the SSP path as well, under Setup > Self Service Portal, edit the configuration effective for the affected users and clear Unenroll device under Actions > Show; select Save on Edit Self Service Portal configuration. First record the previous settings and affected users, and obtain change approval. Check overlapping groups and priority: if no other configuration matches, the always-present Default configuration applies with the lowest priority. Do not change Default without assessing the consequences for other users.

Then use fresh SSP sessions to check that Unenroll is not offered for the affected group assignments and, where affected, Default; do not trigger a device action as a countercheck. If the action remains visible, clarify the effective group assignment and priority, then escalate. The SSP administrator workflow covers full configuration setup, pilot checks before rollout, and restoration of the previous action selection. Disabling Unenroll device does not automatically block other separately authorized removal actions such as Wipe Android work profile or Wipe; their permissions and consequences still require separate review.

Locate and lock before erasing

Find/Locate shows only the last known location, not a travel history. For this location feature, Sophos Mobile stores only the last known location, not a location history over time. This says nothing about the retention of location events, reports, or data previously uploaded to the Data Lake. Location events are logged; Sophos requires a reason in the dialog for administrator location requests. This feature is unavailable in Sophos Mobile for Apple User Enrollment and Macs. According to Sophos, ordinary SSP Locate on an iPhone/iPad requires messages to be confirmed on the device before the location is displayed. This limits the usefulness of this branch for a missing device. Do not treat an old location as the current position or proof of ownership.

Prerequisites for an authorized location request

Privacy restrictions on administrator and SSP location requests are separate from the respective action permissions. Check the privacy settings and their limits before making a request: blocking map-based location does not hide the last location in the Device location report and proves neither that collection has stopped nor that stored data has been deleted.

  • Android: Sophos Mobile Control must be running, location services must be enabled, and the app must have Location permission.
  • iPhone/iPad: The same three prerequisites apply to ordinary location requests. They are not required for a supervised MDM device already in Managed Lost Mode. This extends neither platform support nor authorization; delivery and a verified return path are still required.
  • Chromebook: The Sophos Chrome Security extension must be active and location access allowed. Without a signed-in user, the location task remains Notified until a user signs in.

The compliance rules for location readiness distinguish Locate permission required for Android from App is able to locate for iPhone/iPad. They support assessment, not authorization to locate a device. Do not change policies or trigger Check now as a readiness test for a lost device: it can execute actions on other devices.

Sophos documents two settings paths for Chromebooks. Before making a change, check the policy’s actual target scope and organizational privacy and change approval; do not enable location across the fleet indiscriminately:

  • Chrome Enterprise: In the Google Admin console, under Devices > Chrome > Settings > User & browser settings > Geolocation, select Allow sites to detect users’ geolocation.
  • Other Chromebooks: On the device, under Settings > Privacy and security > Site settings > Location, select Sites can ask for your location.

Mobile Admin: locate a device already in Managed Lost Mode

For the exception on a supervised MDM iPhone/iPad, first check the IsMDMLostModeEnabled device property on the unambiguously identified device. The administrator branch under Show device > Actions > Locate applies only when Managed Lost Mode is confirmed to be already active. Distinguish it from ordinary Find/Show location and SSP Locate; SSP permissions and the SSP workflow must still be checked separately.

Privacy restrictions, action and incident authorization, delivery, and a verified path to turn the mode off remain required. If the active state is not confirmed, do not skip the ordinary location prerequisites; if the state is unclear or the action is missing, escalate to the responsible Mobile administrators. Do not turn on Managed Lost Mode as a readiness test. Here too, check the task status and, where possible, the actual device state; sending a request does not prove execution.

Fusion: request Find and display the location

After identifying the device, obtaining incident and privacy authorization, and meeting the location prerequisites above, proceed in Sophos Fusion:

  1. Open My Environment > Mobile Devices and click the name of the identified device.
  2. In the device details, select Actions > Find. If Find is unavailable, check platform support and Sophos Mobile Control’s location access; escalate if readiness is unclear.
  3. Enter the reason for the request and confirm with OK. Sophos Mobile sends a location task. If the device is offline, it remains Notified until the device synchronizes; for Chromebooks, the user sign-in requirement above also applies.
  4. Check the task status through Open in Sophos Mobile > Tasks. After completion, return to the Fusion device details and select Show location at the top right. The map opens in Google Maps.

Summary > Device information > Last known location shows the coordinates and date of the last Find action. A new authorized Find request updates the location. Determining the most accurate position can take up to 10 minutes. If no location is available after that, the device may be offline or powered off. This is not a definitive finding or a fixed task timeout. Do not trigger another device action as a connectivity test.

Mobile Admin: request ordinary Find and display the location

This ordinary location workflow applies to Sophos Mobile Admin, not the Managed Lost Mode branch described above, the Fusion inventory view or SSP Locate. Proceed only after identifying the device, obtaining incident authorization, and checking privacy requirements:

  1. Under Devices, select the unambiguously identified device and open Actions > Find.
  2. Enter the reason for the request and confirm with Yes. This creates a location task and sends it to the device. It does not yet confirm execution.
  3. Check the specific task status. If the device is offline, the task remains Notified until it reconnects to the server; on Chromebooks, the user sign-in requirement above also applies.
  4. Only after the task completes, select Actions > Find > Show location. The location is displayed in Google Maps; even then, it is a last known position, not proof of the device’s current whereabouts.

If Find is unavailable, check platform support and the prerequisites above, especially Sophos Mobile Control’s location access on Android and iPhone/iPad. Do not bypass missing readiness with Wipe, password reset, or another device action; escalate to the responsible administrators.

For multiple devices, select the approved targets under Devices and use Actions > Find; alternatively, use the Device location report. Both remain limited to the approved device and privacy scope. The report is not a way to bypass missing authorization to locate devices.

SSP: ordinary Locate and map display

This workflow differs from Locate with Lost Mode already active and from Mobile Admin > Find. Proceed only after identifying the device, obtaining incident and privacy authorization, and checking effective SSP permissions and the ordinary location prerequisites above:

  1. Sign in to the Sophos Central Self Service Portal.
  2. Open Mobile and select the unambiguously identified device.
  3. Select Actions > Locate. Sophos creates a task and sends it to the device. Sending it does not confirm execution.
  4. In the device details, click View Details next to Location. According to the SSP help, the location appears in Google Maps. An old position is not proof of the device’s current whereabouts.

On iPhones/iPads, this ordinary SSP Locate requires messages to be confirmed on the device before the location is displayed. Do not assume this confirmation is possible on a device that remains missing. This prerequisite applies here to ordinary location requests; it does not describe the separate Lost Mode location workflow. Location requests are logged; this does not replace privacy authorization. If the action or location display is missing, or the state is unclear, escalate to the responsible administrators rather than using other device actions as a workaround.

Distinguish locking from risky device actions

Lock locks the device but does not erase data. On an Android device with a managed work profile, Lock locks the entire device; only Set container access > Deny locks the work profile. For Mac locks, document the PIN and authorized unlock path before triggering the action. Supervised iPhones/iPads can use Managed Lost Mode instead; loss of connectivity after a restart can prevent it from being turned off. Do not restart or power off a device in this state as a test. If Turn off Managed Lost Mode, the command to end that mode, cannot be delivered or executed, escalate to the Mobile/Apple administrators and, if the device is physically accessible, first assess the documented wired-network connection path. This is not a command to turn off the device. Erasing or restoring through Apple Configurator or recovery mode requires separate authorization: it erases content and ends supervision.

Fusion: lock a device with Lock

After completing the checks under “Before taking any device action”, proceed in Sophos Fusion. Lock is unavailable for Windows and Chromebooks; with Android work-profile management, it locks the whole device.

  1. Open My Environment > Mobile Devices and click the name of the identified device.
  2. In the device details, select Actions > Lock.
  3. Fill in the fields appropriate to the device type:
    • Lock screen message for Android, iPhone, and iPad. Use only approved return information.
    • Phone number for iPhone and iPad. The number appears on the lock screen; do not assume a calling function or an SSP character limit.
    • Unlock PIN for Mac. Set a six-digit PIN and store it securely. Locking restarts the Mac, and this PIN is required to unlock it.

Sophos does not specify an additional confirmation button for this Fusion Lock workflow. Check the task status and actual lock state separately. Android devices, iPhones, and iPads are unlocked with the existing device password, configured PIN, or pattern; failed-attempt limits still apply.

After locking a Mac, search for device.unlock.code on the Properties tab in the Fusion device details. Sophos Mobile stores the PIN there. Share it with an authorized person only through the designated secure channel. The Mobile Admin field names below provide a different retrieval path.

Mobile Admin: lock a device with Lock

Ordinary device locking is a separate workflow, not Managed Lost Mode or an SSP action. Complete the checks under “Before taking any device action” before proceeding in Sophos Mobile Admin:

  1. Open Devices, click the down arrow next to the unambiguously identified device, and select Show.
  2. On Show device, open Actions > Lock.
  3. Set the fields for the device type:
    • Lock screen message: A message on the lock screen of Android devices, iPhones, and iPads. Include only necessary return information, not confidential incident details.
    • Phone number: A phone number on the lock screen of iPhones and iPads. Use an approved contact point; do not equate this field with the callable number in Managed Lost Mode.
    • Lock PIN: For Macs, set a six-digit PIN for later unlocking and store it securely. Locking restarts the Mac; establish authorized access at the device before triggering it.

Check the task status and, where possible, the actual lock state. After recovery, the authorized user unlocks an Android device, iPhone, or iPad with the existing device password, configured PIN, or pattern. Do not keep guessing; the failed-attempt limits described below also apply when unlocking. Password reset is not part of Lock.

On a Mac, the PIN set by the administrator is required. For Lock, find it on the device page under Device properties > Unlock passcode and on Task details under Lock PIN. Share it with the authorized person only through the designated secure channel, not in the incident log. The restriction on wiping a Mac already locked remotely, mentioned above, still applies.

SSP: lock a device with Lock

This workflow applies to Lock in the SSP, not Mobile Admin or Lost Mode. First complete the checks under “Before taking any device action” and establish effective SSP permissions and the authorized unlock path. Sophos restricts this feature to certain device types without listing them on this SSP page. An available administrator menu therefore does not establish SSP availability.

  1. Sign in to the Sophos Central Self Service Portal.
  2. Open Mobile and select the unambiguously identified device.
  3. Select Actions > Lock.
  4. For iPhones/iPads, you can enter a message of no more than 300 characters that appears on the device after it is locked. You can enter an approved contact number in Phone number to display. According to the SSP help, tapping this number in the lock message automatically dials it. Do not include confidential incident details.
  5. For Macs, set a six-digit PIN and store it using the designated secure procedure. It must be entered on the Mac to unlock it. The administrator field names and PIN retrieval paths above are not SSP instructions.

According to the SSP help, the action locks the device with the existing device password, or the system lock PIN on a Mac. It does not reset the password. After recovery, unlock only with authorization, observe failed-attempt limits, and do not guess if access is unclear. Check delivery and the actual lock state separately; a portal action is not proof that an offline device has been locked.

Mobile Admin: turn on and verify Managed Lost Mode

This workflow applies only to supervised MDM iPhones/iPads, not Apple User Enrollment or a security app alone. Before enabling it, check incident authorization, the device identifier, privacy, and the path to turn it off. The restart/offline warning already applies to this decision: a visible action menu does not guarantee that the mode can later be turned off.

  1. Open Devices, click the blue triangle next to the unambiguously identified device, and select Show.
  2. On Show device, select Actions > Turn on Managed Lost Mode.
  3. Set Lock screen message, Phone number, and Footer. The message appears on the lock screen; the phone number can be called from there. Footer appears at the bottom of the screen. Without a footer, a default message tells the user to contact the administrators. Enter only approved return and contact information.

Sophos Mobile creates a task and sends it to the device. The device activates the mode only when it receives the task. Check the task status and the IsMDMLostModeEnabled device property; if the device is physically accessible, also check its actual state. A sent task or an old synchronization does not prove that the mode is currently active.

Normal use is blocked until the mode is disabled in Sophos Mobile. The device allows only a call to the configured number or an emergency call. With the mode confirmed active, Show device offers the separate actions Actions > Locate, Actions > Play Lost Mode sound, and Actions > Turn off Managed Lost Mode. For location requests, continue to follow the authorization requirements and administrator Locate branch described earlier. Location comes from a system function; Sophos Mobile Control does not need to be running. This makes locating more reliable than under an ordinary lock, but guarantees neither a current position nor device connectivity.

After recovery and authorization, end the mode with Actions > Turn off Managed Lost Mode. Check the task status, IsMDMLostModeEnabled, and device state again before authorizing a return to service. This is neither Shut down nor SSP Turn off Lost Mode; iCloud cannot end this mode either.

If Managed Lost Mode cannot be turned off

First check the task status, last connection, and known device history. Possible causes include:

  • A restart while in the mode, including after shutdown or a drained battery. Network connectivity may then be lost. In this mode, the SIM cannot be unlocked for cellular access, nor can the user sign in to an Apple Account if that is required for the Wi-Fi connection concerned.
  • Another loss of connectivity after which the device cannot reconnect.
  • Outdated iOS as another possible cause. This does not authorize an update or restart test while the device is locked.

For a recovered device with authorized physical access that cannot reach either Wi-Fi or cellular service, first assess the network path that does not erase data:

  1. If it has a suitable Lightning connector, try an Ethernet connection using a Lightning-to-Ethernet adapter or a combination of Lightning-to-USB and USB-to-Ethernet adapters. These examples do not establish compatibility with every device or USB-C adapter.
  2. Once the Ethernet connection is established, use Actions > Turn off Managed Lost Mode in Sophos Mobile Admin > Show device.
  3. Check task completion, IsMDMLostModeEnabled, and the actual state on the device. If connectivity or deactivation still fails, escalate to the Mobile/Apple administrators. Do not promise recovery or use password reset, restart, or shutdown as a test.

Erasing or restoring is not an equivalent way back: both remove content and settings and end supervision. Restoring also resets the operating system and firmware; it does not recover erased user data. Before considering such an alternative, check ownership, backups, Activation Lock, and reenrollment, and obtain separate authorization to erase data.

The Configurator path requires a Mac with Apple Configurator 2. If Allow host pairing is disabled in Restrictions in the iOS device policy, the Mac must already be configured as a suitable supervision host; do not assume a new certificate or policy can be sent to an unreachable device. Proceed only with these prerequisites and authorizations:

  1. Connect the recovered device to the Mac by USB, open Apple Configurator 2, and select only this device in the device window.
  2. For the authorized content erasure, select Actions > Advanced > Erase All Content and Settings. For a separately authorized restore, select Actions > Restore instead and confirm with Restore. Do not perform both actions in succession.
  3. Check the device state, and separately verify reactivation, the required backup, supervision, reenrollment, and protection status. Without a demonstrably suitable reactivation path, stop and escalate; a return to the originally shipped operating-system version is not promised.

Restore a recovered iPhone or iPad in recovery mode

This local procedure is a separate destructive alternative, not a remote action or a connectivity test. Restore erases content and settings, ends existing supervision, and reinstalls iOS or iPadOS. It does not recover erased user data; a return to the originally shipped operating-system version is not promised.

Before connecting the device, Apple administrators must confirm the device identifier, specific model, ownership, and authorized physical access, and document separate authorization to erase data. Check the existing backup, its date, and the data needed; for an encrypted computer backup, the backup password must be securely available. Do not assume a new backup can be made from the locked device. Verify an authorized Activation Lock path that is actually usable and the plan for reactivation, supervision, and reenrollment before erasing. Restoring does not bypass Activation Lock. Without suitable means or authorization, stop and escalate; a lost-device incident does not authorize erasure.

  1. Prepare the computer: Use a suitable Mac with macOS 11 or later, installed updates, and Finder. Alternatively, use an updated Windows computer that supports the current Apple Devices app; install or update it through the Microsoft Store. For a suitable Windows computer without Apple Devices, the current version of iTunes is the documented alternative. Check compatibility between the computer, app, and specific device model beforehand; an older host or an existing iTunes installation alone is not sufficient. Plan for internet access for the software download and subsequent activation.

  2. Connect by USB: Open Finder, Apple Devices, or the authorized iTunes alternative, and connect only the identified device using a suitable USB data cable. Keep it connected throughout the following steps. If the Mac requests permission to connect an accessory, approve only this authorized device.

  3. Use the sequence for the specific model:

    • iPhone 8 or later, including iPhone SE (2nd generation or later): Quickly press and release the volume up button, then quickly press and release the volume down button; then hold the side button until the recovery-mode screen appears.
    • iPhone 7 or 7 Plus: Hold the side button and volume down button simultaneously until the recovery-mode screen appears.
    • iPhone 6s or earlier, including iPhone SE (1st generation): Hold the Home button and the top or side button simultaneously until the recovery-mode screen appears.
    • iPad without a Home button: Quickly press and release the volume button closest to the top button, then quickly press and release the volume button farthest from the top button; then hold the top button until the recovery-mode screen appears.
    • iPad with a Home button: Hold the Home button and top button simultaneously. When the iPad turns off, release the top button and keep holding the Home button until the recovery-mode screen appears.

    Expect the connect to a computer screen with a cable/computer icon, not just the Apple logo. If the model is unclear or the buttons are faulty, do not try other sequences; stop and escalate to the Apple administrators or a service provider.

  4. Restore on the computer: In Finder, select the device in the sidebar; in the normal device pane, Restore iPhone/iPad is under General. In Apple Devices, select the device in the sidebar, then General > Restore [device]. In the iTunes alternative, select the device icon at the top left, then Summary > Restore. If the recovery dialog offers Update or Restore, select Restore for the separately authorized erasure and confirm the restore. Update is not confirmed erasure; Apple’s general recommendation to try an update first for startup problems does not authorize an update test in Managed Lost Mode. Restore Backup is a separate step for an existing backup, not this device reset. Follow the instructions on the computer and device without guessing codes or credentials.

  5. Wait for the download and completion: If the download takes longer than 15 minutes and the device exits the recovery-mode screen, let the download finish first. Then, while the device remains connected, repeat the appropriate model sequence from step 3 and continue the restore on the computer. If errors occur, document the exact error and escalate; do not claim success or repeatedly reset the device without assessing the result.

  6. Check return to service separately: After Restore completes, check the welcome screen and actual device state. Activate through the authorized path verified beforehand, then set up the device again according to the recovery plan or restore a suitable backup separately. Next, check the required data, supervision, reenrollment, connection to Sophos Mobile, and policy and protection status. A welcome screen or completed computer dialog does not prove these points. If Activation Lock requests credentials that are unavailable, or enrollment is incomplete, stop; authorize normal use only after these checks.

Mobile Admin: reset the password only after recovering the device

Password reset and restart are not harmless tests. On an iPhone/iPad, a Sophos Mobile password reset removes the passcode and unlocks the device, weakening containment if it is still missing or stolen. Do not use password reset as a loss response or synchronization test; consider it only after recovery and separate incident authorization.

Administrator reset is available for Android Enterprise and iPhones and iPads without Apple User Enrollment. It is unavailable if only Sophos Intercept X for Mobile is registered for the device in Sophos Mobile. On Android Enterprise, the user must previously have confirmed the device password. If the user set it during initial setup before installing Sophos Mobile Control, the app prompts for confirmation at every synchronization. Until that confirmation is provided, remote password reset is not possible.

Before entering any password, check the effective password policy; do not keep guessing. A configured Maximum sign-in attempts limit can reset the entire device for an Android Enterprise device password, but erase the work profile for a work-profile password. In an Android Enterprise work-profile policy, the device-password setting is documented under Android 11 and earlier; do not assume it is available for Android 12 and later. An iOS device policy can use Number of failed attempts until device wipe to remove all data and settings after failed attempts.

Establish the authorized recovery path before entering a one-time password or a new password. If a password is rejected or the failed-attempt counter is unclear, make no further attempts; escalate to the responsible Mobile administrators. A password reset proves neither that this counter has been reset nor that the policy has been removed or data restored.

After recovery, device identification, and separate authorization in Sophos Mobile Admin:

  1. Open Devices in the sidebar and click the unambiguously identified device.
  2. On Show device, select Actions > Reset password.
  3. If the confirmation dialog displays a one-time password for unlocking the device, share it with the authorized user through the designated secure channel; do not store it in the incident log.
  4. On Android, the user must unlock the device with this one-time password and then set a new password. On iPhone/iPad, the passcode is instead removed and the device unlocked; check its protection status before returning it to service.

The SSP version of Android password reset has its own prerequisites and, with work-profile-only management, may change only the work-profile password. Do not apply the administrator workflow to the Self Service Portal or the Fusion device view.

SSP: reset the password only after recovering the device

The same rule applies in the SSP: Do not use password reset as a loss response or connectivity test. Proceed only after recovery and separate incident authorization. First check the device identifier, management mode, effective SSP permissions, password policy, and authorized recovery path. The failed-attempt risks described above still apply. This SSP page does not list all excluded device types; eligibility for administrator reset therefore does not establish SSP support.

For Android Enterprise with Android 8.x or later, the SSP help requires the password reset feature to have been enabled beforehand in Sophos Mobile Control. Password confirmation in the administrator workflow does not replace this prerequisite. Do not bypass missing preparation with an unverified device or policy change during the incident.

  1. Sign in to the Sophos Central Self Service Portal.
  2. Open Mobile and select the unambiguously identified device.
  3. Select Actions > Reset password.
  4. Confirm any informational messages displayed or follow the displayed instructions. The SSP help does not specify an additional button label for this step.

For Android, Sophos describes locking with the one-time password displayed in the SSP. After authorized unlocking, a new password must be set. Use the one-time password only through the designated secure channel; do not store it in the incident log. With work-profile-only management, Reset password affects only the work-profile password, not the personal device password.

On iPhone/iPad, password reset removes the passcode and unlocks the device. According to the SSP help, the security consequence described above also applies to SSP reset. Check protection status before returning the device to service. These consequences are vendor statements, not results tested here. Check delivery and the actual device state; stop and escalate if they differ from expectations.

Mobile Admin: restart only with a verified recovery path

Sophos Mobile can remotely restart Android Enterprise devices, but not if it manages only their work profile. For iPhones and iPads, remote restart is available only for supervised devices.

Do not use this as a synchronization test. Passcode-locked iPhones/iPads do not reconnect to Wi-Fi after a restart. User interaction may be needed before they can communicate with Sophos Mobile again. Before authorization, establish who can restore access on the device and check connectivity. If that recovery path is unavailable, stop and escalate to the Mobile/Apple administrators; a password reset is not a workaround for a device that is still missing. Do not restart a device in Managed Lost Mode as a test.

Proceed only after device identification, verification of the platform and management mode, and separate authorization in Sophos Mobile Admin:

  1. Open Devices in the sidebar.
  2. On Devices, click the arrow next to the unambiguously identified device and select Show.
  3. On Show device, select Actions > Restart.
  4. Confirm with Yes in the confirmation dialog.

Sophos Mobile sends the restart command to the device. The device restarts immediately without requiring confirmation from the user on the device; Yes is the administrator’s confirmation. Sending the command alone does not prove execution on an offline device. Check the task status and actual device state; after the restart, also check the connection to Sophos Mobile and, if connectivity is missing, use the authorized recovery path or escalate. This workflow does not apply to the SSP or the Fusion device view.

Mobile Admin: shut down a supervised iPhone or iPad

Sophos Mobile can remotely shut down supervised iPhones and iPads. Shut down neither ends Managed Lost Mode nor locks the device or erases data. Do not shut down a device in Managed Lost Mode as a test. Before a separately authorized shutdown, establish how the device can be turned back on and its connectivity checked; without a suitable recovery path, stop and escalate.

After device identification, confirmed supervision, and separate authorization in Sophos Mobile Admin:

  1. Open Devices in the sidebar.
  2. On Devices, click the arrow next to the unambiguously identified device and select Show.
  3. On Show device, select Actions > Shut down.
  4. Confirm with Yes in the confirmation dialog.

Sophos Mobile sends the shutdown command to the device. The device shuts down immediately without confirmation from the user on the device; Yes confirms the action on the administrator side. Here too, sending the command is not proof of execution on an offline device. Check the task status and, where possible, the state on the device. After the authorized power-on, check connectivity and protection status; escalate if the outcome is unclear. Do not equate this with Turn off Managed Lost Mode, SSP Turn off Lost Mode, or an action in the Fusion device view.

SSP: Lost Mode on an iPhone or iPad

This branch applies only to supervised iPhones/iPads managed through MDM, not to Apple User Enrollment, Android, Mac, or a security app alone. After incident authorization and verification of the path to turn the mode off, select the unambiguously identified device in Sophos Central Self Service Portal > Mobile and use Actions > Turn on Lost Mode. Set Lock screen message, Lock screen phone number, and Footer; without Footer, the default message tells the user to contact the administrators. In this mode, the device allows only a call to the configured number or an emergency call.

After checking the entries, confirm the action. The SSP help does not specify a button for this step. According to Sophos, the device enters Lost Mode immediately after confirmation. This describes the documented effect but is not evidence from testing here that an offline or unreachable device executes the action immediately. Check delivery and the actual device state; do not infer that the mode is active from confirmation in the portal.

With Lost Mode active and the appropriate permissions, Locate, Play Lost Mode sound, and Turn off Lost Mode are available in the SSP. A mode enabled in the SSP cannot be turned off in iCloud; conversely, the SSP cannot turn off Lost Mode enabled in iCloud. Distinguish the SSP action Turn off Lost Mode from the administrator command Turn off Managed Lost Mode and from powering off the device. The restart/offline risk described above still applies: do not restart as a test; check delivery and the actual device state, and escalate if the mode is not turned off. A confirmation in the portal does not guarantee successful recovery.

Remove data only after confirmed authorization

  • Selectively remove the work profile: Only for Android Enterprise work-profile management and after confirming that the work data there is no longer needed. The profile and its work apps and data disappear; personal data remains. This is not an assurance that corporate accounts, tokens, or copies stored elsewhere have been revoked.
  • Reset the entire device: Only for an eligible platform and management mode, with unambiguous authorization concerning ownership and data backups, and with an organizational reactivation path verified beforehand as applicable to that specific method. An invalid or unknown FRP account can render a fully managed Android device unusable after Wipe; the FRP choice belongs to Wipe in Sophos Mobile Admin and has not been established for “Delete.” For iPhone/iPad, establish the specific Activation Lock path and its prerequisites before resetting; without the previous Apple account, Sophos describes reactivation only for supervised devices subject to additional conditions. Do not describe User Enrollment or an Android work profile as permitting a full wipe. Do not promise a return to service without controlled verification.
  • Unenroll, then delete the record: This is not a substitute for a confirmed wipe. Before authorization, check the consequences for the specific management mode:
    • Android Enterprise, fully managed: Unenrollment entails a factory reset.
    • Existing Android management in Device administrator mode: Unenrollment disables the Sophos Mobile Control device administrator and removes the server login credentials and all other data received by Sophos Mobile Control. Sophos Intercept X for Mobile is reset. This is neither a full wipe nor revocation of cloud accounts or data migration; do not apply these effects to Android Enterprise.
    • iPhone/iPad: Unenrollment removes managed apps, policies, and certificates received through MDM. Sophos Intercept X for Mobile is reset; this is not a device passcode reset or an assurance that the app will be uninstalled.
    • Mac: Unenrollment removes all policies and certificates received through MDM, but does not factory-reset the Mac. This may disrupt managed network or application access. Before authorization, verify network and administrative access independent of these policies and certificates, along with a suitable recovery plan for credentials, certificates, and required data. If a suitable path cannot be demonstrated, stop and escalate. For a Mac that remains missing, continue to address access risks in the incident; do not claim device-side unenrollment without confirmed execution.

Mobile Admin: Unenrollment with Unenroll

This procedure applies to Sophos Mobile Admin, not Fusion or the SSP. It is documented for non-Android devices and Android devices in Device administrator mode. Fully managed Android Enterprise devices require a separately approved factory reset; for devices managed through a work profile only, work profile removal is the appropriate approach. An available Unenroll menu does not establish either that a device is under MDM management or that this action is suitable for every device.

Proceed only after completing the checks under “Before taking any device action”. For each target device, verify the device identifier, ownership, platform, management mode, permission to perform the admin action, incident and data approvals, and the appropriate recovery path. The platform-specific consequences described above still apply. If suitability is unclear or approval is missing, stop and escalate.

  1. In the sidebar of Sophos Mobile Admin, click Devices.
  2. Select only target devices that have been clearly identified and approved for unenrollment. If selecting multiple devices, check the prerequisites and consequences for each device.
  3. Select Actions > Unenroll.
  4. Check the target selection and approval again, then select Yes in the confirmation dialog.

Afterward, check the specific task status and last synchronization in Sophos Mobile for each target device. If the device is recovered and authorized access is available, also check its actual management status and device state. Yes confirms the admin action, not its successful execution on the device. If the device is offline, the task is pending, or the results are contradictory, do not claim that unenrollment or data deletion has occurred; continue tracking access and data risks in the incident and escalate. Remove the entry through the separate Delete procedure only after unenrollment has been confirmed. The unenrollment at the next synchronization described below concerns Delete of a device that is still enrolled, not a guaranteed execution timeframe for this Unenroll procedure.

Fusion: unenroll with Unenroll or Wipe

Unenrollment ends management; it is not harmless list cleanup. This workflow applies to the Fusion device details, not Mobile Admin or the SSP. Proceed only after the checks under “Before taking any device action”. Establish the device identifier, platform, Management mode, ownership, action permissions, incident and data authorizations, and an appropriate recovery path. If the mode is unclear or authorization is missing, stop and escalate.

  1. In Sophos Fusion > My Environment > Mobile Devices, click the name of the unambiguously identified device.
  2. Choose the route that matches its management mode:
    • Non-Android device or Android in Device administrator mode: Select Actions > Unenroll in the device details. Account for the platform-dependent consequences described above; in particular, removing policies and certificates from a Mac is not a factory reset.
    • Android Enterprise, fully managed: Use Actions > Wipe to unenroll. This resets the entire device to factory settings; it does not remove only work data. Separate authorization to erase data and the FRP and reactivation checks are required.
    • Android Enterprise, work profile only: Use Actions > Wipe to unenroll. This removes the work profile and all its apps and data, not personal apps and data. This removal cannot be undone either.
  3. For Wipe, also check the limits and device-specific inputs below before confirming. Select OK in the Fusion confirmation dialog only once authorization has been confirmed.

If the appropriate action is unavailable, do not use Delete instead. Clean up the entry through the separate Delete workflow only after confirmed unenrollment. A disappearing entry proves neither unenrollment nor a reset on the device.

Android work profile: local removal and a remaining account

If an Android Enterprise work-profile device can no longer connect to Sophos Mobile, for example after a trial expires, Sophos describes a local removal path through Android settings. For a physically accessible personal device with confirmed Owner: Personal and Android Enterprise Work profile, use the BYOD workflow for local work-profile removal and account checks. First clarify the device, required work data, and authorization to erase data with the user. This permanently deletes all apps and local data in the work profile; personal apps and data remain. It is not a remote measure for a device that remains missing, nor the Sophos Mobile Control Unenroll path described below. If ownership or mode is unclear, the removal option is missing or blocked, or the device is of another type, stop and escalate to IT. Do not bypass management restrictions or use a factory reset as a substitute.

Only for organizational registration in Managed Google Play Account mode: After unenrollment, a Google account may remain on the device. The device then continues to count toward the user’s limited enrollment quota. The account check in the linked BYOD workflow applies whether the profile was removed locally or through an approved remote action: an authorized specialist must identify the exact remaining account as the managed enrollment account and manually remove only that account if needed. Do not delete the user’s personal Google account. Check the actual profile and enrollment state; a disappearing console entry proves neither removal on the device nor an available enrollment slot. If the account cannot be identified unambiguously, stop and escalate.

Fusion: perform and verify Wipe by management mode

Actions > Wipe in the Fusion device details performs a factory reset on a supported device, but only removes the work profile with Android Enterprise work-profile management. Both erasures are irreversible. Apple User Enrollment devices and Macs already locked remotely are excluded from Wipe. A visible menu does not establish eligibility or authorization; a security app alone is not MDM management.

After identifying the device, checking permissions and data authorization, and verifying a reactivation path usable for this method, open the device name under Sophos Fusion > My Environment > Mobile Devices and select Actions > Wipe. Wipe is not a connectivity test. If FRP is to be enabled for the planned Wipe of a fully managed Android Enterprise device, explicitly use Open in Sophos Mobile > Show device > Actions > Wipe instead. The separate Mobile Admin workflow, with its FRP checks and confirmation, then applies, not the Fusion dialog. Do not assume Fusion offers an FRP selection.

For other supported device types, the Fusion Wipe workflow specifies its own inputs:

  • iPhone/iPad: Preserve data plan retains the mobile data plan, not device data. Forbid Quick Start skips the Quick Start step on the first startup after the reset. Set both according to the approved recovery plan.
  • Mac: Set a six-digit PIN under Unlock PIN and store it securely; it is required on the Mac after the reset. In Fusion, it can be retrieved under Properties > device.unlock.code.

Select OK in the Fusion confirmation dialog only after checking the inputs and authorization. Sophos Mobile sends a Wipe task; check its status through Open in Sophos Mobile > Tasks. This switch is for checking the task and does not make Mobile Admin field names or its Yes confirmation into Fusion steps.

These consequences are vendor statements, not tenant or device results tested here. Distinguish between sent, reported successful, and confirmed on the device. If the device is offline or the result is unclear, do not claim erasure; escalate and continue tracking data risk in the incident. After recovery, check the actual device or profile state; separately authorize reactivation, reenrollment, and verification of protection status. Subsequent enrollment does not restore the removed data.

Mobile Admin: remove an Android work profile when a device is lost

This remote workflow applies to Sophos Mobile Admin and may also be used for a device that is still missing, following explicit incident and deletion authorisation. For each target device in the correct tenant, check the device identifier, assigned user, actual ownership (Owner) and confirmed Management mode: Android Enterprise Work profile. Sophos Mobile must manage only the work profile; a personal device or a visible action menu alone does not establish this mode. Document administrative permission to perform the action, required work data and authorisation for irreversible removal for each target device. If ownership or mode is unclear, or authorisation is missing, stop and escalate. This is neither a connectivity test nor an automatic offboarding measure.

Once performed, removal cannot be undone: the work profile and all work apps and data within it are deleted. Personal apps and data are not removed; this is not a full factory reset. The local BYOD workflow described above remains exclusively for a physically accessible personal device with confirmed ownership and mode, not for a device that is still missing.

  1. Open Devices in the side menu of Sophos Mobile Admin.
  2. Select only the unambiguously identified Android Enterprise work-profile devices authorised for work-profile removal. For multiple targets, check ownership, mode and authorisations separately for each device.
  3. Select Actions > Wipe Android work profile.
  4. Recheck the target selection and scope of deletion, then select Yes in the confirmation dialogue.

Afterwards, check delivery, the specific task status and the last synchronisation in Sophos Mobile for each target device. Distinguish between sent/pending, reported successful and confirmed on the device: Yes or an old synchronisation does not prove that removal has been performed. Only if the device has been recovered and access to it is authorised should you also check the actual profile and registration state on the device. If the device is offline, the task is pending or the result is contradictory, do not claim removal; escalate and continue tracking the data risk. The product consequences described are vendor statements, not tenant or device results successfully tested here.

Secure account, session and application access independently in accordance with the incident policy: profile removal does not establish that corporate accounts, tokens or copies outside the profile have been revoked. The limitations of Managed Google Play Account described above still apply to any managed enrolment account that may remain, and account checks must wait until authorised access to the device is available; do not remove any personal Google account. Re-enrolment does not restore deleted work data. Fusion Wipe and the following SSP workflow remain separate alternatives with their own permissions and confirmations.

SSP: selectively remove an Android work profile

Use this only when Sophos Mobile manages only an Android work profile and you have checked the work-data and incident authorizations described above and effective SSP permissions. If unsure, ask the responsible IT team first. Removal cannot be undone. It is neither a full device wipe nor SSP Unenroll for devices without a work profile.

  1. Sign in to the Sophos Central Self Service Portal.
  2. Open Mobile and select the unambiguously identified device.
  3. Select Actions > Wipe Android work profile.

According to the SSP help, the work profile and all work apps and data, including Sophos Mobile Control, are removed. Personal apps and data are not removed. The device is then no longer registered with Sophos Mobile. These are documented consequences of an executed action, not proof of success from clicking in the portal. Check delivery and the actual state as described in “Verify the outcome and escalate”. This does not establish that other corporate accounts, tokens, or copies outside the profile have been revoked.

Mobile Admin: reset the device only with separate authorization

Wipe resets the device to factory settings. Once the wipe has been performed, it cannot be undone. This procedure applies to devices managed by Sophos Mobile and is performed in Sophos Mobile Admin, not in the SSP or in Fusion. Android Enterprise work profile devices, devices with Apple User Enrollment, and Macs that have already been remotely locked are excluded. Selectively removing a work profile is a different operation.

Proceed only after the device has been unambiguously identified, authorization concerning ownership and data backups has been obtained, and the reactivation path applicable to this reset method has been checked. The FRP, Activation Lock, and PIN checks mentioned above remain mandatory; a visible Wipe action does not replace them. If the management mode is unclear, credentials are missing, or authorization is missing, stop and escalate. Wipe is not a synchronization test.

For an authorized Wipe of a fully managed Android Enterprise device, also check the following before opening the action:

  • Match the internal Google IDs stored in the FRP configuration’s Google+ IDs field exactly against the securely retained, confirmed IDs of the authorized accounts. These are the 21-digit internal IDs, not email addresses. Known credentials alone do not establish a valid ID. The associated Google accounts must also be valid, and their credentials securely available for authorized reactivation. Invalid IDs or missing credentials can render the device unusable after a reset with FRP.
  • On the unambiguously identified device, check the FRP status under Show device > Status against the authorized reset and reactivation path. If the global FRP configuration has changed, it takes effect on the device only at its next synchronization. Before Wipe, therefore, establish that synchronization occurred after the change and verify the effective device-specific FRP state; a saved configuration value or an older synchronization is insufficient.
  • If IDs, credentials, or the effective state are unknown or unconfirmed, stop and escalate to the responsible Mobile administrators. For a lost or offline device, do not force synchronization, change or disable FRP, or make Google API calls as an incident test. This check is not an FRP reconfiguration procedure and does not extend any Wipe setting to Delete.
  1. Open Devices in the sidebar.
  2. On Devices, click the blue triangle next to the unambiguously identified device and select Show.
  3. On Show device, select Actions > Wipe.
  4. Before confirming, check the settings for the device type:
    • Android Enterprise, fully managed: If required by the authorized reset path, select Turn on Factory Reset Protection in the Wipe confirmation dialog. The previously configured internal Google IDs, valid accounts with known credentials, and effective state must have been checked as described above. Invalid IDs or accounts, or unknown credentials, render the device unusable after a Wipe with FRP. Do not apply this selection to Delete or to a wipe in Fusion.
    • iPhone/iPad: In the confirmation dialog, set Preserve data plan and Forbid Quick Start according to the authorized recovery plan. Preserve data plan retains a cellular data plan present on the device after the factory reset, not the other device data. Forbid Quick Start skips the Quick Start step in Setup Assistant on the first startup after the reset—the step that allows content to be transferred from another iPhone. This is not a permanent block on all content transfers.
    • Mac: For Wipe, set a six-digit PIN and store it securely. It must be entered on the Mac to unlock it. The macOS system lock PIN can be found on the device page under Device properties > Unlock passcode and on the Task details page under Lock PIN. Store the PIN only using the designated secure procedure, not in the incident log.
  5. Select Yes in the confirmation dialog only once authorization has been confirmed.

Sophos Mobile creates a Wipe task and sends it to the device. A task that has been created, notified, or is still pending does not prove that a wipe has been performed. Check the specific task status and distinguish between reported as successful and confirmed on the device; if the device is found again, check its actual state. If the device is offline or missing, or the result is contradictory, do not claim that a wipe has occurred; instead, continue to track access and data risk in the incident and escalate. Neither a last synchronization nor sending the task is a success criterion.

There is no rollback for a wipe that has been performed. Subsequent enrollment or an inventory change does not restore deleted data. Restoring the device to service from suitable backups is a separate operation requiring authorization; check reactivation, reenrollment, and protection status separately in accordance with “Verify the outcome and escalate”. Do not infer from this procedure any assurance that a task that has already been sent can still be stopped.

SSP: full reset only with separate authorization

This workflow applies to Actions > Wipe in the Sophos Central Self Service Portal, not Mobile Admin or Fusion. It does not apply to Android devices on which Mobile manages only the work profile. Use the separate SSP Wipe Android work profile workflow for those devices. Sophos restricts the feature to certain device types without fully identifying them on this SSP page. An available administrator menu does not establish SSP support.

An executed reset restores the device to factory settings and erases all device data. This cannot be undone. Proceed only after completing the checks under “Before taking any device action”. Check device identification, effective SSP permissions, authorization concerning ownership and data backups, and a reactivation path that is actually usable for this method. If unsure, ask the responsible IT team first; Wipe is not a connectivity test.

  1. Sign in to the Sophos Central Self Service Portal.
  2. Open Mobile and select the unambiguously identified device.
  3. Select Actions > Wipe.
  4. For Macs, set a six-digit PIN and store it securely. It must be entered on the Mac after the reset to unlock it. The SSP help does not specify administrator field names or PIN retrieval paths for the SSP.

The FRP selection, Apple data-plan and Quick Start fields, and Yes from the administrator Wipe dialog are not documented SSP steps. The reset consequences described have not been tested in the tenant or on the device. A sent or pending action does not confirm erasure, particularly on an offline device. Separately check task status and the actual state, along with reactivation, reenrollment, and protection status. If the outcome is unclear, do not claim erasure; escalate.

After Unenroll: check readiness to return to service

Before returning a device to service after unenrollment, apply the reenrollment and protection-status checks in “Verify the outcome and escalate”. Resetting an app does not prove that protection remains effective.

Before Delete: check unenrollment and synchronization

Unenroll the device before deleting it from Sophos Mobile. The help for the Fusion device details under My Environment > Mobile Devices expressly warns that it may otherwise become unusable. This warning therefore also applies to this Mobile view. It does not override the Status > Not managed selection restriction in the Delete workflow below. For deletion of a still-managed, fully managed Android Enterprise device, Sophos documents an automatic factory reset. This is the documented consequence of Delete, not proof of a reset already performed or an extension of the FRP choice from the Wipe dialog.

For a still-enrolled device other than Windows, Sophos says that unenrollment triggered by deleting the record occurs only at the next synchronization with Sophos Mobile. It does not happen immediately or as a later administrator step. If the device remains offline, neither device-side unenrollment nor a factory reset has been confirmed. Verify actual execution even after a later connection; neither removal of the record nor the documented automatic consequence proves a successful reset. This automatic unenrollment after deletion specifically does not apply to Windows.

Fusion: delete an entry that is no longer managed

Clean up the Mobile entry only after confirmed unenrollment and separate authorization. After Unenroll, it initially remains in the device list and reports. A device record deleted from Sophos Mobile cannot be restored.

  1. In Sophos Fusion > My Environment > Mobile Devices, click Show filters.
  2. Expand the Status filter, select Not managed, and apply it with Apply. The list shows unmanaged devices.
  3. Click the name of the unambiguously identified device authorized for cleanup.
  4. In the device details, select Delete, not Actions > Delete. Select OK in the dialog only once authorization has been confirmed.

Then check that the entry has been removed. If the device is missing from the filtered list or unenrollment is unconfirmed, stop and clarify its status; do not bypass the filter. The documented consequences of Delete for still-enrolled devices do not establish that those devices can be selected through Not managed. Removal of a record does not confirm erasure on the device. The retention limits below still apply.

Distinguish unenrollment in the app from unenrollment in the SSP

Unenrollment in the Sophos Mobile Control app is not the same as uninstalling the app. It removes the server connection and associated data but leaves the app installed.

According to Sophos, local app unenrollment is unavailable for certain device types; the source does not identify those types. Do not infer a specific platform exception or SSP availability from missing app menus. This local workflow requires access to the device and is not a remote measure for a device that remains missing.

This says nothing about SSP unenrollment. According to Sophos, Sophos Mobile Control is uninstalled on iPhone/iPad when unenrolled through the SSP. Nor does the description of the app procedure replace the management-mode-dependent consequences of unenrollment above.

The Sophos instructions dated March 14, 2023 describe the following local app procedure. This is a vendor description, not verification in the current tenant or on the device, and not incident authorization. Proceed only after completing the checks under “Before taking any device action”: establish the device identifier, management mode, ownership and data authorizations, and recovery path.

  1. Open Sophos Mobile Control on the device you are authorized to access.
  2. On the Dashboard, use the route for the device type:
    • Android: Tap Management info > Unenroll.
    • iPhone/iPad: Tap Corporate management > Unenroll.

If the exact menu is missing, or suitability or authorization is unclear, stop and ask the responsible IT team; do not switch to the SSP, Mobile Admin, or Fusion. Do not trigger Unenroll as an availability test. After authorized unenrollment, follow the outcome and return-to-service checks under “Verify the outcome and escalate”; the app remaining installed does not prove that protection is effective.

SSP: Unenroll and its platform-dependent consequences

Unenroll in the SSP cannot be undone. Later reenrollment is a separate operation, not a rollback. This SSP workflow does not apply to devices with an Android work profile. Use the separate SSP Wipe Android work profile workflow for those devices. Unenroll is not a blanket lost-device response or inventory cleanup either. First check the device identifier, mode, effective SSP permissions, incident and data authorizations, and recovery path. For a fully managed Android Enterprise device, the factory reset documented above remains the consequence.

  1. Sign in to the Sophos Central Self Service Portal.
  2. Open Mobile and select the unambiguously identified device.
  3. Select Actions > Unenroll.

The SSP help describes the following additional consequences of executed unenrollment. Clicking in the portal is not proof of execution:

  • Existing Android management in Device administrator mode: Sophos Mobile Control and Sophos Intercept X for Mobile are reset. If necessary, manually uninstall the apps on the device with authorized access. This does not describe Android Enterprise; automatic uninstallation is not documented for this older mode.
  • iPhone/iPad: Device restrictions imposed by Sophos Mobile are lifted. All accounts configured by Sophos Mobile and their associated data, including work email, are removed. According to the SSP help, all apps received from Sophos Mobile are also removed, not all personally installed apps. These effects are in addition to the profile and certificate consequences already described, SSP uninstallation of Sophos Mobile Control, and the reset of Intercept X for Mobile.
  • Mac: Device restrictions imposed by Sophos Mobile are lifted. All accounts configured by Sophos Mobile and their associated data, including work email, are removed. Account for this in addition to the policy and certificate removal already described. It is not a factory reset or blanket deletion of all cloud accounts.
  • Windows: The Sophos Mobile MDM account on the device, server login credentials, and all other data received from the server are removed. This is the consequence of SSP Unenroll, not the automatic consequence of deleting the inventory record, and is not a full factory reset.

Before authorization, assess the protection and access mechanisms that will be removed. These consequences are vendor statements, not results tested here. Check delivery and actual execution as described in “Verify the outcome and escalate”. Do not claim successful unenrollment on an offline device. Clean up the record through the separate Delete workflow only after confirmed unenrollment.

After Delete: review retention and privacy separately

“Delete” removes the Sophos Mobile record and the device data stored there. Data previously uploaded to the Sophos Data Lake remains until the applicable Sophos XDR retention period ends.

Deletion proves neither erasure on an offline device nor removal of all cloud/audit data or fulfillment of a comprehensive deletion request. Review retention and privacy separately under your organization’s process.

SSP: Delete an already unenrolled or reset device from the list

Delete unenrolled device is subsequent list cleanup, not a lost-device response or a remote wipe. Only after confirmed unenrollment or a separately authorized reset that has actually occurred, and with the Delete unmanaged device permission, select the correct device in Sophos Central Self Service Portal > Mobile and use Actions > Delete. Then check that it no longer appears in your device list. A merely pending unenroll/reset task does not meet this prerequisite; do not assume that an offline device has already been unenrolled or reset.

This SSP branch is not equivalent to Fusion Delete for a device that is still managed. It proves no erasure on the device and restores no data; in particular, the Android factory-reset, Windows unenrollment, reactivation, and retention boundaries described above still apply.

Verify the outcome and escalate

For necessary, approved app diagnostics, click the name of the unambiguously identified device in Sophos Fusion > My Environment > Mobile Devices and select Actions > Get log files in the device details. This action retrieves the log files of all apps managed by Sophos Mobile on this device, not all installed apps indiscriminately. Use it only when diagnostics are needed and access and privacy permissions have been established; it is not mandatory in every lost-device incident. Requesting the files proves neither that they are already available nor that a lock or data erasure has been executed.

After an authorized action, check the specific task status in Sophos Mobile, the time of the last synchronization, and, if available, the actual state of a recovered device. Distinguish created/notified, reported successful, and physically confirmed. If the device is offline, the result is contradictory, or the device remains missing, do not claim it has been erased; continue to address access and data risk in the incident. Before returning it to service, separately authorize reactivation, required backup restoration, reenrollment, and verification of its protection status. A later inventory change does not restore a removed work profile or erased device data.

Limitations of this decision aid

The vendor documentation establishes product boundaries, not authorization to act on a particular device. Verify the interface, ownership, management mode, and policies in your own tenant. Release is not an immediate response to a lost device.