Sophos Mobile: Assign policies precisely and verify their effect
A Sophos Mobile policy contains settings for supported devices. Device group, assigned user, and policy type are not interchangeable: a device belongs to exactly one Sophos Mobile device group; user values can be inserted into policies as placeholders; and deployment and rollback depend on the policy type. This procedure covers direct policy assignment in Sophos Mobile. Task Bundles are a separate workflow; their creation, deployment, and troubleshooting are not covered here.
Before production use: This guide is based on official product documentation, not on tests performed in a tenant or on a device. Before approval, independently check the edition, license, admin role, OS, management mode, policy type, actual behavior when changing groups, and rollback on pilot devices. The reviewed pages do not establish a general precedence order for multiple competing policies.
Before assignment: define the target and rollback path
- Inventory target devices, operating systems, management modes, and edition (Sophos Mobile with device management or Mobile Threat Defense). A policy type offered in the interface does not establish that another OS or the app-only edition supports the same MDM payload. On Android, the available types also depend on the management mode.
- Should the change affect individual devices or a device group? Each device belongs to exactly one device group. Sophos recommends grouping devices of the same operating system for installation- and OS-specific tasks. This makes the groups easier to use for installations and other operating-system-specific tasks. Group compliance policies for corporate and personal devices can be selected separately when creating a group; this is not itself the assignment of a device policy.
- Record the starting state on a representative pilot device: group membership, assigned user, policy name, type, configuration, and existing assignments. Document the change window, owners, affected devices, and approved rollback path. For Wi-Fi, certificate, or password changes, ensure connectivity and independent access for rollback.
- Do not assume implicit precedence: The reviewed pages describe neither a general conflict or precedence rule for multiple policies on one device nor guaranteed automatic recalculation after later group changes. If policies control the same setting, measure the effective setting on a pilot device before expanding scope. “Priority” in the change process means starting with the narrowest pilot and then the approved target population; it does not assert a product priority number.
Prepare the device group and check its scope
Under Device groups > Create device group, enter a name and description, select the appropriate Compliance policies for corporate and personal devices, and choose Save. The new group appears under Device groups. The Enable iOS auto-enrollment option, documented in the full Sophos Mobile group-creation instructions, concerns automatic enrollment of iPhones and iPads with Apple Configurator; it is not a general policy priority and is not a prerequisite for other platforms. Its omission from the Mobile Threat Defense group-creation instructions does not establish that it is unavailable in every Mobile Threat Defense tenant. Before enabling it, check the edition and the actual interface in your tenant. When a device is added, it is assigned a device group.
Check the member list before assigning to a group. A selection under Select device groups affects the selected groups, not an arbitrary set of users. The 20 reviewed pages do not establish whether or when new group members inherit existing policy assignments. Test that case and a subsequent group change separately before approval; do not present either behavior as guaranteed.
Do not delete a group as a quick rollback. The deletion pages guarantee neither a particular policy or compliance effect nor a change in enrollment status. Because group membership changes, check the correct group by name and member list, identify affected devices, destination group, edition, and platform before any necessary deletion, and agree on a tested rollback path with the platform owner. Only then, under Device groups, choose Delete from the blue triangle beside the checked device group. For a group with assigned devices, select a remaining destination group in the confirmation dialog to which those devices will be reassigned; no such selection is needed for an empty group. The last remaining group cannot be deleted while devices are assigned to it. Check the group name, affected devices, and destination group if applicable again, and only then choose Yes to delete the group. Then check group membership and the actual policy and compliance scope of every affected device; if they differ from expectations, stop deleting groups and follow the approved rollback path. Neither manual Windows unenrollment nor an automatic Android reset can be inferred from these group-deletion pages; platform consequences need separate official evidence and technical testing.
Create and assign a policy
Under Policies, first select the device platform, then choose Create and a supported policy type. Enter a name and description; for iOS, iPadOS, and macOS policies, also enter the organization name. Use Add configuration to add the required configurations. Then click each configuration’s name to edit its settings. If a SCEP configuration is included, select the certificate renewal interval under SCEP renewal interval before saving. Check each configuration individually and choose Save only after adding all required configurations. You can then assign the saved policy. Sophos Mobile automatically adds a Restrictions configuration for Android Enterprise policies and a Network configuration for Mobile Threat Defense policies; this does not mean the editions offer the same functionality.
Alternative for basic policies: Policies startup wizard
The wizard is a creation path before assignment, not proof of an already active device configuration. It is suitable when basic policies are first needed for supported platforms; for specifically configured types and additional settings, the Policies > [platform] > Create path described above remains appropriate. The older Startup Guide names Android and iOS/iPadOS as selection examples, while the admin help leaves platform selection open; these wizard instructions do not apply to Chrome devices. Select only platforms and policy types actually offered and suitable for the edition, device, and intended management mode. On Android, the management mode affects the available policy types; Android Enterprise must be set up before enrolling the corresponding devices.
- On the Dashboard, open Getting started tasks > Policies startup wizard; if the widget is absent, choose Add widget > Getting started. On Platforms, select only platforms checked beforehand and set the appropriate management mode for Android. Sophos recommends Android Enterprise as the Android management mode here. Do not infer support for other Apple management modes or identical effects from an iOS/iPadOS example.
- On Policies, enter a clearly identifiable name: the wizard creates one policy under that name for each selected platform. Select the areas to manage. The wizard skips deselected areas; you can add them later to the saved policy. Review Password requirements and Restrictions as starting points rather than enabling them unchecked for every target device.
- On Passwords, choose only agreed device password requirements supported by the pilot devices and intended management mode. On Restrictions, set only approved restrictions; for example, do not impose a camera restriction without a business need. Check values and OS behavior on the pilot before broad assignment.
- Configure Wi-Fi only with approved corporate network details, once the connection method, security type, and independent fallback access are clear. For a security type other than WPA/WPA2 PSK, check and adjust the appropriate setting in the policy later; do not enter guessed credentials or credentials as placeholders. Configure Email only for the Exchange Online or on-premises Exchange access actually used; with
%_USERNAME_%and%_EMAILADDRESS_%, check the user assignment and substituted values on the pilot. Skip areas that are not needed and add them deliberately later. - Before Finish, compare the selection, target platforms, mode, and configurations with the approved change. Finish creates policies but does not automatically assign them to devices or groups, and proves neither synchronization nor OS-level effect. Then, under Policies > [platform], open each generated policy, check its type and settings, and add configurations with Add configuration if needed. If the selection was wrong, do not assign the policy; correct the saved policy and check it again first.
- Only then use the Assign procedure below for a narrow pilot, and check status as well as actual device settings as described under “Check effectiveness and approve rollout.” If they differ, stop expansion; correct the policy before assignment, or, after assignment, use the rollback path for the specific type under “Roll back instead of removing blindly.” A Task Bundle or SSP enrollment follows a separate procedure; Finish in the wizard replaces neither.
For direct assignment:
- Under Policies, open the platform; choose Assign from the blue triangle beside the correct policy.
- On Select devices, select individual pilot devices or use Select device groups to select the prepared device groups. Compare the list and number of affected devices with the change request before completing the assignment.
- The documented Schedule task steps name only Android device, Knox container, and iOS device policies. Choose Now to run immediately. To run later, choose Date and enter the intended day and time. The mention of iOS/iPadOS device policies in the policy-type overview does not establish this step for iPadOS. Do not assume a scheduling screen for iPadOS or other types; check availability in the actual tenant.
- Choose Finish and check the result for each target device. Alternatively, the Policies tab on an individual Sophos Mobile device details page offers Assign policy; for several selected devices, Devices > Actions > Assign policy provides a device workflow. Do not reconstruct the separate Task Bundle workflow here.
According to Sophos, the policy takes effect immediately if no execution date is entered. This also applies to direct assignment of an iOS device policy, not just to synchronized policy types. For a later change window, therefore, check the day and time under Date before choosing Finish; omitting the execution date does not postpone the change. The immediate effect described in the assignment instructions does not guarantee immediate implementation of every setting on an offline device. Continue to check task status and actual device settings.
Users are not a general third Assign target type: Direct selection in this guide names devices and device groups, not arbitrary user groups. When assigning a policy, Sophos Mobile replaces placeholders in policy settings with user, device, or customer properties. %_EMAILADDRESS_% and %_USERNAME_% insert values for the user assigned to a device; the latter represents that user’s Exchange Login, not necessarily the displayed name.
For device placeholders, you can use any property listed on the Device properties and Custom properties tabs of the relevant device’s Show device page. Look up the required property and its value there. For example, %_DEVPROP(IMEI)_% inserts the device’s IMEI value if it is available. Create customer properties via Setup > Sophos setup > Customer properties > Add customer property: enter a name and value for the customer property, then choose Apply, followed by Save. You can reference them, for example, with %_CUSTPROP(my property)_%. Check names and values before broad assignment, and check correct substitution and confidentiality on a pilot after assignment.
For macOS, Sophos uses properties of the assigned Sophos Mobile user for local Mac users and properties from LDAP for network users; a macOS user policy is assigned to users of the Mac when they log in. Do not infer from this that every device policy can be assigned separately per user.
Check effectiveness and approve rollout
According to the Policies overview, synchronized policy types take effect immediately on assignment and synchronize whenever the device connects to Sophos Mobile; this does not guarantee immediate implementation of every OS setting on an offline device.
Policy types differ in how an already assigned policy is updated after a change:
| Type | Update after a change | Rollback according to Sophos |
|---|---|---|
| Android Enterprise, Mobile Threat Defense, iOS/iPadOS declarative and user, Windows, Chrome Security | Synchronizes when the device next connects to Sophos Mobile; no manual Update devices required. | Adjust the policy or assign another one. |
| macOS device and declarative | Changes take effect at the next device synchronization; no manual Update devices required. | Adjust the policy or assign another one. |
| macOS user | Changes take effect when the relevant user next logs in to the Mac; device synchronization alone is not sufficient. | Adjust the policy or assign another one; check the effect after the relevant user’s next login. |
| Android device, Knox container, iOS/iPadOS device | According to the Policies overview, installed on assignment and to be updated on the device after changes. For iPadOS, the documentation conflict explained below applies. | According to the Policies overview, uninstall to remove the settings; no confirmed procedure for iPadOS. Handle broad unassignment separately. |
For iPadOS device, the documented scopes conflict: The Policies overview places Android device, Knox container, and iOS/iPadOS device in the same installed class: installation on assignment, updating on the device after changes, and uninstallation to remove the settings. By contrast, Apply policy changes to devices explicitly requires manual updating only for Android device, Knox container, and iOS device; all other policies are supposed to synchronize automatically. Uninstall policy also explicitly restricts uninstallation to those three types. Neither set of instructions names iPadOS separately. Whether their term iOS device policies also includes iPadOS therefore remains unclear. This establishes neither that iPadOS updating or uninstallation is generally impossible nor that a reliably supported procedure exists. Before making an iPadOS change, check the actual procedure and rollback path in your own tenant and on a pilot device; do not adopt the iOS click sequence without checking it.
For the explicitly documented types Android device, Knox container, and iOS device, after editing, trigger Update devices using the triangle beside the policy under Policies > [platform]: Sophos Mobile creates a task for all devices to which it is assigned. This is not a pilot action if the policy has already been assigned broadly. Do not assume the same update path for iPadOS device; verify it in the tenant on a pilot. For synchronized types, wait for the next connection and observe synchronization; for changes to macOS device and declarative policies, the next device synchronization is the relevant event. For changes to a macOS user policy, check the user’s actual settings only after the relevant user next logs in to the Mac. Successful device synchronization alone does not prove this user-level effect. “Immediately” in a type description is no substitute for checking an offline device.
Check assignments on the Fusion Policies tab
On the pilot device, check assignments in Sophos Fusion Admin under My Environment > Mobile Devices > [device] > Policies. This tab shows Sophos Mobile policies and Provisioning profiles assigned to the device. Use Refresh at the top right to reload the displayed information. Filter by policy name in the search field and check the result against the approved change.
Use the fields to identify the correct policy and the state of its assignment:
- Name gives the policy name, and Type gives the policy type.
- Version is the policy version. Sophos Mobile increases it automatically when you edit the policy. A higher version alone does not prove that the changed settings are in effect on the device.
- Assigned at shows when Sophos Mobile assigned the policy to the device or reassigned it after an update. It does not establish when every individual OS setting took effect.
- Status describes the assignment status, for example Applied. Check this status together with the version and actual device settings.
- Component identifies where Sophos Mobile sent the policy when assigning it. For most policy types, this is the device’s MDM agent.
Android Enterprise device policies and work profile policies can contain configurations that Sophos Mobile sends to a Google API rather than to the device. In that case, the list shows two entries for the same policy with different components and potentially different statuses. Check both entries; Applied for one component does not establish the other component’s status.
For macOS user policies, assignment to the relevant users takes place when they log in to the Mac. The list contains separate entries for all users to whom the policy is assigned, not just those currently logged in. These are the local user who enrolled the Mac with Sophos Mobile and network users known to Sophos Mobile from the external LDAP directory configured for the Sophos Fusion Self Service Portal. This does not imply assignment to every local account. The macOS enrollment guide also explains this user scope.
The overview does not show iOS/iPadOS device policies, Knox container policies, or Android device policies in the obsolete Device Administrator mode; iOS device policies containing only roaming/hotspot or wallpaper configurations can also be absent. In these cases, use Open in Sophos Mobile at the top right of the device detail page and check the effect on the device separately; do not interpret a missing row as a failed assignment.
Rollout gate: Before expanding scope, check pilot devices for every combination of edition, OS, and management mode; record intended versus actual scope, user/placeholder values, policy version, affected components, device settings, and task status. Do not roll out if results conflict or no rollback path exists. Only after business approval, repeat the procedure for the agreed target population, then perform the same checks on samples and exceptions. No tenant test was performed for this guide.
Download a policy for Support
The general download procedure is documented both for Sophos Mobile with device management and in the separate Mobile Threat Defense help; this does not mean the policy types, exported contents, or permissions are the same in both editions. First check the edition, device platform, exact policy type, and required admin role/permission in the actual tenant; select only the policy confirmed for the Support request.
- Open Policies in the sidebar and select the device platform. Choose Download from the blue triangle beside the policy whose name and type you have checked.
- Check that the file was saved locally on your computer and belongs to the selected policy (edition, platform, name, and type). Do not claim completeness or recoverability based on the filename or download alone.
- Before handing the file to Sophos Support, authorize the storage location and recipient, inspect the file for confidential settings and data, and disclose only what is necessary for diagnosis. If the diagnostic value is preserved, securely redact sensitive details; use an approved secure transfer method, have the authorized Support recipient confirm receipt, and securely delete local and transferred copies when their purpose has ended, in accordance with the approval.
Download does not assign a policy or synchronize a device, and it proves neither backup, import, restore, nor rollback. For actual rollback, follow the type-specific steps in the next section.
Roll back instead of removing blindly
- Synchronized types: Correct the existing policy deliberately or assign another policy that has been checked. The official uninstall function is not intended for these types. After connection and synchronization, check the new state on the device; for macOS device and declarative policies, check after the next device synchronization, but for an edited macOS user policy, only after the relevant user next logs in to the Mac. Check that user’s actual settings before treating the rollback as effective; device synchronization alone is not sufficient for the user policy. Do not promise that all platform-specific settings disappear immediately.
- Installed types: The Uninstall policy instructions explicitly allow uninstallation on an individual device only for Android device, Knox container, and iOS device policies. For iPadOS, the conflict with the Policies overview explained above remains unresolved. Under Devices > [device] > Policies > Uninstall, remove the correct policy only for a documented supported type and check on the pilot that the relevant setting is gone. Test the iPadOS rollback path separately in the current tenant and on the device before making a change; do not treat the iOS procedure as iPadOS instructions. For all devices to which one of the named policies is assigned, Policies > [platform] > [triangle] > Unassign offers a much broader path: do not use it for a single-device rollback. For multiple devices, Sophos describes an Uninstall policy task in a Task Bundle; carrying that out belongs to the separate Task Bundle workflow, not this article.
- A Support download is not a rollback: For the separate local file and secure Support handoff, see “Download a policy for Support” above; plan the actual rollback by policy type and check it on a pilot.
After any rollback, check the original device/group assignment, relevant policy entries, and actual settings again. Unassign, Uninstall, policy editing, and group deletion are different actions with different scopes. If the effect, mode, or edition remains unclear, stop the change and obtain expert approval for the device-specific rollback path.