Sophos Mobile Self Service Portal: Safely Enable Actions and Device Enrollment

Permissions for this workflow: Creating and changing Mobile SSP settings requires access with the corresponding permissions of the Sophos Mobile Administrator role. The predefined Sophos Fusion roles Admin and Super Admin map to this role in Mobile, so Super Admin is not required for this workflow alone. Help Desk maps to Helpdesk in Mobile and cannot define these settings; Read-only can only view them, and User has no access to Mobile administration. This does not establish minimum permissions for a Custom Role: its specific Mobile editing permissions must be clarified separately in the tenant before you start configuring the settings. Use an existing identity with the appropriate permissions rather than granting additional permissions indiscriminately.

Quick path for admins: Under Setup > Self Service Portal, create a configuration for a tightly limited pilot group, choose the platform and ownership mode that match your device fleet, and select only the actions that group needs under Actions > Show. Before Save, tightly restrict the pilot group and actions: saving can make selected actions available to groups already assigned to the configuration. After Save, check the priority on Self Service Portal configurations against all matching configurations and Default using the arrows, and correct it if necessary. Do not assign more users until you have checked both a pilot and a Default test account and actually enrolled approved test devices on every intended platform and in every intended ownership/management mode. Do not enable destructive actions merely because they appear in the list.

This is the Sophos Mobile permission configuration within the SSP, not general account sign-in. Granting and delivering Sophos Fusion SSP access and assigning administrative roles in Sophos Fusion are separate tasks. An SSP user group is not an admin role: here it determines which Mobile configuration applies to a signed-in member. Depending on product entitlements, the shared Sophos Fusion Self Service Portal can also include Sophos Email and Sophos Device Encryption. Reducing Mobile group or action permissions does not revoke separately granted portal sign-in or access to those other product features. Turning off automatic User Access does not revoke portal access already granted, either. This article covers admin configuration, not the steps a user takes on their own device after loss, during recovery, or during setup.

Define the scope before enabling access

First, inventory the Mobile product edition actually in use in the tenant, managed platforms and ownership models (corporate or personal), user groups, and intended enrollment packages. The documentation for Sophos Mobile Device Management or the combined license lists more device actions than the separate Sophos Mobile Threat Defense documentation. An action appearing in an edition’s list is therefore not a guarantee that it is available in your tenant, on a particular operating system, or in its management mode.

Plan app registration and MDM enrollment separately: For Android and iPhone/iPad, the Threat Defense path registers Sophos Intercept X for Mobile and assigns its MTD policy; it does not automatically place the device or a work profile under MDM management. Before enabling SSP access, check which registration task the selected package triggers in your tenant. The Intercept X registration guide explains app prerequisites and registration paths; planned MDM enrollment instead requires a separately confirmed management mode. A registered app or device record alone proves neither MDM management nor effective protection.

ChromeOS remains a separate path: Manual SSP registration concerns the Sophos Chrome Security extension: the user installs it and enters an enrollment token. This is neither Android/iOS app registration nor MDM enrollment for those platforms. The Chrome Security guide distinguishes this path from automatic Google Workspace deployment.

For a pilot, create a dedicated group such as Mobile-SSP-Pilot containing only named test users. The name is arbitrary; membership is what matters. Do not add existing production groups just for a quick test. A person can belong to several groups; in that case the SSP configuration with the highest priority applies. The ever-present Default configuration has the lowest priority and applies when no higher-priority configuration matches. Check every overlap with broader groups before rollout.

Prepare configuration and enrollment texts

Prepare basic administrative settings separately: Getting started with Mobile includes personal settings and the technical support contact in addition to SSP configuration. The responsible admin configures the display settings for their signed-in admin account under Setup > General > Personal and saves them with Save; this establishes neither a required setting value nor a general enrollment prerequisite. Separately, the responsible IT team enters the approved contact information under Setup > General > IT contact and selects Save. Before the handoff to users explains the procedure and further setup, including verification. Opening Support in Mobile Control later displays the information already entered but does not configure it.

Avanet sequencing safeguard before updating the SSP or selecting Save: For each intended platform, ownership mode, and selected app or MDM path, check before updating or saving that the required configuration is ready: appropriate compliance and MTD or device policies, device groups, and existing enrollment packages or Task Bundles suited to the path and edition. Include Android Enterprise setup if an Android Enterprise MDM path is planned, and a valid APNs certificate if you plan MDM management of iPhones, iPads, or Macs. Do not infer these MDM prerequisites from Android/iOS app registration alone; check requirements for any additionally planned iOS web filter profile separately against the app workflow. Check license activation and the EAS proxy only where the deployed product scope or email path requires them; neither is a universal SSP prerequisite. If something is missing for an intended path, resolve that preparation before enabling its SSP settings. This is Avanet’s recommended sequence, not an additional formal approval required by Sophos or a substitute for the subsequent real enrollment test.

Only if the planned email path uses EAS: The optional Sophos Mobile EAS proxy filters email traffic from managed devices to the mail server or controls EAS access. In Proxy mode, this traffic passes through the proxy; in PowerShell mode, devices connect directly to Exchange and the service controls access through a separate management connection. First, clarify the mode-specific EAS architecture and access control and the EAS pre-installation review with documented configuration scope with the responsible Mobile/Exchange team. This handoff is a documentation-based preliminary review, not approval to install or migrate; compatibility with the specific build, mail clients, and tenant, as well as the separately authorized pilot, still need to be confirmed. It does not replace a lab test or resolve any service startup order still left open there. EAS is neither a universal SSP prerequisite nor part of the SSP steps described here.

Open Setup > Self Service Portal > Enrollment texts. If needed, create clear text to show before enrollment under Terms of use and brief instructions for afterward under Post-enrollment text, saving each name and content. Sophos permits HTML formatting; use only reviewed, data-minimizing content without personal device identifiers or credentials. Agreement to the Terms-of-use text is required if the text is assigned to the enrollment type; an empty field displays no text.
On Self Service Portal configurations, select Create. Under Name, set the name by which users select the configuration in the SSP; this is not the Display name they later use to select an enrollment type. Under User groups > Add, select the pilot group. A configuration can contain multiple user groups; for this pilot, keep it limited to the narrowly defined test group initially. The same group cannot be assigned to multiple configurations. Under Maximum number of devices, set a limit consistent with your policy; it limits how many devices a user can enroll through the SSP, not how many devices they may own or how many may be deleted.
Under Actions > Show, initially select only the actions needed. Then use Add to add a platform. In Configure platform settings, write the Display name and Description from the user’s perspective. Users see Description in the SSP beside the enrollment type’s Display name, not beside the configuration name Name. Align Owner, Device group, and Enrollment package with the planned app or MDM path and a deliberately selected device group. In the full Mobile edition, the Enrollment package is a Task Bundle for Android, iOS, and macOS, and a Policy for Windows; the Threat Defense instructions specify a Task Bundle. Do not reuse a package from another edition. For the Android/iOS app path, check that the existing bundle contains the intended MTD registration task and policy assignment. Policy selection in the Add device wizard is not an additional SSP package option.
Optionally select Terms of use and Post-enrollment text for each enrollment type, select Apply, and configure separate platform settings for other platforms or ownership models. Only after tightly restricting the pilot group and actions, select Save on the editing page. Then, on Self Service Portal configurations, use the arrows to check priority against all configurations with matching groups and Default, correcting it if necessary. Saving is not a consequence-free draft step: actions may become visible to users already assigned before you correct the priority.

Distinguish actions by effect and management mode

Platform applicability in Mobile Threat Defense: The action list specifies Reconfigure device and Show compliance violations for Android devices, iPhones, and iPads. Refresh data and Delete unmanaged device are listed for Android devices, iPhones, iPads, and Chromebooks. These and the following platform listings for the full Mobile edition describe the documented edition lists. They do not guarantee availability for your tenant, license, specific device, or its ownership or management mode; check these prerequisites before enabling an action.

View / refresh: The full Mobile edition lists Show compliance violations for Android devices, iPhone/iPad, Mac, and Windows. The action shows details of rule violations on noncompliant devices, not a general compliance report. Refresh data is listed there for Android devices, iPhone/iPad, Mac, Windows, and Chromebooks; it initiates device synchronization with Sophos Mobile and can affect its compliance status. Depending on the compliance policy, a prolonged lack of synchronization can make a device noncompliant, for example if it has been switched off for a long time. If this is the cause, Refresh data can restore compliance by synchronizing again; it does not automatically resolve other rule violations. For the initial permissions test, check only the visibility of these options with the pilot account, without triggering either action. If needed, run Refresh data separately on an approved test device afterward and check synchronization and compliance status; first verify platform and edition.
Reconfiguration is not an innocuous refresh: The full Mobile edition lists Reconfigure device for Android devices, iPhone/iPad, Mac, and Windows. It describes reconfiguring the Sophos Mobile Control app, for example after accidental uninstallation; Mobile Threat Defense concerns the Sophos Intercept X for Mobile app instead. The user-facing instructions for reconfiguring device management warn that an already managed device is unenrolled and must be enrolled again. That warning applies to the described device-management workflow, not automatically to current Mobile Control or Threat Defense app reconfiguration. Before enabling or running the action, verify the exact workflow for the edition, tenant, and test device, and plan for any necessary reenrollment and its effects on policies. Do not test it as a simple repair refresh.
Separate app reconfiguration (full Mobile edition): Reconfigure the SMC app concerns an already installed Sophos Mobile Control app on an iPhone or iPad. Do not conflate this separate SSP action with Reconfigure device. Before considering enabling it, the admin checks whether it is offered in the tenant for the device and its management mode, and what the specific workflow entails. Selecting it under Actions > Show only delegates a possible user action; it does not itself reconfigure the app.
Security or privacy implications: Locate device can disclose location data; the full Mobile edition lists Android, iPhone/iPad, Windows, and ChromeOS, whereas the Threat Defense list mentions only Chromebooks. Lock device is listed for Android, iPhone/iPad, and Mac in the full Mobile edition; that does not establish availability in every edition and management mode. Do not enable either as a universal “find my device” option.
Device or profile lock password (full Mobile edition): Reset password concerns the device lock, not sign-in to the Fusion SSP. Sophos describes a one-time password for Android devices and iPhone/iPad that must be changed after unlocking; for Android Enterprise with a work profile, it instead resets the work profile password, not necessarily the lock on the whole personal device. For iPhone/iPad, the same action description additionally says the previous device password is removed: a new one must be set within 60 minutes. Before delegating, clarify these platform- and profile-specific effects with the responsible device and incident owners. This information is not an instruction to trigger or test a reset.
Apple User Enrollment (full Mobile edition): Sophos explicitly excludes this management mode from Locate device, Reset password, Wipe, Managed Lost Mode, and Play Lost Mode sound. According to the action list, the two Lost Mode actions apply to iPhone/iPad outside this mode, not to Android or every Apple enrollment. Managed Lost Mode turns managed lost mode on or off; Play Lost Mode sound plays a sound on a device already in Managed Lost Mode. This describes the actions, not their successful delivery or execution on a specific device. Do not infer permission for other actions from this exclusion list, or specific availability from general platform listings.
App Protection password (full Mobile edition): Reset App Protection password is listed as a separate SSP action for Android devices and resets the password for apps designated as protected; it is not Reset password for the device lock. Enable it as a user action only when App Protection is actually deployed and you have checked availability for the device and tenant, not indiscriminately for all Android users.
Wipe (full Mobile edition): The action list specifies Android devices, iPhone/iPad, Mac, and Windows for resetting a lost or stolen device to factory settings; this deletes all device data. Explicitly excluded for iPhone/iPad with Apple User Enrollment. The separate work-profile removal action is not a full-device reset.
Wipe Android work profile (full Mobile edition): On Android devices where Sophos Mobile manages only the work profile, removes all work apps and work data, including Sophos Mobile Control, and ends Sophos Mobile enrollment. Personal apps and data are not removed. The removal cannot be undone and is not the same as wiping the whole device.
Unenroll device (documented Mobile MDM self-service workflow): The full Mobile edition’s action list specifies Android devices, iPhone/iPad, Mac, Windows, and Chromebooks. Distinguish this platform list from mode-specific unenrollment paths and consequences. This does more than end management: for Android Enterprise fully managed devices, unenrollment factory-resets the entire device. On iPhone/iPad, it removes the management profiles, managed apps, accounts and associated data (including business email), and certificates installed by Sophos Mobile; on Macs, it removes the policies, accounts and associated data (including business email), and certificates installed by Sophos Mobile. According to Sophos, this general unenrollment workflow does not apply to Android with a work profile: Wipe Android work profile is the separate removal path. Other device types have different consequences again; the action name alone implies neither a universal factory reset nor a consequence-free unenrollment. Unenrollment cannot be undone.
Delete unmanaged device: The full Mobile edition lists Android devices, iPhone/iPad, Mac, Windows, and Chromebooks. After unenrollment or a reset, the action deletes the no-longer-managed device record from Sophos Mobile; it neither wipes the device nor replaces unenrollment. The Threat Defense action list contains no Wipe or work-profile removal, but does list Unenroll device for Android, iOS/iPadOS, and ChromeOS, among other actions. A documented entry does not establish its effect on a specific device.

Before enabling, and especially before running, Wipe, Unenroll device, or Wipe Android work profile: Confirm the platform, ownership, and management/profile mode of the actual devices. Resolve backup and data retention, privacy and incident procedures, and the applicable change/incident approval before delegation, and obtain explicit authorization. Apply the same safeguards as appropriate to other deletion, locking, or Lost Mode actions. Without explicit authorization, do not trigger any of these actions for “validation”; reenrollment does not automatically restore deleted data.

For personally used devices, do not infer location tracking or full-device wiping from a general platform overview. The five explicit exclusions for Apple User Enrollment above do not extend to every personal enrollment. Confirm the device and profile mode on the actual device before any emergency decision. Enabling an action in the SSP delegates it to users; it does not instruct the administrator to remotely wipe a lost device themselves.

Test the pilot and stop if results differ

Before the final SSP enrollment test, check prerequisites for the app or MDM path actually selected. For Android/iOS app registration, app support, MTD entitlement, the existing registration bundle, and the intended MTD policy must all match the planned path; check additional iOS web filter profile requirements separately using the linked app guide. For MDM enrollment, by contrast: if the intended Android management mode uses Android Enterprise, its matching mode and the organization’s Android Enterprise setup must be ready; check the prerequisites separately for any other supported Android management mode. A valid APNs certificate must be available for MDM management of iPhones, iPads, or Macs. Do not make Android Enterprise and this APNs requirement universal prerequisites for app-only registration. Relevant compliance and MTD or device policies, device groups, enrollment packages, effective portal settings, and a reachable support contact must match the planned test path. Check license activation only if the deployed product scope requires it, and an EAS proxy only if the intended email access uses one. Neither is a universal prerequisite for every SSP test. Without these platform- and path-specific checks, do not interpret a failed enrollment attempt solely as an SSP permissions error.

After Save and any priority correction, check at least two group assignments in fresh sessions: a test user in Mobile-SSP-Pilot (also in a broader group if overlaps are realistic) must receive the intended configuration; a test user without a matching group assignment must fall back to Default. For both, check the configuration name, only the intended enrollment types and actions, texts, and device limit. If the name is not clearly visible, compare group assignments and the priority list in the admin interface; a portal display alone does not prove actual device permission. Do not trigger any actions yet.

Before invitations or broader group assignment, actually complete the approved registration path with explicitly authorized test users, a tenant, and devices. For each intended platform, ownership mode, and app or MDM path, check the matching Enrollment package and target Device group, and complete the workflow with the respective test group. Then check the following separately on the same test device and its record in Sophos Mobile:

Android – Intercept X for Mobile: Check completed app registration, the connection to Sophos Mobile, and the assigned Android MTD policy. This does not confirm MDM management of the whole device or a work profile.
iPhone/iPad – Intercept X for Mobile: Check app registration, the connection to Sophos Mobile, and the assigned iOS MTD policy; separately verify any planned web filter profile. Neither app registration nor a web filter profile proves Apple MDM enrollment.
Actual MDM enrollment: Confirm the previously defined management/profile mode and actual management status on the device and in Sophos Mobile. An additionally registered protection app does not replace this check.
Chrome Security SSP path: Check the installed extension, its registration by token, and the intended Sophos device group and Chrome Security policy; do not use Intercept X app status or Android MDM as success criteria.

The app checks for Android and iPhone/iPad do not prove effective protection; test its effectiveness separately in the respective platform policy pilot. If there are multiple target groups, test their group assignments as well. A visible portal entry is not enough for any of these paths. This article documents no device test already performed. Do not use Wipe, unenrollment, locking, or Lost Mode as pilot actions.

Wrong actions visible after Save: Stop rollout, invitations, and further group assignments immediately; do not trigger a device action as a countercheck. Under an approved change procedure, edit the affected configuration on Self Service Portal configurations: under Actions > Show, restore the action selection, and under User groups, restore configuration assignment to the documented, previously approved state; select Save on Edit Self Service Portal configuration. Restore any inadvertently changed memberships of affected user groups to that same approved state. Then on Self Service Portal configurations, use the arrows to restore the approved order for all overlapping groups; check Default as the lowest-priority fallback, but do not make broad changes to it without assessing effects on other users. In fresh sessions, recheck visible actions and enrollment types for both a pilot account with overlapping groups and an account without a matching group assignment. If visibility is still wrong, keep approval blocked and escalate to the responsible tenant admin. Determine whether an action was triggered in the meantime; if so, involve incident and privacy owners in device-specific recovery and next steps. This correction limits only future Mobile permissions; separately granted portal access and Sophos Email or Device Encryption permissions must be checked separately by their respective owners. It cannot undo an already executed Wipe, Unenroll device, or a disclosure of location; reenrollment may be necessary after unenrollment.
Enrollment missing or failing: Check platform, Owner, target Device group, Enrollment package, and edition-specific entitlement. Do not experiment on production users without a confirmed test path.
Portal unavailable: First check general SSP access assignment separately from Mobile configuration. Reset password and Reset App Protection password are device/app actions, not a reset of the Fusion/SSP sign-in password. The Fusion identity owner is responsible for the sign-in mode and password: when sign-in is exclusively federated, Sophos password reset is unavailable; changing the sign-in method is not a Mobile SSP fix and can affect access across products. Removing an admin role also does not delete the person or demonstrably revoke portal access; check that separately with the Fusion access owner. Successful sign-in does not prove that the Mobile group rule is correct.

User communications should include only approved self-service actions checked for the relevant platform and management type. The Mobile SSP user handoff separately covers enrollment, recovery, visible device steps, and the support contact for loss or failed reconfiguration, including effects on management and data; the admin settings shown here, especially destructive actions, are not passed on as general advice to users. The general SSP access assignment guide linked above explains only sign-in and invitation.