Sophos Mobile Threat Defense on Android: Planning a Protection Policy Safely

Draft – not an approved operating procedure. A Mobile Threat Defense policy for Android configures Sophos Intercept X for Mobile (IXM) when the app is registered with Sophos Mobile. It is neither an Android Enterprise device policy nor evidence of full MDM management, effective web filtering or Intune MTD integration. Sophos Mobile Threat Defense entitles you to manage IXM and Sophos Chrome Security; Sophos Mobile includes the features of Device Management and Threat Defense. Sophos Mobile Device Management alone does not provide MTD entitlement: managing IXM as described here requires a Sophos Mobile or Sophos Mobile Threat Defense licence. Confirm the licence, admin permissions, app registration and device mode in the actual tenant. The Mobile licensing decision guide explains how to check these under Profile icon > Licensing in Sophos Fusion.

On Android Enterprise devices managed by Sophos Mobile, the MTD policy installs IXM; before assigning it, the app must be added to Sophos Mobile as a managed Google Play app. This prerequisite belongs to the Mobile Enterprise management path, not automatically to every app-only Threat Defense tenant. Check the Play catalogue entry, Android Enterprise connection and limited installation evidence using Prepare Managed Google Play and deploy apps; do not change a shared app configuration without checking it first. For another enrollment path, check installation and IXM registration separately; a visible app does not yet prove both steps have succeeded.

Stop before assigning Web Filtering: On Android Enterprise with a work profile, the Android MTD Web Filtering configuration does not apply: IXM in the work profile cannot access the Sophos Accessibility Service required for it. Neither a saved policy entry nor a visible app makes it effective there. When Web Filtering is enabled on an eligible device, it blocks all websites if https://4.sophosxl.net/lookup cannot be reached. Check access to the classification service, Accessibility permission, suitable browsers, an independent communication channel and a limited pilot before enabling it. Do not claim a work-profile exception by moving IXM to the personal area without verification.

Scope and decisions before making changes

Record the tenant, edition and actual MTD licence, role, device/Android version, Android Enterprise fully managed, work profile or a separately verified app-management mode, IXM registration with Sophos Mobile and current policy state. A personally owned device is not necessarily a work-profile device, and MTD does not automatically mean MDM. Third-party EMM device enrollment does not replace registration of the IXM app with Sophos Mobile. The separate method for automatically registering IXM through third-party EMM requires custom app settings, a prepared IXM enrollment configuration and a Connection code. This method cannot be combined with Intune Mobile Threat Defense that is already configured; this is not a blanket restriction on every Intune-managed device. Establish the appropriate path, code/user mapping, installation and registration using Register Intercept X for Mobile. This article approves neither this EMM enrollment procedure nor any EMM provider. Confirm the supported combination of Android version, edition and app mode in the target environment; do not infer it from the policy name.
For the approved test group only, record the relevant policy type, device or group membership, required app permissions and previous state. Creation, assignment, conflict/group logic and rollback are covered separately under Assigning policies: use Policies > [platform] > Create, choose the appropriate MTD type, enter a name and description, and check the automatically added Network configuration. Add any other planned areas through Add configuration and open their settings; check every configuration before Save. Then assign it only to the approved target group. This article does not prescribe a universal precedence for competing policies. Registration and app distribution remain separate tasks.
Before a Web Filtering pilot, check that IXM runs outside the unsupported work-profile case, that Accessibility permission is actually available and that the service URL is reachable over the intended networks. Prepare suitable test pages, business-critical browser/app dependencies, approved exceptions and an accessible alternative communication channel. If the prerequisites cannot be confirmed: do not assign the policy.

Antivirus: app scans and exceptions

The Android Antivirus configuration manages malware protection. When it is assigned, the user can no longer change the corresponding IXM settings themselves. Assess the fields individually; an enabled scan does not guarantee that every object will be detected or that a detection will be removed automatically.

Update mode determines when IXM downloads current malware information. The selected data connection must be available on the intended devices; do not confuse an update setting with a completed update.
Scheduled scan interval determines the frequency. Daily while charging starts a scan only after more than 30 minutes connected to a power source; it does not guarantee that a scan is completed every day.
Installed apps are scanned by default. Scan system apps adds the normally omitted system apps, which are protected by Android and cannot be uninstalled by users.
Scan storage also covers files in internal shared storage, on SD cards and on connected USB media. Monitor storage monitors changes there and scans newly saved files. This can increase scan load and may affect private files: clarify device ownership, permissions, storage volume and data protection beforehand.
Detect PUAs checks for potentially unwanted applications: they are not necessarily malicious, but may pose privacy, security or usage risks in a business environment. Enable user to allow PUAs permits users to allow them; an app allowed this way is ignored in subsequent scans. Do not treat detection and permission as the same switch.
Under Apps with low reputation > Mode, Allow disables this particular check. Warn displays a warning; users can allow the app and suppress further warnings for it. Block prevents affected apps from opening. The decision must align with the approved exception policy, not just the number of annoying messages.
Scan notification controls notifications after an app scan during installation. If the checkbox is cleared, no notifications are generated for clean apps; this does not mean that all detection notifications are disabled or that the apps have not been scanned.
The selected App group excludes apps from scanning and is therefore a security exception: keep it small and approved rather than exempting an entire business-app group indiscriminately. Before changing it, document its members and the business reason; after reversing the change, scan again on the same device and check the results.

Distinguish local settings, scanning and privacy

In the app, Settings contains local scan, notification and update options. Make local changes only after approval and where the management state permits them; have the responsible administrator change locked settings. Manage allowed apps shows allowed apps that do not appear in scan results; after removal from that list, they may appear again under Threats and PUAs.

Allowing system apps is not a bypass for managed apps: The Android client release notes for 9.8.4125 describe a new option to allow system apps detected as threats, reducing repeated warnings for apps that cannot be removed. This addition applies only when Sophos Mobile does not manage IXM, and not to non-system apps. It therefore does not authorize locally allowing such a detection in the managed IXM app covered here. Suppressing a warning does not remove the detected threat either.

For local scan scope, select Scan system apps if Android system apps should also be scanned. The default omission of these protected apps, which users cannot uninstall, described above also applies here. Detect PUAs enables local detection of potentially unwanted apps, not permission to allow them. App reputation enables detection of low-reputation apps based on Sophos Live Protection data. This local switch is not equivalent to the central Allow/Warn/Block response.

Select Scan storage to include SD cards and USB storage in local scans. Enable Monitor storage to scan new apps and files downloaded or copied to these media. This also automatically starts a scan for newly connected storage media. Matching field names alone do not extend this documented local SD/USB scope to the central scope described above, which includes internal shared storage. Approvals for scan load and potentially private files still apply.

The local Scan notification switch enables scan notifications for clean apps. When it is not selected, notifications for malware, PUAs and low-reputation apps remain enabled; this does not disable scanning. IXM scans apps when they are installed on the Android device and when they are launched from SD cards or USB storage. Notifications can be viewed in the Notification Panel. Do not interpret missing notifications for clean apps as evidence that a scan did not take place.

The Android notification channel Protection status is separate from these notifications. The historical release entry 9.7.3542 describes the status notification Sophos Intercept X is protecting you and states that dismissing the notification or disabling this channel does not affect protection. This is not an instruction to disable all IXM notifications. Scan notification, detection notifications, Create events for Web Filtering and reports to management are other mechanisms; User Activity Verification and the Fusion Notification Center must also be distinguished from this channel. Neither the presence nor the absence of the status notification proves a successful scan or an applied policy.

Under Settings > Update mode, select the data connection for downloading virus detection data, where local changes are approved. To check how current the protection data is, inspect Version for the antivirus engine and antivirus data, and Last update. Last update gives the date on which antivirus data was retrieved from Sophos; tapping it checks for updates. The date is neither the time of a mere update check nor proof that a scan has just completed.

Track data to help improve usability permits anonymous usage data; Send log to Sophos first shares trace/log files with another app so they can be sent to Sophos Support. These are separate privacy decisions, not scan prerequisites or a promise of “no telemetry”. Before sharing logs, approve their contents, recipient, secure transfer method and deletion once their purpose has been fulfilled; share only necessary diagnostic data.

Start a local manual scan through App security > Show scan details > Start. The App security issues overview and Show scan details display detections; under Threats and PUAs > [App] > Object details, you can check the installation source, requested permissions and threat description. From Object details, you can also open a web page with detailed threat information in the browser. This local browser action is separate from the Fusion lookup described later. Do not reflexively use the Allow or uninstall actions offered in Object details: first clarify approval, management state and consequences for business data.

Where the policy does not prevent it, configure local scheduled scans in Settings by enabling Scheduled scans and choosing an option under Scheduled scan interval. The local Daily while charging option also starts a scan only after more than 30 minutes connected to a power source; it does not guarantee that a scan is completed every day. IXM uses online lookups and a local scan engine; this does not guarantee detection of every threat or identical protection without a network connection.

Put dated data-usage figures in context: The Sophos Sizing Considerations dated April 14, 2022 specify 256 Bytes per app for every malware scan by Intercept X for Mobile on Android for online lookups of current threat data in the SophosLabs database. Separately, the source gives an average of 10-20 KB per day for downloading antivirus-engine data updates. These dated estimates from documentation are neither measured usage on your own device nor upper limits or a budget for all scan or device traffic; the daily average applies only to the stated data updates. Do not apply them to iOS or an offline scan. Before planning data usage, check actual consumption for the intended app inventories, scan intervals and update conditions in an approved pilot; do not disable protection or update features solely to meet these estimates.

An APK already obtained from a legitimate source can be checked before installation by selecting it in the file manager and using the share function with Scan with Intercept X. IXM scans the selected APK for threats and displays the result. Inspect this displayed result for the selected file. Do not use APK installation from unknown sources as a test prerequisite: installations outside Google Play increase risk; even a clean APK scan does not prove a trustworthy source or authorize installation.

Trigger a central scan and check the latest findings

In Sophos Fusion, My Environment > Mobile Devices > [test device] > Actions > Scan for malware requires a Sophos Mobile or Sophos Mobile Threat Defense licence and an IXM app on Android managed by Sophos Mobile: clicking it sends a scan task, not an immediately confirmed finding. Check the task status through Open in Sophos Mobile > Tasks. If the action is missing, check installation and management first rather than repeatedly initiating scans blindly.

In the Fusion device details, use Refresh under Scan results. The list shows the most recent scan, not a complete history. Type distinguishes Threat, Suspicious, PUA and Low reputation; Name, Identifier and Version identify the app, Threat names the threat where applicable, and Detected at gives its detection date. Use the search field to filter by threat or app name, version or identifier; the type filters above the list narrow down the detection type. For additional threat information, open the Threat name and then the matching result. This opens the threat’s page in the Sophos Threat Center. Use the links there for further information. Make app identifiers and detection details accessible only to authorized people. Old or empty results do not establish that a new scan succeeded: check task status, how current the results are and the app display on the same device together, without assuming automatic cleanup.

Network: Wi-Fi security, not Wi-Fi configuration

Network > Man-in-the-middle protection manages the IXM Wi-Fi Security feature, particularly checks for man-in-the-middle attacks. A detected attack generates an event in the device details and an alert. Users can no longer change assigned Network settings in the app; set Extra settings only when instructed by Sophos Support. This is not a Wi-Fi SSID, certificate or VPN configuration.

Because of Android’s location-permission model, the Android app requests precise location and background location when Wi-Fi Security is switched on: a Wi-Fi name can reveal information about location. Requesting permission here does not mean that IXM retrieves or tracks location; this limited statement is not a promise that no network or diagnostic data is processed. Agree this sensitive permission with data-protection stakeholders and the device owner before the pilot. Do not assume successful Wi-Fi protection without confirmed permissions; do not bypass managed settings through private user changes.

In the app, under Network security > Wi-Fi Security, Check Wi-Fi checks the currently connected network. Background check checks when connecting to Wi-Fi, where the management state permits the setting. Checks cover content manipulation (altered website content that induces harmful actions), SSL interception (intercepting traffic with a false certificate, which can expose sensitive data despite an apparently secure, encrypted connection) and SSL stripping (downgrading HTTPS to HTTP). Wi-Fi Security cannot detect ARP spoofing (falsely mapping the gateway to the attacker’s MAC address) on devices running Android 10 or later because of an Android limitation (Sophos Known Issue SMSECAND-4570). Legitimate captive portals, such as a public Wi-Fi sign-in page, may also generate additional warnings because they redirect all traffic to the portal. This does not authorize ignoring warnings or bypassing protection features. The absence of an alert does not prove that every network is safe; observe the app’s check result, permissions and any central event separately, without staging a real attack.

Android Web Filtering: effects, lists and permissions

The MTD configuration controls how malicious websites are handled through Filter malicious websites and how content categories are handled through Filter websites by category. Categories are updated continuously; a classification is not a permanent record. Create events determines whether only blocked requests or also warnings generate events in the device details. For an approved pilot, record the selected event scope and check the expected test events there; a missing warning entry with a block-only setting is not, on its own, a protection failure.

Classification requires https://4.sophosxl.net/lookup; if it cannot be reached, Web Filtering blocks all websites. When the filter is enabled, particularly severe criminal content is always blocked and those URLs are masked in logs, events and reports – not all URLs. Do not access such content for testing. For Web Filtering, plan to set the compliance rule Intercept X for Mobile permissions can be denied to No, so that a filter failure caused by the Accessibility Service being switched off is detected as non-compliance. This is not automatic recovery; separately review the actions and possible access/app consequences of a compliance policy, and do not configure a dangerous response or status change without approval.

Keep exceptions narrow and check precedence

Exceptions are not a harmless quick fix: A policy allowlist takes precedence over the policy blocklist; both take precedence over the user allowlist. Category blocking follows. For the Threat Defense edition, a user blocklist is additionally described between the user allowlist and category blocking; this intermediate step has not been established for the full edition. Before adding an exception, therefore, check the actual edition/version-dependent precedence in the pilot rather than assuming an identical order. A local user allowance does not override a policy blocklist; mandatory blocking of particularly severe criminal content must still be respected.

Allowed domains permits sites despite a blocked category; Blocked domains blocks sites despite an allowed category. Both fields accept one domain name, wildcard domain, IPv4/IPv6 address or subnet per line, without separators or a protocol prefix such as https:// or chrome://. Browser-internal identifiers are also valid exception entries: bookmarks instead of chrome://bookmarks is a syntax example, not a recommendation to block bookmarks. A wildcard * must be at the beginning. A single * in Blocked domains blocks all websites within the filter’s scope.

The syntax examples www.example.com, *.example.com, 203.0.113.0/24 and 2001:db8::/32 are valid forms, not business exceptions intended for copying. For an approved test, first choose a specific domain name that is actually needed and replace the example with your own verified entry. A wildcard or subnet covers a wider scope than a single name or address; check its reach and required app dependencies beforehand, and do not use broad entries as a quick fix.

According to Sophos, Web Filtering applies to all web traffic on supported devices, including web traffic from third-party and system apps and external resources that websites load, such as fonts. Broad wildcards can make business apps or websites unusable. Try only one individually approved, verifiable exception entry in an isolated pilot, with the original list recorded; after testing, remove the exception deliberately and check the block/allow effect again. Do not use a global allowlist as a supposed remedy for a classification-service outage.

Check browsers and local controls

Supported browsers are Android web browser, Firefox, Google Chrome and Microsoft Edge; others may work but have not been tested. In the app, Web Filtering is visible under Network security > Web Filtering. If the browser, Accessibility, device-mode and reachability checks described above are satisfied, the change is approved and the management state permits local changes, switch on Web Filtering on this page. Then tap Malicious content and select Warn or Block. For each intended content category, tap the category and also select Warn or Block. Have centrally controlled settings changed through the approved policy workflow instead; do not bypass them locally.

Always allow access to this page in the warning dialog adds a local exception; Clear allowed pages list removes local exceptions again. This is neither a blanket bypass of central rules nor a rollback of an MTD policy. Agree any broad removal of local allowances beforehand as well.

Check the intended browser under Protected browsers; Protected browsers (not tested) is not acceptance evidence for additional browsers. If a supported browser is installed but not listed under Protected browsers, check whether Sophos Accessibility Service is enabled under Accessibility in the Android system settings. The interface is not evidence that a tenant policy has actually been applied and does not replace checking the policy’s and app’s effects. The work-profile limitation remains regardless of visible switches.

Do not present Link Checker and Device security as policy components

Link Checker is a dedicated app feature that lets you check links from non-browser apps for malicious or inappropriate content. It cannot check links opened internally within an app; links must be handed over to the browser. It is not an additional configuration component of the three MTD areas covered here, Antivirus, Network and Web Filtering, and assigning those areas does not switch it on automatically.

Warning – the default browser changes: Only if this separate app feature is wanted and approved, record the existing Android default browser. Then, under Network security > Link Checker, operate the switch next to Link Checker is turned off, confirm the message with OK, select Intercept X and choose Set as default. With multiple browsers, select the desired destination browser under Checked links open in this browser. Test a harmless link handed over externally; for apps with an internal browser, assess the existing setting for opening links in the browser separately. In Gmail, this is Open web links in Gmail: turn it off only after approval if links should be handed over to the browser. This change affects how that app handles links and does not guarantee coverage of every link.

Choosing another default browser in Android switches Link Checker off. Settings > Clear defaults stops IXM being used as the default app for supported links. To revert, restore the previously recorded default browser and any in-app link option you changed, then check the same harmless link handover again; this does not remove the central web-filter policy.

Device security assesses Android security settings and displays recommendations. Green with Secure means the maximum possible security for that particular setting, not complete device security or an applied MTD policy. Red with Insecure indicates possible security issues. Review the recommendation for that setting and have an approved change implemented accordingly.

Yellow with Unknown means that IXM cannot determine conclusively whether the setting is insecure because of the device model or Android version. Consider changing that setting after review and in consultation with the responsible administrator; do not force a change based on the colour alone. Grey with Turned off means that the check is disabled and the setting is excluded from the device security status. This does not mean that the underlying Android protection feature is switched off. Do not interpret yellow or grey as secure.

Under Device security, tap a setting to read more about its security implications or open the offered path for changing it. Not every tap changes a setting or grants authorization to change it. When the app is managed by Sophos Mobile, the organization configures security-related system settings. Do not tell users to override managed settings; a recommendation is not an additional Android MTD policy component.

Interpreting release notes on device assessment

The following Android client changes are documented in earlier releases; mentioning them confirms neither the installed version nor an effect verified on the device.

Secure NFC: In 9.8.4125, Security Advisor takes the Android setting Require device unlock for NFC (Secure NFC) into account. Enabled NFC is no longer automatically assessed as insecure if Secure NFC is supported and enabled. If Secure NFC is supported but disabled, a warning recommends enabling it. Check support and the actual state on the intended device; do not extend the statement about supported Secure NFC to devices without this feature or disable NFC indiscriminately.
Accessibility services: 9.7.3829 introduced a Device security warning when an Accessibility Service is enabled; 9.7.4013 added the option to select individual services that can be exempted from these warnings. Such a warning exception neither disables the service nor authorizes it in Android MDM. Web Filtering still requires the Sophos Accessibility Service explained above. By contrast, Allowed accessibility services in the Android Enterprise device policy controls which apps may provide accessibility services; check this separate MDM area using the Android corporate policy. Do not infer from the release note that a local exception action is available for every managed app, and do not disable the required Sophos service to eliminate a warning.
Device integrity: 9.7.3672 replaced Google’s SafetyNet API with the Play Integrity API for device integrity checks. This is a historical change to the checking method, not an additional MTD policy component or an equivalent of a particular compliance rule. It proves neither a successful integrity check on the specific device nor authorization for enrollment or access; assess the compliance policy and actual device findings separately.

Limited acceptance testing and fallback

Beforehand: document the approved small pilot group and an accessible test device for each Android mode actually intended for use; the policy version, IXM registration, scan/permission status, most recent results, allowed and blocked test pages, business browser/app dependencies and an independent communication channel. For work-profile devices, do not define successful web filtering as a test objective; do not roll out Web Filtering there as effective protection.
After assignment: wait for the next connection/synchronisation, check the policy and app configuration on the device, and observe functionality separately. For Web Filtering, open only approved, harmless Web Security & Control test pages; the examples contain harmless content despite their test classification. Compare access to allowed and blocked web destinations, Accessibility status and Wi-Fi checks on a known network. Check antivirus scan status and the most recent results separately; do not use real malware for testing. Under Create events, check only expected Web Filtering test events; do not equate scan task status with scan results. Successful assignment is not proof of effectiveness. A classification service reachable from the administrator’s computer does not prove that IXM can reach it from the intended device network either; check the device case in the approved pilot and do not deliberately cause a production outage.
If legitimate content is blocked or protection fails: stop expansion, safeguard affected devices and dependencies, and narrow down the cause: is the service reachable? Is Accessibility still permitted? Does the problem concern an exception, the scan-exclusion group or the entire policy? Remove a new exception introduced during the pilot or restore the previous list; for group changes, restore the original limited target group. If necessary, deliberately restore only a policy version verified for the incident at hand, or assign an alternative that has already been tested. If the classification service is unavailable, the fallback policy must not also enable Web Filtering with the same unreachable service dependency; without an accessible, approved recovery path, make no further changes and escalate through the independent communication channel. Do not blindly “uninstall” an MTD policy as though it were an Android device policy, or remove the IXM app: changed MTD settings are synchronised at the next connection; the recovery path is a targeted policy change or assignment of a verified alternative policy, not the MDM uninstall action. On the same test device, after its next connection to Sophos Mobile, recheck the policy actually applied, app/permission status, access to permitted business destinations, protection function and events. Do not disable filter permissions or conduct an uncontrolled test with * or a global allowlist.

Outstanding before approval: The specific licence, admin role, supported Android versions, MDM/app mode, data-protection approvals for scanning and location, actual Accessibility and service availability, effects of exceptions, group targeting and recovery path in the customer tenant have not been tested. The MTD policy owner does not replace the separate assignment/registration guidance, an iOS web-filter policy or an Android Enterprise MDM policy. Before a production assignment, the licence, policy effectiveness and recovery path must be verified on the approved test device; do not roll out without that evidence.