Safely plan and review Sophos Mobile compliance policies

A compliance policy is not a certificate or a device profile. It evaluates selected rules for enrolled devices and can trigger actions when rules are violated. What matters is the actual product edition (Sophos Mobile or Sophos Mobile Threat Defense), platform and OS version, company-owned or personal device, enrollment and management mode, the Intercept X for Mobile app (IXM) managed by Sophos Mobile where applicable, and the assigned device group. A visible rule or PCI/HIPAA template proves neither that it applies to every device nor that it confers certification.

Before any production action: Check now checks all enrolled devices and executes configured actions. Creating or changing a policy and assigning it to groups are not read-only steps either. First establish the full set of affected devices and a way to reverse the changes; do not use a production fleet for testing.

What is actually evaluated?

First select the product edition, then check the platform, OS, and enrollment mode: With Android Enterprise fully managed, MDM manages the entire device; Apple User Enrollment enrolls personal Apple devices with a limited scope of management; supervised refers to supervised iPhones/iPads. An IXM app managed by Sophos Mobile is not, by itself, evidence of full Mobile Device Management (MDM). In your own tenant, verify which rules are available for the edition and mode actually in use; do not conflate the rules and actions of Sophos Mobile with those of Sophos Mobile Threat Defense.

Rules define which device features or states are allowed, forbidden, or required. The response to a violation is selected separately; a compliance criterion alone does not prove that a device setting is actively changed or enforced.

To create a policy in Sophos Mobile or the standalone Sophos Mobile Threat Defense edition, open Compliance policies, click Create compliance policy, and select the Default, PCI, or HIPAA template. Enter a name and an optional description; the choice of template does not limit later settings. Only the Default template has no preset actions; PCI/HIPAA templates may already contain actions. Sophos describes the rules and actions in the PCI/HIPAA templates as based on HIPAA and PCI DSS. However, the ordering of templates and standards in the documentation is ambiguous; do not infer a mapping of an individual template to a standard here. The platform tab must be activated with Enable platform: If it is not checked, no compliance check takes place for devices on that platform. The severity levels high, medium, and low are fixed for each rule; they are not the same as a response action you can choose freely. During policy planning, they help assess the importance of each rule and select an appropriate response to a violation. This does not authorize executing an action during an incident. Highlight rules in the full edition helps highlight a management type but does not prove that a rule applies to every device of that type.

Click Save only after configuring and reviewing the rules and their associated responses for all required platforms. This saves the policy under the name you entered; group assignment follows separately after the checks described below.

Sophos Mobile (full edition/MDM): In addition to platform-dependent management and OS rules, IXM signals are possible when Sophos Mobile manages the app. The available responses for each rule are Deny email, Lock container, Set health, Create alert, and Transfer task bundle; the platform and prerequisites for each action still apply.
Sophos Mobile Threat Defense (separate product edition): Its separate set of rules includes Android IXM permissions and malware/app detections, iOS web filtering, and Chromebook security rules. Create alert is documented as a response for this edition, not the MDM actions for email, containers, health, or task bundles.

In the standalone edition, Installed apps and Mandatory apps apply only to Chromebooks. For Installed apps, first select Allowed apps or Forbidden apps, then the app group containing the allowed or forbidden apps or extensions. For Mandatory apps, select the app group containing the apps or extensions that must be installed. The Android, iOS, and Mac mappings described below, along with the notes on system apps and Android app updates, belong to the general catalog of the full Sophos Mobile edition, not to these two rules in the standalone Threat Defense edition.

The separate Mobile Threat Defense compliance rules catalog within Sophos Mobile Help describes a subset for Android/iOS devices whose IXM app is managed by Sophos Mobile: for example, root/jailbreak status, OS limits, IXM synchronization, and Android app scans. A managed app alone does not prove full MDM device management; this subset is also not the rule catalog for the standalone Sophos Mobile Threat Defense product edition. On Android, the rule Intercept X for Mobile permissions can be denied determines whether denied IXM app permissions make the device noncompliant. It can flag a failure of web filtering as a violation when Accessibility Service permission is denied; Sophos recommends setting it to No when using web filtering. The iOS rule Web Filtering turned on appears in the general Sophos Mobile rule catalog and in the catalog for the standalone Threat Defense edition, not in the IXM subset mentioned above. On iPhones and iPads, it requires the Web Filtering feature in Intercept X for Mobile to be enabled; this is a separate criterion, not the Android permissions rule. Chromebook rules are not automatically Android/iOS rules.

The managed IXM subset is documented in both the Sophos Mobile and Sophos Mobile Threat Defense help. For devices whose IXM app Sophos Mobile manages, it specifies these mappings:

Managed required applies to Android and iOS. The rule sets the response when a device is no longer managed. It is not the same as Device administrator management allowed and does not establish full MDM management.
Minimum OS version and Maximum OS version apply to Android and iOS in this subset. They set the earliest required and latest permitted OS versions, respectively. The absence of a platform list in the general catalog below does not change this mapping.
Malware apps allowed applies only to Android here. Use this rule to specify whether malicious apps detected by IXM are allowed.
PUAs allowed applies only to Android here. Use this rule to specify whether potentially unwanted apps detected by IXM are allowed.

These two app rules evaluate compliance. They are not scan settings or authorization to unblock detected apps or exclude them from future scans. Detection consequences and exceptions are assessed separately in the compliance incident response guide linked below.

A Maximum interval between … synchronizations rule is a configurable compliance rule for the relevant synchronization source: the operating system’s native MDM software, Sophos Mobile Control, IXM, or Sophos Chrome Security. The general catalog maps them as follows:

Native MDM: iPhones/iPads without Sophos Mobile Control or IXM, plus Macs and Windows computers.
SMC (Sophos Mobile Control): Android devices and iPhones/iPads.
Intercept X for Mobile: Android devices and iPhones/iPads.
Sophos Chrome Security: Chromebooks.

Each of these rules limits the maximum permitted interval between the relevant agent’s synchronizations with Sophos Fusion; do not interchange agents or time values. By contrast, Maximum interval between Intercept X for Mobile scans limits the interval between IXM malware scans on Android, not between synchronizations. Whether a limit has been exceeded must be assessed against the rule that is actually enabled and violated, and the corresponding synchronization or scan time. Separately, a delayed or failed synchronization can mean that a displayed compliance status is no longer current; by itself, it proves neither a rule violation nor compliance. A status unknown to the EAS Proxy is a different case again, handled by the separately configured Exchange quarantine workflow, and is not automatically a violation of the maximum-interval rule.

Select rules for the checks you need

The following groups organize the general rule catalog of the full Sophos Mobile edition for planning. They are not a list of recommended defaults. First verify the edition and management mode, then select only the appropriate criteria and review each rule’s response separately.

Management status, versions, and updates

Managed required / Device administrator management allowed: The first rule concerns devices that are no longer managed; the second sets actions for Android devices on which Sophos Mobile itself is used as Device Administrator. This Sophos Mobile management mode is deprecated and available only on Android 9 or earlier; it cannot be used on Android 10 or later. Sophos recommends migrating to Android Enterprise. This is a limitation of this Sophos Mobile management mode, not a claim that Android Device Administrator APIs have been removed altogether, nor guidance on newly enrolling such devices.
Minimum SMC version: The earliest permitted version of the Sophos Mobile Control app, for Android and iPhones/iPads. Do not confuse it with the IXM or OS version.
Minimum OS version / Maximum OS version: The earliest or latest permitted operating system version, respectively. The catalog does not provide a separate platform list for these two entries; check availability on the relevant platform tab.
Mandatory OS updates: For supervised iPhones/iPads, not Apple User Enrollment. Latest available update requires the latest available update; Latest critical update requires the latest update classified as critical by Apple. The latest available update may be newer than the latest critical update. Latest critical update is unavailable from iOS/iPadOS 27 onward. For update management on these devices, Sophos specifies a declarative policy with Software update settings or Enforced software update; do not infer that the previous compliance selection continues to have the same effect. Software update settings requires iOS/iPadOS 26 or later, Apple Device Enrollment, and a supervised device. For Enforced software update, Sophos lists iOS/iPadOS 26 or later and Apple Device Enrollment as prerequisites, but no additional supervision requirement. This minimum version of 26 is distinct from the version 27 boundary for the previous Latest critical update selection.

Apple update information needs its own network path: For information about available updates on iPhone, iPad, and Mac, mesu.apple.com must be reachable over HTTPS 443. If this destination is unreachable, Sophos Mobile has no update information, and compliance rules for mandatory updates have no effect. Check the actual path with the network administrators before treating such a rule status as reliable. This does not extend the platform, OS, or enrollment limits of Mandatory OS updates listed above, nor does it claim that all Apple update installations fail.

Device protection and separation of work data

Root access allowed (Android): Specify whether rooted devices are allowed. The documented permission also covers Sony devices with Enterprise API Level 4 or later and Samsung devices with Knox Standard SDK 5.5 (API Level 17) or earlier that the operating system considers insecure. These are historical qualifications in the rule help, not a recommendation to use these devices today.
Android Debug Bridge (ADB) allowed (Android): Specify whether the ADB debugging interface is allowed or forbidden.
Allow jailbreak (iPhone/iPad): Specify separately whether jailbroken devices are allowed; do not carry over the Android root rule.
Screen lock required (Android, iPhone/iPad, Windows): Specify whether a device password or another locking mechanism is required. On Android, Pattern, PIN, and Password count, but Swipe does not. With Apple User Enrollment, the rule is satisfied if the assigned policy contains a Password policies configuration.
Encryption required (Android, Mac, Windows): Require encryption; on macOS, the rule concerns FileVault full-disk encryption. According to the rule help, iPhones and iPads are always encrypted and are not in this rule’s applicability list.
Container configured (Android): A container must be configured and activated, such as an Android work profile or a Samsung Knox container. This is a state criterion, not the Lock container response.
Data roaming allowed: Allow or forbid data roaming for Android and for iPhones/iPads without Apple User Enrollment.

Do not apply a blanket Android encryption fix: The current rule help still mentions Require PIN to start device or Require Password to start device when setting up an Android screen lock. This does not establish that these startup PIN or password options are available on current Android versions or in every Android Enterprise mode. The separate KBA-000004067 describes a failure involving the displayed default encryption key and names a startup PIN and manual synchronization as a remedy, without specifying an OS version or enrollment mode; it is not a universal remedy for current Android versions or Android Enterprise modes. Before changing anything on a device, establish the error actually observed, the supported OS version, and the enrollment mode; do not recommend a blanket PIN change or Synchronize now.

Apps, profiles, and permissions

Installed apps: First select Allowed apps or Forbidden apps, then the app group containing the allowed or forbidden apps. Applies to Android, iPhones/iPads without Apple User Enrollment, Macs, and Chromebooks. Android system apps are always allowed; Chrome OS app groups can contain apps and extensions.
Mandatory apps: Select the app group whose apps must be installed from the list. Chrome OS groups can also contain extensions. On iOS, do not add system apps as mandatory apps: Sophos Mobile cannot detect their installation and, according to the rule help, marks all affected devices as noncompliant. For Android, Sophos documents in SMCAND-3159 that concurrent app updates while the Control app is syncing with the Mobile backend can briefly cause the status to change to noncompliant and then back to compliant, especially on older devices. To assess this without making changes, compare the rule that was actually violated, the timing of the updates and synchronization, and the status observed afterward. This is not a reason to weaken the mandatory-app rule. A later compliant status does not establish that operation was unaffected or that app, mail, or wireless access was restored; the documented automatic return to compliance is neither an outcome observed here nor a guaranteed timeframe.
Suspicious apps allowed (Android): Specify whether suspicious apps detected by IXM are allowed. This is a separate compliance selection, not automatically the same as scan settings for low-reputation apps.
Third-party profiles allowed (iPhone/iPad, without Apple User Enrollment): Specify whether configuration profiles not managed by Sophos Mobile are allowed.
Unmanaged apps from unknown sources allowed (iPhone/iPad): Specify whether in-house apps installed manually through an IPA file and signed with an ad hoc provisioning profile are allowed. Do not equate this with the Chromebook rule for apps outside the Chrome Web Store.
SMC permissions can be denied (Android): The Control app needs permissions to function, which must be granted during installation. The rule determines whether denying them triggers a compliance violation. This is a different app from the one covered by Intercept X for Mobile permissions can be denied above.
Locate permission required (Android): For the Locate feature, specify whether compliance requires the permission granted to the Control app during installation to retrieve location data.
App is able to locate (iPhone/iPad): Location services must be enabled and the Control app must be allowed to use them. This combination is separate from the Android installation criterion. Neither location rule grants organizational or legal authorization to collect location data.

Check Chromebook, Mac, and Windows criteria separately

Chromebooks: The following rules concern Sophos Chrome Security, not the Android Control app:

Tamper protection turned off: Select responses for cases where the Chrome Security policy has been tampered with.
Minimum Sophos Chrome Security version: Set the earliest permitted version of the Chrome Security extension.
Apps from unknown sources allowed: Specify whether apps and extensions outside the Chrome Web Store are allowed.

Macs: The criteria concern whether the relevant protection is enabled; they do not prove that the compliance rule itself enables it:

Firewall required: The macOS firewall must be enabled.
System Integrity Protection required: SIP must be enabled. This macOS protection feature limits the root user’s actions; it can be configured when booting into macOS Recovery. This does not authorize changing SIP during normal operation.
Security updates required: Automatic installation of macOS security updates must be enabled. The rule help limits this to macOS 26 (Tahoe) or earlier; this is not the iOS/iPadOS 27 boundary of the mobile update rule.

Windows computers: Select three separate Defender criteria; do not infer them from a single status:

Windows Defender must be turned on: Windows Defender real-time protection must be enabled. This remains the intended requirement. For Windows 10, however, Sophos documents a limitation of the check in SMCSRV-13801: The rule checks only whether the Defender service is running, not whether real-time protection is enabled. A device can therefore appear compliant even when protection is turned off. Before relying on that protection, separately verify the actual real-time protection status on the Windows 10 device using read-only checks, without changing protection settings or policies. A running service and the compliance status are no substitute for this device-level check.
Clean status from Windows Defender required: The device is noncompliant if Windows Defender displays warnings.
Up-to-date Windows Defender definitions required: Windows Defender must use the latest spyware definitions.

Do not confuse responses with the rule

Create alert creates an event visible on the device details page and an alert in the full edition; Threat Defense describes alerts in Sophos Fusion. An alert is not a configured email or container block. Selecting only Create alert does not, however, guarantee that device health or wireless access will remain unchanged; noncompliance may have other consequences.
Deny email is a configured response to a violated policy rule in the full edition; it requires a configured connection to the Sophos Mobile EAS Proxy and is intended for Android, iPhone/iPad, and Windows. The presence of an EAS Proxy alone proves neither how the relevant mail service authenticates nor that delivery has actually stopped or resumed. Separately, Sophos describes Exchange quarantine for unenrolled devices only with the EAS Proxy in PowerShell mode and an appropriately configured Exchange default access rule. Enrolled devices can also be quarantined there if their compliance status is unknown to the proxy because too much time has passed since synchronization or because it cannot connect to Sophos Mobile. The enrollment notification sent by Exchange during quarantine is neither Create alert nor evidence that Deny email was triggered. Do not infer general quarantine or automatic restoration of email from a rule violation or an alert; investigation belongs in incident response, not this policy planning.
Lock container is intended for Android Enterprise in the current full edition, not as a confirmed iOS container lock. The full-edition compliance-action table describes this configured action as locking all apps except Sophos Mobile Control, Sophos Intercept X for Mobile, Google Play Store, Contacts, Messages, and Phone. That general description does not specify the effect on apps in a personal BYOD profile; neither the six exceptions nor the work-profile example below proves personal apps remain accessible. For a supported Android work profile, Sophos documents Auto (the default when no manual access permission is set: the work profile is locked if a violated compliance rule includes Lock container), Deny (work profile locked), and Allow (work profile unlocked) under the separate access control setting. When locked, work-profile apps and data are inaccessible; the setting takes effect only after device synchronization. This work-profile access control is distinct from the whole-device Lock command; it establishes neither the effect of the configured compliance action on personal apps, nor its availability for every BYOD/enrollment scenario, nor a tested recovery path. Check the scope and effect on an authorized device before approval.
Keep Set health separate from calculated health: Set health is an explicitly selected action for each rule in the full edition: when that rule is violated, the selected Red/Yellow/Green value is assigned; if multiple rules are violated, the worst assigned health value applies. The action requires Synchronized Security to be enabled for Android, iPhone, and iPad; for an intended wireless effect, the policy’s health value for noncompliance and the wireless rules must also be configured. Separately, Fusion displays device health based on compliance-rule violations; when Synchronized Security is enabled, it can be overridden manually, while Auto returns to calculation from compliance status. It is unclear what value results without a Set health action in every edition and mode, or how a manual override and a simultaneous rule action are prioritized; do not infer either an automatic Red/Yellow assignment or unchanged health from Create alert. Check the violated rule/noncompliance, saved Set health action, displayed health and its manual/Auto status, value reported to Wireless, and actual access separately. Depending on its configuration, Sophos Wireless can restrict network access; a console display alone does not prove any particular wireless effect.
Transfer task bundle can misconfigure devices or even wipe them. Do not configure wipe/reset tasks or automatic task bundles as the default response; None here means only that no task bundle is transferred, not that noncompliance has no consequences.

Special case: On a noncompliant Android Enterprise fully managed device, the full edition automatically disables all apps, regardless of the response selected for each rule. This is neither equivalent to the configurable Lock container action nor an established effect for Android BYOD/work-profile devices, MTD-only, or other Android modes. For Android BYOD, the effect of Lock container still depends on the management mode actually supported and the configuration; do not infer a device lock from a possible work-profile lock. Check access to the phone, work profile, recovery, and critical apps on an authorized test device before any approval.

Synchronized Security is not available for all devices: Sophos excludes Chromebooks, Apple User Enrollment, and devices with a network-specific/private or randomized MAC address because they do not report their MAC address to Sophos Mobile. The separate option to pass the MAC address through IXM app configuration when using a third-party EMM does not establish an exception for private/randomized MAC addresses. Plan a wireless pilot only for a device/enrollment mode that is actually supported, with verified MAC and Synchronized Security configuration; a health display alone is no substitute for an access test.

Assign in stages instead of testing globally

Record the inventory and prerequisites: Document the tenant, license/edition, management mode, platform/OS, ownership, IXM management status, last synchronization, existing rules, and active dependencies on EAS Proxy and Sophos Wireless. Document Synchronized Security eligibility and MAC limitations, displayed device health and whether it is manual or Auto, existing Wireless rules, and policies and assignments.
Assess each rule and action individually: Open the current rule catalog for the correct product edition; for each enabled platform, inventory every rule inherited from the template or set manually, along with its response. Check the signal, mode, and action prerequisites before Save and before assignment; do not assume PCI/HIPAA is passive. For an approved pilot, plan a new, isolated policy without blocking or destructive actions, and recheck the actions actually saved. If Set health is absent, that does not establish that calculated or manual health, or Wireless access, will remain unchanged. Important: Even Create alert alone, or None for a task bundle, does not prevent the documented automatic app deactivation on a noncompliant Android Enterprise fully managed device. Exclude such devices from this pilot until a device-specific test of app accessibility and recovery has been authorized and prepared for the actual version and mode.
Select a limited pilot group: Consider the planned corporate and personal devices separately. If the approved pilot needs a new group, first prepare the device group and check its scope. If both ownership types are managed, Sophos recommends separate compliance policies for corporate and personal devices; two separate assignment fields alone do not mean that different policies are in use. Under Device groups > [Group] > Compliance policies, corporate and personal are assigned separately. Before Save, check each target device’s one and only current device group (including the existing Default group, if assigned), ownership type (corporate/personal), and that group’s policy assignment for unintended scope. After selecting the policies for corporate and personal and checking the scope, click Save to save the group assignment. Then, on the Device groups page, compare both Compliance policy (corporate) and Compliance policy (personal) columns for the selected group with the planned assignment. Before changing an existing shared policy, check all groups assigned that policy; the change may affect other groups, not because a device belongs to multiple groups. A new isolated pilot must not silently change a shared policy.
Verify the effect in the authorized pilot: Before deliberately causing a violation, confirm again that no Android Enterprise fully managed device is included in the alert-only/action-free pilot; Create alert or None does not protect its apps. First compare the group assignment and the specific device, including its new compliance status, violated rule, synchronization time, and any alert/event. On the supported test device, separately observe the Set-health action actually saved, displayed health, and manual/Auto mode before and after the violation; if Synchronized Security is enabled, also observe reported health, the Wireless rule, and actual Wireless access. Check mail flow and app accessibility as well if the configuration makes them relevant. Even without a Set-health action, do not assume network access will remain unchanged; do not interpret delayed or absent synchronization as compliance. Deliberately cause a violation only with a confirmed recovery path and no risk to production data. Before expanding to fully managed Android Enterprise devices, first check on an authorized device whether the documented automatic consequence occurs in the actual version and mode, and whether recovery works.
Expand only after acceptance: Compare affected devices and unexpected violations against the initial state. If there are discrepancies, stop the expansion, restore the documented previous group assignment and rule/action configuration after approval, and verify recovery again on the device and in external services. Removing a rule does not automatically undo task bundles or wipes already executed, or external access blocks.

Do not use as a test: Compliance policies > Check now applies to all enrolled devices and executes their configured actions—even if only a small group was intended. Before a planned full compliance check, all groups and responses must be reviewed and the change approved; this article does not authorize pressing the button in the production tenant.

For planning only; not tested: A specifically approved group with one corporate iPhone (no Apple User Enrollment and not Android Enterprise fully managed), a previously verified applicable, non-destructive rule, and Create alert could serve as a limited pilot. Before assignment, record every rule/action pair, group membership, and, if Wireless is part of the test, Synchronized Security eligibility, MAC address, and Wireless configuration. During an authorized, reversible test violation, check the violation/noncompliance and event on the device details page in the console, along with the console alert in the full Sophos Mobile edition; in the standalone Sophos Mobile Threat Defense edition, check the alert on the Alerts page in Sophos Fusion. Separately check the displayed Health (manual/Auto) and, on the target device, email flow, app accessibility, and actual Wireless access before and after synchronization. Do not expect an alert on the physical target device. Do not infer that Health or network access will remain unchanged from Create alert alone. Stop if other devices are affected, synchronization does not occur, or Health/access differs unexpectedly; do not expand the test, restore the previous assignment after approval, and check the effect again. This is a test plan, not an observed test result.

Scope and prerequisites for use

Investigating a device that is already flagged or blocked, alert triage, handling false positives, and restoring email/Wireless access are outside the scope of this policy-planning guide. It does not replace incident or reset instructions. An Android startup PIN measure or manual synchronization from KBA-000004067 is not a general fix without checking the specific error and the supported device/enrollment combination. For read-only initial triage and assessment of Wi-Fi access, see the guide to responding to a compliance incident; it does not authorize operational action either.

The procedures described here have not been validated on devices or in a tenant. This article does not authorize operational action. The relationship among the selected Set health action, automatically calculated or manually overridden Health, and the effect on Wireless is not resolved here for every mode. Rule/action combinations for each product edition, OS, and mode, as well as recovery paths for EAS/Wireless and Android app accessibility, must be authorized and checked on the specific device before operational adoption.