Assess Sophos Mobile Web Filtering safely on iPhone and iPad

Do not assign broadly without testing: The iOS Web Filtering configuration in a Mobile Threat Defense policy controls web filtering in Sophos Intercept X for Mobile. The full Sophos Mobile administrator guide explicitly limits this configuration to supervised devices. The Threat Defense edition omits that restriction. This discrepancy in the documentation is not an explicit authorization for device-wide filtering on unsupervised devices, but neither does it establish that Intercept X cannot filter on those devices at all. Before making a change, verify the license, management mode, iOS/iPadOS version, profile status, actual device or app scope, and effective filtering in the target tenant on a test device.

This is a guide to assessing policy effects, not instructions for enrolling the app, deploying an iOS profile, or setting up a particular DNS, VPN, or Network Extension method. A visible policy, an app tile, or a user-facing toggle alone does not prove that filtering is active on the target device.

Define the scope before making changes

Sophos describes MTD web filtering as covering access through Safari and other browsers as well as connections from apps. System and third-party apps, or external resources used by a website, can also depend on a blocked domain. Treat this broad reach as something to test only on a suitable device that is actually being filtered; it is not evidence that every iPhone in your fleet is covered.

For unsupervised devices running iOS 16 or later, or iPadOS 16.1 or later, Sophos documents a separate assignment path for the web content filter of individual managed apps. In the app settings, the Web Filtering function of the same installed and managed Sophos Intercept X app can be selected for that app instead of a Web content filter policy configuration. This establishes neither device-wide MTD assignment nor coverage of Safari or other apps on an unsupervised device. Identify the specific management path and affected app scope before interpreting test results. Compatibility with other filters or VPN connections is not established here.

The MTD feature requires an appropriate Sophos Mobile or Sophos Mobile Threat Defense license and a managed Intercept X for Mobile app. The user-facing Turn on Web Filtering toggle is on the Intercept X Settings page in the app, not in iOS Settings. It belongs to the feature that blocks connections to malicious websites or websites filtered by category. The organization must enable Web Filtering; the user-facing toggle does not replace this prerequisite. Sophos also describes an iOS configuration profile for web filtering. Check that the profile is actually assigned, installed, and active on the pilot device; neither app installation nor the Turn on Web Filtering toggle establishes this. For manually downloaded profiles, the iOS help gives an eight-minute installation window; Profile Installation Failed can indicate that profile support is missing. This does not establish a general profile deployment procedure.

Test exceptions and blocks with a small pilot group

In the MTD policy, Filter malicious websites, Filter websites by category, Create events, and Website exceptions are separate decisions. The two exception lists are called Allowed domains and Blocked domains. Put each entry on its own line; Sophos allows IPv4/IPv6 addresses and subnets, domains, and wildcard domains. Do not use a protocol prefix such as https://. A wildcard character must be at the start of an entry: *.example.com is a format example, not a recommendation to allow that domain. A single line containing * in Blocked domains blocks all websites. Before applying such a rule, verify the necessary exceptions and their actual effect; even a narrower block can break apps or embedded resources.

Website categories are based on SophosLabs data, which is continually updated. For the pilot assessment, this means that a category assignment observed earlier is not a permanent guarantee. Recheck the expected category behavior during the current pilot or before making another change.

Each of the two fields Allowed domains and Blocked domains in the MTD Web Filtering policy has a documented limit of 5,000 entries and 130,000 characters. Both limits must be observed per field, not as a shared allowance for both lists. These field limits apply to the policy lists; they do not specify the capacity of the personal Allow list or Block list. Before assignment, check the list size and the entries actually saved in the target tenant. How an exceeded limit is handled—for example, by rejection or truncation—has not been tested here; no particular API error message is guaranteed either.

When rules overlap, precedence is:

1. Policy Allowed domains: allow.
2. Policy Blocked domains: block.
3. User Allow list: allow.
4. User Block list: block.
5. Blocked category: block.

A policy allow entry can therefore take precedence over a blanket policy block; a user allow entry cannot override a policy block. For example, with * blocked, a required domain explicitly listed under Allowed domains may be exempt under normal rule evaluation in this order. This is not a guaranteed bypass when classification is unavailable or for the always-blocked category of serious criminal content, and it is not a reliable recovery method. Test each browser, affected app, and specific Intercept X version: version 9.7.10 was the first to fix a bug that blocked websites in Microsoft Edge despite an entry in Allowed domains and * in Blocked domains. Seeing an entry in a list alone does not prove the exception works.

Sophos uses https://4.sophosxl.net/lookup for classification; the current Sophos network connections list specifies HTTPS (443) as required access for iPhone and iPad. DNS resolution of this name alone does not prove that Web Filtering can establish the HTTPS connection. According to both administrator guides, if Web Filtering cannot reach this service, it blocks all websites; an entry in Allowed domains is not guaranteed as an exception in that situation. Before assigning the pilot policy, check reachability from the intended device networks and plan an authorized alternative administration and recovery path; do not deliberately trigger an outage on the production network. Sudden widespread blocking may indicate a lost classification connection rather than successful enforcement of the selected categories. Whether or when removing a policy or profile restores access must first be tested on a pilot device.

Observe the effect and the recovery path

For a limited pilot, first record the existing state, target devices, and responsible people. Then, on a suitable iPhone or iPad, check the policy actually assigned, app and profile status, and applicable management mode. Using harmless test destinations, check an expected allow, a targeted block, and, where relevant, a category warning—in Safari and another browser, as well as through an affected app connection. Also watch business-critical system functions and embedded page resources. Create events can make blocked or additionally warned access visible on the device details page; the event setting is separate from the filtering decision. According to the Sophos Mobile release notes for version 2023.10 (March 13, 2023), iOS connections to Apple servers at the operating-system level are ignored for Web Filtering events: the absence of such events proves neither that access is allowed nor that classification is reachable. A page load or an app tile alone is not proof of success.

For category checks, Web Security & Control Tests provides example pages and explanations of the categories. According to the administrator guide, the content of the category test pages described there is harmless, even when their classification is offensive or dangerous. Before opening a page, select a currently appropriate web/category test by checking its description and product and platform details; the catalog alone does not establish suitability for iOS MTD. On the approved pilot device, record the test destination, time, expected allow, block, or warning, and the result actually observed. Other catalog entries, such as malware test downloads, are not evidence of iOS category filtering; do not download test files or visit genuinely harmful sites for this check.

If unexpected blocking occurs, do not add ever-broader allow entries on speculation. First investigate device scope, list precedence, profile status, app version, and the classification connection. Stop further assignments; have an authorized person carefully revert the previously documented policy assignment or exception configuration for the pilot devices, then check whether the original access has returned. Reverting does not erase events already generated and does not prove that every affected app connection will recover immediately. Do not roll out broadly without a confirmed recovery path.

Increased battery usage with Web Filtering active

For Sophos Intercept X for Mobile for iOS, version 9.7.13, the Sophos release notes document a fix under SMSECIOS-2055 for a bug where Web Filtering caused increased battery usage. This is a specific troubleshooting lead, not proof that every increase in battery usage is caused by the web filter or that an update will resolve it on every device.

For this symptom, first record the installed Intercept X version, iOS/iPadOS version, the filter actually active, and when the increased usage occurred. Compare the installed app version with the fix documented here in 9.7.13 / SMSECIOS-2055 and check whether an app update approved by the organization is available for the device in the App Store. The release notes establish neither the version installed on the device nor the version available in its store region. After an approved update on the pilot device, observe battery usage again under comparable use and recheck expected allows and blocks. If the symptom persists, provide the version details and observations to the responsible IT team or Sophos Support; do not disable the filter broadly on speculation. This does not guarantee a particular battery life or a successful fix on your own device.

Consider the user interface and privacy separately

From the iOS app dashboard, open Network security > Web Filtering. Personal exceptions can be added from a relevant warning, reviewed in the app, and removed:

1. Add an exception: Swipe down on the Web request blocked notification. Tap Add to allow list for a personal allow entry, or Add to block list for an additional personal block. An allow entry suppresses a protection warning; if the classification is unclear, first check with the responsible IT team whether the exception is acceptable.
2. Review entries: Under Web Filtering, Allow list shows the number of allowed pages, and Block list shows the number of blocked pages. Tap the respective counter to open all entries in that list. Your own entries and entries set by the organization appear in separate sections. Before making a change, check who owns the entry; the count alone does not prove that an allow or block is effective.
3. Remove your own entry: In the relevant list, swipe left on an entry you added yourself to delete it. This is possible only for your own entries, not those set by the organization. After removal, use a harmless test destination to check which applicable rules take effect again; the consequences for allow entries and additional blocks are described separately below.

This interface neither changes the precedence of policy entries nor, by itself, confirms the scope of filtering on the device.

An entry a user adds to their own Allow list can suppress the documented warning for certain pages classified as malicious or assigned to a category for as long as the entry remains. Removing that entry removes the user-level exception: the page is once again filtered according to the applicable rules. This neither determines which warning or block will follow nor guarantees that the change will take effect immediately on the device.

An entry a user adds to their own Block list keeps a previously warned page blocked for as long as the entry remains and takes effect under the order described above: policy lists take precedence over user lists, and allow entries take precedence over block entries within each level. A user block therefore overrides neither a policy allow entry nor the user’s own allow entry. Removing the user’s block entry removes this additional user-level block; the underlying warning may reappear if the applicable rules call for it and no other rule blocks the page. Both list changes apply only to entries users added themselves, not to settings imposed by the organization. They provide no general bypass when classification is unavailable or for the always-blocked category of serious criminal content, and they do not guarantee immediate restoration of access.

When Create events is enabled, warnings and blocks may be visible in device details. While Web Filtering is on, Sophos always blocks websites in the category of particularly serious criminal content; URLs in that category are masked in logs, events, and reports. This does not imply that all URLs are masked. Separate Network logging can collect metadata such as URLs, times, and data volumes for a managed app, but not transmitted content. According to the iOS release notes, uploading network logs to the Sophos Data Lake requires management and administrator enablement. Web filtering events, network logging, Data Lake uploads, and Data tracking are distinct features. Data tracking on the app’s Intercept X Settings page allows Sophos to collect anonymous usage data to improve the app. This permission is distinct from network metadata and support log files; it does not imply that those other logs are anonymized. Before production use, determine visibility, permissions, notice to affected people, and retention separately for your tenant; these help pages do not establish a binding retention period.