Sophos Mobile: Investigate a compliance incident and check Wi-Fi access

When a compliance alert occurs, read first; do not immediately run another check or block access. Sophos Mobile does not block network access by itself; a Wi-Fi restriction depends on the configuration in Sophos Wireless. This guide is a path for investigation and decisions, not authorization to run commands in a specific Sophos environment.

Incident decision path: read, assess, escalate

1. Read-only — preserve the findings: Identify the affected device and assigned policy, rule violation and timestamps under Compliance; review Events separately. Record only approved device identifiers, rule/event times, the relevant policy and the minimum necessary technical findings in the approved incident channel, following its access and retention rules. Do not collect private file contents, app inventories, screenshots or comprehensive device exports without separate need and authorization.
2. Read-only — assess the impact: Do not equate an app detection with a compliance violation or an actual Wi-Fi block. Check the platform, management mode, confirmed license/edition, rule action, integration status and MAC mapping; assess Wi-Fi impact only against the affected device and corresponding AP/client.
3. Stop before making changes: Check now, policy corrections and tenant-wide NAC activation are not initial triage; refer them to the responsible policy or Wireless/network owner. Consider manual overrides only with device-specific authorization, a documented starting value and an expected effect. After an approved action, confirm device status and actual AP/client access separately.

Read-only: distinguish rules from events

Identify the approved target device, its assigned user and — separately — its owner, platform, Sophos Mobile license and edition, enrollment and management mode, device group, policy and last synchronization. For personal devices, investigate only within the approved management scope.

In Sophos Fusion > My Environment > Mobile Devices, click the name of the approved device and open the Compliance tab. For a device managed by Sophos Mobile, this tab shows details of compliance violations when the device is noncompliant. A device becomes noncompliant when it violates a rule in its compliance policy. The target device uses the policy assigned to its device group for the relevant ownership type: Compliance policy (corporate) for corporate devices and Compliance policy (personal) for personal devices. Check the device’s ownership type against the corresponding group assignment without making changes; the two fields may contain different policies.

In the list, Severity gives the severity of the compliance violation as High, Medium or Low. Type identifies the rule violation, and Info contains its details. Created at shows when the compliance violation was detected. For example, if the policy includes Minimum OS version and the device’s OS version is older than required, Type shows OS version too old. Info shows the required and actual OS versions. This lets you compare the requirement with the device’s state without lowering the minimum version as an initial response.

The Refresh icon at the top right reloads the information on the Compliance tab. It proves neither a new device scan nor delivery of an action. If needed, narrow the Compliance list using the severity filters above it; choose filters based on the specific incident rather than copying the example selection.

On the same device page, open the Events tab. It shows events associated with the device managed by Sophos Mobile. Event contains the event text, and Severity gives the event severity as High, Medium, Info or None. These values are not the compliance severity scale. Created at shows when Sophos Mobile created the event, not when a compliance violation was detected. This timestamp does not prove remediation. Keep the check result distinct from the actual device status as well.

The Refresh icon at the top right reloads the information on the Events tab; here too, it proves neither a new device scan nor delivery of an action. If needed, narrow the Events list by creation date using the filters above it and record the selected time reference in the findings. For events across all devices, consult Reports > General Logs > Events.

Fully managed Android Enterprise devices: According to Sophos, all apps are disabled when such a device becomes noncompliant. This does not apply across the board to Android work profiles or standalone Mobile Threat Defense. Establish the management mode and possible rule actions before running any further check.

Check now is not Refresh: The compliance check in Sophos Mobile and Mobile Threat Defense checks all registered devices and executes configured actions. The policy documentation for Sophos Mobile Device Management and the combined Sophos Mobile edition describes task bundle transfer, among other actions; incorrectly used bundles can wipe devices. The policy creation page for Sophos Mobile Threat Defense, by contrast, shows Create alert. Before any action, confirm the actual license, administration interface, role, platform and mode with the policy owner; do not trigger Check now as an impromptu test.

Read-only: assess app detections and Wi-Fi impact separately

App detection: For Sophos Intercept X for Mobile managed through Sophos Mobile on Android, distinguish a malicious app, a potentially unwanted app (PUA), a file and an app with a low reputation. A detected malicious app is blocked; by default, a PUA generates a warning on the device, although the policy and exceptions can affect that behavior. Low-reputation scanning is off by default; if enabled, Apps with low reputation controls warnings or access blocking. Whether app or PUA detections affect compliance is determined separately by Malware apps allowed and PUAs allowed. Do not extrapolate these Android detection outcomes to iOS.

For a read-only review of the individual settings, see the Android protection policy. If Detect PUAs is off, no PUA scanning takes place. Enable user to allow PUAs permits users to allow an app so that it is ignored in subsequent PUA scans. The selected App group can exclude individual apps from PUA or reputation scanning. Such exceptions do not resolve a detection and are not an initial incident response. Compare the specific detection, rule and policy settings: a PUA notification proves neither malware nor a Wi-Fi block.

Malicious files: Scan storage is off by default. When enabled, IXM warns on the device about a detection but neither blocks the file nor cleans it up automatically. To remove it, the affected person must delete the file manually. Do not issue blanket instructions to remove suspicious files; advise the affected person on any removal only after device-specific authorization and an assessment of the evidence needed and potential data loss. Do not routinely collect private file contents as evidence.

Is the integration active? With Synchronized Security, Sophos products exchange security-related information through Security Heartbeat. Sophos Wireless can use the Sophos Mobile compliance status of Android and iOS devices to restrict network access; such a restriction requires a health-based access rule configured there. For this documented Wireless path, Sophos names only APX 320, APX 530 and APX 740. Only if an existing environment uses this integration, check its enrolled access points in Sophos Fusion, the Wireless rule, enabled NAC integration and a compliance policy assigned to the device group. This legacy APX dependency is outside the Mobile check and is not a recommendation for a new APX installation. A Mobile health status or enabled Mobile NAC integration proves neither that this integration is in use on AP6 nor that it is supported there. Setup > Sophos setup > Network Access Control > Sophos Wireless > Save is a tenant-wide change, not a read-only triage step.

Can this device be mapped? Synchronized Security can also be used for devices enrolled through third-party EMM: the custom app configuration for Intercept X for Mobile must contain the device’s MAC address so the Sophos APX Series access point can identify it. Do not treat this as proof that mapping works on the specific Wi-Fi network. Missing or network-specific MAC addresses prevent the intended mapping. The documentation for Device Management/combined Mobile names Chromebooks, Apple User Enrollment and devices with Private address or Randomized MAC as limitations; the Threat Defense page names Chromebooks and private/randomized MAC addresses but does not expressly name Apple User Enrollment. Do not infer support for that mode in Threat Defense. Set network access in the Device Management/combined Mobile documentation also excludes Macs and Apple User Enrollment.

Which edition and rule action are confirmed? According to the Synchronized Security page, the compliance policy defines the health status a device receives when it is noncompliant; different health statuses can be set for individual rules. The policy creation page for Sophos Mobile Threat Defense, by contrast, shows only Create alert. An automatic MTD rule-to-health-status-to-Wi-Fi-block chain is not established here and must not be assumed as an incident response action. Clarify the license/edition, administration interface and actually available rule action with the policy and Wireless/network owners.

Only with approval: narrowly scoped changes

Before a change, the appropriately authorized role must document the target device, license/edition, platform and mode, existing manual overrides, the starting values of both settings, expected effect, delivery and verification method. Policy changes and Check now belong to the policy owner; the guide on planning and checking compliance policies describes this separate task but does not grant operational authorization. NAC integration and Wireless rules belong to the Wireless/network owner. Device-specific authorization for the settings below is not blanket authorization for such tenant-wide changes.

Tenant-wide NAC change: Only if the documented Wireless path applies to the existing environment may the responsible Wireless/network owner, after obtaining separate authorization, open the Network Access Control tab under Setup > Sophos setup. Before any change, record the actual previously saved integration selection and the approved target selection in the change record — separately from device-specific network-access and health-status overrides. The Sophos guide Turn on Synchronized Security documents activation only, not a recovery path. Before activation, therefore, check whether the previous selection can be selected again in the actual interface and whether restoring it is documented as supported for this environment. If no such recovery path exists or it is unclear, do not activate the integration; clarify it with the Wireless/network owner and Sophos Support. If these prerequisites are met, select Sophos Wireless and save with Save; then reopen the Network Access Control tab and compare the saved selection with the approved target. Check the affected Wireless clients’ actual access at the corresponding AP/client separately: neither Save nor a health status proves the effect on Wi-Fi access.

NAC rollback: If there is a discrepancy, stop further changes. Only with authorization and a confirmed, documented supported recovery path may you select exactly the previously recorded integration selection in the same tab, save with Save, and reopen the tab to compare it with the starting value; check the affected AP/client access separately again. If the previous selection is unavailable or restoring it is not documented as supported, do not assume that deselecting, turning off or resetting the integration provides a recovery path; escalate to the Wireless/network owner and Sophos Support. Auto mode and removing device overrides do not restore the tenant-wide NAC selection. These safeguards are a prospective verification and rollback plan, not tested in a tenant or lab and not evidence of successful recovery.

• Network access (documentation for Sophos Mobile Device Management/combined Mobile; confirm availability in the specific environment): After device-specific authorization and documentation of the starting value:
  1. Open Devices and select only the identified and authorized target device from the device list. Check the selection against the authorization; select multiple devices only with an explicitly reviewed device list and authorization.
  2. Select Actions > Set network access.
  3. Select the authorized value: Allow grants access regardless of compliance status, Deny refuses it regardless of that status, and Auto mode ties it to compliance. Allow can override a security rule and does not resolve a rule violation.
  4. Recheck the target selection and selected value, then save with Yes. Afterwards, check the saved network access value, device status and actual AP/client access separately; confirmation alone does not prove any effect on Wi-Fi access.
• Health status (Mobile or Threat Defense with Synchronized Security enabled; confirm permissions and availability): After device-specific authorization and documentation of the starting value:
  1. Open Devices in the menu bar and click the name of the identified and authorized device.
  2. On Show device, select Actions > Set health status.
  3. Select the authorized health status. Manual Red can be set regardless of compliance status; Auto mode removes only this manual health-status override and calculates the status from compliance.
  4. Sophos Mobile reports the device’s health status to Sophos Wireless. The Wireless rule determines whether access may be blocked; check actual device status and AP/client access separately. For multiple devices, select the devices on Devices and select Actions > Set health status. This is permitted only with an explicitly reviewed device list and authorization.

Device-override rollback: Restore the previously documented value for each of the two device settings — use Auto mode only if it was the starting value for that setting. For network access, select the same verified target on Devices, open Actions > Set network access, select the documented starting value and save with Yes after rechecking the selection and value. Then recheck the saved network access value and actual AP/client access. Removing a health-status override does not remove a separate Allow/Deny override or resolve a rule violation. Monitor delivery, actual device status and AP/client access separately; green status does not prove a Wi-Fi connection.

Trace the cause and outcome — exclude destructive steps

With Sophos Mobile Control, the affected person may see a notification and violations with Fix it on the dashboard. The link in the Self Service Portal is visible only for supported device types; the documentation does not identify the excluded types. A missing link does not prove compliance. Managed Intercept X for Android or iOS can display a violation and guidance; network or feature restrictions are possible, not guaranteed. Match user instructions to the specific rule first. Tapping in the app does not remove an administrative override.

View compliance violations in Intercept X on Android and iOS

When Sophos Intercept X for Mobile on Android or iOS is managed by Sophos Mobile, the local app dashboard shows the compliance status based on the organization’s policy. The affected person opens the guidance on their device as follows:

1. On the dashboard, tap the Corporate management tile. This tile has a red icon when there are compliance violations.
2. Tap an individual compliance violation to open its instructions. Before following them, match the guidance to the specific rule and device-specific authorization. Clarify any unclear or risky actions with the policy owner. If the actions are authorized, follow the displayed instructions to resolve that violation.

The red icon belongs to the Corporate management tile. On Android, distinguish it from the Insecure rating under Device security; on both platforms, it proves neither a manually set Red health status nor an actual Wi-Fi block. Opening the guidance does not resolve a violation or remove an administrative override. Following the instructions does not guarantee resolution or restored Wi-Fi access either; the outcome checks described below are still required. This procedure applies to the managed Android and iOS app, not to Sophos Mobile Control or the Self Service Portal.

View compliance violations in the Self Service Portal

This procedure is for the affected person in the Self Service Portal, not for actions in Mobile Admin:

1. The affected person signs in to the Sophos Central Self Service Portal, opens Mobile and selects their own affected device.
2. Next to Compliance Status, they click the Noncompliant link to view the compliance violations. The link is available only when the device is noncompliant. The restriction to supported device types mentioned above also applies.

To make the device compliant again, the affected person must take the necessary actions on their device. Before guiding them through those actions, match the displayed violations to the specific rule and clarify device-specific authorization. Opening the link does not resolve a violation, remove an administrative override or prove that Wi-Fi access has been restored. Clarify any unclear or risky actions with the responsible policy owner rather than bypassing safeguards or triggering destructive steps. Separate outcome checks are still required afterwards.

For a possible false alarm, compare the rule, exceptions, group assignment, OS threshold, minimum necessary app detection details, synchronization, relevant permissions, MAC mapping and existing overrides against the approved incident data. Have only the policy owner correct an incorrect policy assessment in a targeted way. After an approved correction, check Compliance, Events and, where applicable, the user app again; verify actual Wi-Fi access at the corresponding AP/client separately. If the status remains contradictory, escalate before making further changes.

Stop before destructive steps: Wipe, Factory Reset, deletion of the device record, unenrollment, removal of the work profile and task bundle transfer are not initial responses and cannot be undone with Auto mode. They belong in a separate, authorized process: for device loss, the draft on lost-device safety decisions supports assessment before authorization; for a user change or deletion, user assignment and offboarding must be reviewed separately. Neither reference grants device-specific authorization. The respective process requires checks of ownership and private data, management mode, backup and approval for data loss, Android FRP or Apple Activation Lock, recovery access, as well as task delivery and observed completion. Retrying deletion is especially dangerous: deleting an enrolled, fully managed Android Enterprise device can trigger a factory reset. The scope of Wipe depends on the console and mode; for Android with a work profile, Fusion describes removal of the work profile, not a generic factory reset. Remote Lock is not a compliance-incident test: for an Android Enterprise work-profile device, it locks the whole device, not just the work profile; a remotely locked Mac cannot subsequently be wiped with Wipe. Stop here without device-specific authorization.