Roll out Sophos Chrome Security safely on ChromeOS

Sophos Chrome Security is a Chrome extension that registers with Sophos Mobile. This is not Android Enterprise MDM enrollment, nor is it the Sophos Firewall extension Sophos Chromebook User ID for Chromebook SSO. Google Admin distributes the extension and connection code to users; Sophos Mobile manages the registered extension and its Chrome Security policy. Record the responsibilities of both administration systems separately before making changes.

Define prerequisites and scope

Check the permissions and license for Sophos Mobile or Sophos Mobile Threat Defense in the tenant being used, along with the available Chrome features. The two editions’ manuals do not list exactly the same tasks: Locate device appears in the Mobile manual but not in the Threat Defense edition’s task list. Do not infer feature availability from the extension’s name.
A Sophos Mobile Device Management license alone does not include Sophos Chrome Security; the required entitlement is Sophos Mobile Threat Defense (formerly Intercept X for Mobile) or Sophos Mobile (formerly Central Mobile Advanced). Check the active tenant license separately from any Google ChromeOS Enterprise Upgrade. Also distinguish the Google account type from the device upgrade: enrolling a device with a bundled ChromeOS Enterprise Upgrade does not give an organization with an Education account access to Chrome features reserved for Enterprise accounts.
Automatic enrollment requires Google Workspace, access to Google Admin > Devices > Chrome > Apps & extensions > Users & browsers, and a controlled user OU. For manual enrollment, the user installs the extension and enters the enrollment token from the device wizard or Self Service Portal. Do not mix up these two paths.
Decide in advance which user OU in Google Admin receives the extension, which device group in Sophos Mobile receives the registered objects, which Chrome Security policy is assigned, and which Owner setting applies: Corporate here means the organization owns the devices; Personal means the organization owns the users. The Google OU target is not the Sophos device group; do not interpret this Owner choice as an Android Enterprise management mode or a blanket BYOD classification.
Clarify the device type: a Chrome Enterprise device has the Chrome Enterprise Upgrade. Only enroll on Chrome Enterprise devices restricts automatic enrollment accordingly. On the first automatic enrollment of a Chrome Enterprise device, Sophos Mobile creates a device object and uses its serial number as the device name. Shared Chrome Enterprise devices retain this one object: when another user signs in, Sophos Mobile removes the previous user association and assigns the new user. On other devices without the Chrome Enterprise Upgrade, by contrast, Sophos Mobile creates a device object the first time each user signs in to that device if Sophos Chrome Security automatically enrolls at that point. A shared device therefore gets one Sophos device object per user, not another object every time the same user signs in again. Verify these expected inventory entries and associations during the pilot before assessing inventory or licenses; do not extrapolate the serial-number device name to other device types.
Document existing Google extension policies, the Sophos policy, and business-critical sites that must remain accessible. Have a test user and a device with a working alternative means of access ready. Deployment to the entire root OU is not a pilot.

Check the Sophos Mobile management connection before the pilot: In addition to FCM and web classification, all managed devices require the regional Sophos Mobile server over HTTPS 443. Determine the actual Sophos Fusion tenant region; do not infer it from the device’s location: open My Products > Mobile in the console and read the host in the browser address bar. In smc-user-if-cloudstation-<region>.prod.hydra.sophos.com, the region lies between smc-user-if-cloudstation- and .prod.hydra.sophos.com, for example eu-west-1. This smc-user-if host is used to discover the console region; it is not the smc-device-if destination for devices. The destination is smc-device-if-cloudstation-<region>.prod.hydra.sophos.com; replace <region> with eu-central-1, eu-west-1, us-west-2, or us-east-2 according to that tenant, rather than allowing all regions indiscriminately. With the network administrators, check DNS resolution and HTTPS/TLS reachability of this destination from the actual pilot device network; if a check fails, inspect firewall/proxy logs for that exact host and port. A successful connection alone confirms neither enrollment nor policy application. The FCM and classification connections below are separate additional requirements.

Check Chromebook network paths before the pilot: Google Firebase Cloud Messaging (FCM) on Chromebooks requires all IP blocks in Google’s ASN 15169 and ports 5228-5230. Avanet recommends assigning maintenance of a dedicated FCM address object to the network administrators: before the first allowance, obtain the currently announced IPv4/IPv6 prefixes for ASN 15169 from an up-to-date ASN routing directory and record the source, retrieval date and complete prefix list in the change record. Because ranges change frequently, repeat this at least monthly and when troubleshooting FCM failures, compare with the approved list, and implement reviewed additions or removals with approval. Do not use only the currently resolved IP addresses of individual Google hosts or widen the allowance to arbitrary ports. After each change, check FCM from the pilot device network and the corresponding firewall/proxy logs; if it fails, roll back that specific change and check again. Sophos Chrome Security Web Filtering also requires the Sophos classification service 4.sophosxl.net/lookup over HTTPS 443. Push and web classification use different connections; check both actual device paths with the network administrators. An allowed connection proves neither enrollment nor policy or filter effectiveness; the following pilot checks are still required.

Put dated lookup-usage figures in context: For devices with Sophos Chrome Security installed, the Sophos Sizing Considerations dated April 14, 2022 give approximately 800 Bytes per web-page lookup against the SophosLabs database. This is a dated estimate from documentation for a single lookup, not for downloading a complete web page, and is neither a daily or device budget nor a tested upper limit. Check actual traffic under the intended browser, policy and network conditions in an approved pilot; reachability and filter effectiveness remain separate checks.

Automatic enrollment in a pilot OU

In Sophos Fusion > My Products > Mobile > Setup > Google setup > Google Workspace, click Generate connection code. Deliberately choose Owner according to whether the organization owns the devices (Corporate) or users (Personal), the Sophos Device group, optionally the Chrome Security policy, and, if applicable, Only enroll on Chrome Enterprise devices; record the settings and previous assignment before saving. Then click Save and, next to Connection code, click Copy to copy the value to the clipboard.
Pass the code only through the intended administrative channel to the person responsible for Google Admin. Sign in to the Google Admin console with the Google Workspace account. In Google Admin, under Devices > Chrome > Apps & extensions > Users & browsers, expand the Organizational Units side panel and select the pilot user OU; check the assigned OU again before saving. OU selection is optional according to the product documentation; here it deliberately limits the pilot to the intended users.
Hover over the + button at the bottom right and click Add from Chrome Web Store. Enter Sophos Chrome Security in the search field and click the extension to open its store page; do not select Sophos Chromebook User ID. Click Select at the top right. Paste the connection code under Policy for extensions. Under Installation policy, select Force install or Force install + pin to browser toolbar. Both options force installation and prevent users from removing the extension themselves; the second also pins it to the Chrome toolbar.
Sign in to the pilot ChromeOS device as a user in that OU. Verify that the extension actually installs and registers, and check the Sophos device group. During automatic enrollment, Sophos Mobile creates one Sophos user per Google Workspace user for both Chrome Enterprise devices and other devices, and assigns that user to the respective device object. Distinguish this user creation from the device creation and changes in user association described above. In the pilot, use a second user and then sign in again as the first user to check and document user creation, device objects, and associations against the expectations described. This is a required pilot check, not a device test already performed. Separately, for manual enrollment: in the Sophos device details, system_user_account may show the Google user signing in; the manually assigned Sophos person need not be the same person.
Include more user OUs only after confirming policy application and documenting a filter test and rollback test. Changes to automatic enrollment settings apply to all users of Chrome Enterprise devices at their next sign-in; according to the documentation, on other devices they apply only when a new user signs in to the device. Test revocation or replacement of the connection code separately; do not infer from it that existing devices have been updated. Do not assume an immediate update of already enrolled devices.

Test the Chrome Security web filter safely

The Chrome Security policy in Sophos Mobile configures the already registered extension; Google’s Policy for extensions, by contrast, carries the connection code. First test the web filter with a small Sophos device group and a pilot user OU. Check Filter malicious websites and each category under Filter websites by category individually for its intended effect. For category tests on the pilot device, open a suitable harmless example page from the Web Security & Control Tests, such as the Gambling test page. Before opening it, compare the category shown there with the current policy and record the expected result; categorization data is continually updated. Use only the categorized example pages, do not download test files, and do not visit real harmful or illegal sites. Under Create events, choose between events only for blocked sites and also for sites that trigger a warning; the absence of a warning event in the “blocked only” mode does not establish that filtering has failed. Compare the selected setting and events in the device details with what you observe in the browser. When enabled, Check embedded content also checks embedded resources such as advertisements, which can cause an entire page to be blocked. When disabled, embedded content is ignored except for malicious content: this does not turn off checks for malicious embedded content. Test the two options separately during the pilot without presenting documented behavior as a verified result on a device.

Exceptions and precedence: Put each entry in Allowed domains and Blocked domains on its own line, without https:// or chrome://; supported entries include domain names, IPv4/IPv6 addresses, networks, and leading wildcards. Valid syntax examples are *.example.com and the alternative notation *example.com; for chrome://bookmarks, the entry is bookmarks. These are syntax examples, not a recommendation to block bookmarks. An allowed domain takes precedence over a blocked domain in ordinary list evaluation. Policy lists take precedence over user lists. This is not a universal allow rule: According to the documentation, when Web Filtering is enabled, Sophos always blocks sites in the category of particularly serious criminal activity; their URLs are masked in events, logs, and reports. Do not plan to use an Allowed domains exception to bypass that block. A domain rule is not automatically resolved into a corresponding IP rule.

The manuals document different decision sequences, not demonstrably different product behavior:

Sophos Mobile (four steps): 1. Policy Allowed domains allow; 2. policy Blocked domains block; 3. the user allow list allows; 4. a forbidden category blocks. This sequence does not explicitly mention a user block list or the decision for an allowed category.
Sophos Mobile Threat Defense (five steps): 1. Policy Allowed domains allow; 2. policy Blocked domains block; 3. the user allow list allows; 4. the user block list blocks; 5. the category determines whether to allow or block.

Conflict to test in the pilot: A URL blocked only by a user, in an otherwise allowed category, is explicitly blocked in the Threat Defense sequence; no outcome can be inferred for it from the four-step Mobile sequence. With the edition actually licensed and the policy assigned, check the browser outcome and configured events using a harmless test site. Only then establish precedence and a rollback path for this case; the difference between the manuals alone proves neither that the URL is allowed nor that device behavior differs.

Do not set a blanket block without a recovery path: A single * in Blocked domains blocks all websites. Even *.example.com can affect third-party apps, system apps, or required page resources. Identify required sign-in, update, and business destinations before applying a block. First test targeted exceptions and both blocked and allowed test pages on the pilot device; after each change, recheck the effective policy, application behavior, and events. If a required application stops working, undo the last changed block in the Sophos Chrome Security policy or reassign the documented previous policy before more users are affected. Do not “fix” the filter by deleting all security policies or removing the extension.

Tamper protection and troubleshooting

The Tamper Protection mechanism for the Chrome Security policy is active even without an additional compliance action. If Sophos Mobile detects tampering, it reapplies the original policy. Additional responses belong in a Compliance policy for Chrome OS with the Tamper protection turned off rule. Avanet recommends configuring alerts only at first, in an approved pilot. This is a safety recommendation, not a product default. Publish intended policy changes through the authorized Sophos administration team and verify that they have been applied, rather than modifying the policy locally on the device. Even an intentional local change falls under tamper protection: if Sophos Mobile detects the change on the device, it reapplies the original policy and carries out the configured compliance actions. The intent of the person making the change does not create an exception to tamper protection.

Configure and read back additional Chrome alerts

The compliance policy guide covers the complete creation and group-assignment workflow. For this Chrome task, compare the following values before making changes and after saving:

Record the tenant, licensed edition, permission to make changes, and approved pilot devices. On the registered Chrome device object, read its exact identity, Sophos device group, and Owner. The Google user OU limits extension distribution, not compliance assignment. Document the previous compliance policy, every group using that policy, the previous Enable platform state for Chrome OS, the tamper rule and its actions, and both corporate/personal group fields. Also record the name, version, configuration, and assignment of the previous Chrome Security policy, together with the actual device state.
Create a new, isolated compliance policy for the approved pilot using the linked guide. On the Chrome OS tab, select Enable platform and choose Tamper protection turned off under Rule. Select Create alert for this rule. Before Save, review all inherited rules and actions, including those on other enabled platforms; PCI/HIPAA templates are not free of actions. Then reopen the saved policy and read back the platform activation, rule, and action. The checkbox enables compliance evaluation, not the already active tamper protection.
Under Device groups > [actual Sophos group] > Compliance policies, assign the pilot policy to the corporate or personal field matching the Owner you read. Check the other field against the approved intended value rather than replacing it without review. After Save, compare both Compliance policy (corporate) and Compliance policy (personal) columns again in Device groups. Include any existing Default group when checking the scope.
On the exact Chrome device object, compare the assigned Chrome Security policy with the intended value. After connection and synchronization, check the settings actually in effect on the device; a name, version, or refreshed console view alone does not prove a device effect. The separate policy assignment and rollback workflow explains this check. For an observed tamper-rule violation, compare compliance status, the violated rule, and the time with the saved action. In Sophos Mobile Threat Defense, check the alert under Alerts in Sophos Fusion; in the full Sophos Mobile edition, also check the event on the device detail page and the alert. A missing alert proves neither a protection failure nor successful tamper detection.

Compliance policies > Check now checks all enrolled devices and executes the configured actions. The button is not limited to the Chrome pilot group or the Google OU. A Chrome pilot using Create alert does not make other devices’ actions safe. Before a global check, inventory all affected groups, policies, enabled platforms, rules, and actions, and obtain separate approval for the global change. This guide authorizes neither clicking the button nor an intentional tamper test. The checks described are a workflow, not a tenant or device test that has been performed; they promise no detection or recovery time.

Clarify task-bundle responses by edition

The older Chrome tamper guide, with the displayed date April 14, 2022, lists alerts or transfer of a task bundle. By contrast, the Threat Defense compliance-creation guide dated September 9, 2026 describes only Create alert; the full edition’s guide dated May 21, 2024 explicitly lists Transfer task bundle. This documentation difference proves neither removal of the feature nor its availability in your Threat Defense tenant. These are manual dates, not verified introduction dates. Before using a transfer response, check actual availability in the licensed edition and obtain separate approval for permissions, target devices, task order, side effects, and rollback. The task bundle guide covers its own creation and transfer workflow; do not apply its Android/iOS click sequence to Chrome.

If enrollment or policy synchronization fails, recheck the tenant region and Sophos Mobile host identified above, and check DNS resolution and HTTPS/TLS reachability over 443 from the affected device network. Inspect firewall/proxy logs for the specific destination; a working FCM or classification path does not replace this management connection. After an approved, targeted network correction, check enrollment and policy application again without indiscriminately disabling protection mechanisms.

If messages, tasks, or log retrievals fail to reach the Chromebook, check whether ChromeOS allows notifications for Sophos Chrome Security. Disabled notifications can prevent these tasks even while periodic or user-initiated synchronization and web-filter events continue to work. Then check OU assignment, extension installation, registration, assigned Sophos device group, and policy separately; successful synchronization alone does not prove successful task delivery. For pending or partially executed tasks, use the task and synchronization diagnostics for read-only status checks and, if needed, the approved Chrome log export.

Stop or roll back the rollout

For the additional compliance response, obtain approval and use the same central settings paths to restore and save the recorded previous compliance policy, Chrome OS > Enable platform, tamper rule and actions, and both corporate/personal group assignments. Then read back the saved platform, rule, and action values and both assignment columns, and check the state of the affected Chrome device object. This rollback changes the configuration of future responses; it does not undo tasks already executed.

For an Assign policy task already executed, centrally correct or reassign the previous Chrome Security policy. The task assigns policies silently, without user action. After connection and synchronization, recheck the assignment and actual device effect. Unenroll unenrolls Chrome devices without user confirmation; restoring the compliance values does not automatically restore either the unenrolled object or its enrollment. For completed or partially executed tasks, first preserve the evidence from task diagnostics and separately authorize any required recovery or re-enrollment. Neither local policy changes nor revoking the connection code is a rollback path for the tamper response. Google-side forced installation and offboarding remain separate changes.

Google-managed ChromeOS device deprovisioning under Google Admin > Devices > Chrome > Devices is not Sophos extension unenrollment or connection-code revocation. Google removes device policies; the administrator explicitly chooses whether to factory-reset the device (which removes local user profiles and data) or keep existing data and profiles. A bundled ChromeOS Enterprise Upgrade remains bound to the device for its lifetime and cannot be transferred to a different device. Re-enrolling that same device in another organization is possible only if the previous organization has successfully deprovisioned it, the destination organization has confirmed its eligibility for enrollment, and no Google policy blocks the move; check the policy status in advance, including any forced re-enrollment with the previous account. If data was kept at deprovisioning, Google requires a device wipe before re-enrollment; back up needed local data first. Standalone upgrades have different reassignment and expiry rules, and an expired subscription can leave a device suspended. Check the actual upgrade and subscription status before retirement, and reconcile Google and Sophos device records separately.

Before any Google deprovision action, confirm the Chrome administrator privilege, exact device identity and status, upgrade type, selected devices and the reason where required; choose explicitly between factory reset and keeping data. Keep the device online so the change can reach it. If this is the organization’s only bundled device and there are no other upgrades, Google’s documentation warns that configured settings and managed devices are removed from its system after 90 days. A deprovisioned device remains in its Google OU even though device management ends: check the Google record and the separate Sophos extension registration rather than treating an OU entry or Google deprovision as proof of Sophos unenrollment. Hold any production deprovision until the Google and Sophos administrators have approved the data, license and re-enrollment consequences.

If there is a filter problem, first revert the most recently changed filter rule or policy assignment for the pilot device group and verify on the test device that previously allowed access and protection are restored. Leave the Google OU and extension unchanged initially so the corrected policy can reach the device.

Revoking the connection code stops future automatic enrollment for the entire Google Workspace account, not just for the pilot user OU. Before revoking it, verify the Google Workspace account and Sophos tenant with the responsible Google and Sophos administrators, and obtain explicit approval to stop enrollment account-wide. To stop only future automatic enrollment, select Setup > Google setup > Google Workspace > Revoke connection code in Sophos Mobile and click Yes in the confirmation dialog. This step does not remove the extension or already registered ChromeOS devices. To re-enable automatic enrollment, generate a new connection code and update it under Policy for extensions for the intended OU in Google Admin; verify sign-in and registration with a new pilot user. Do not treat old Sophos device objects as proof of successful new enrollment.

Fully removing existing devices or the Google-enforced extension is a separate offboarding process: inventory affected users and existing Sophos device associations first, coordinate the responsible Google and Sophos administrators, and assess the consequences for protection and events. Revoking a code alone is not a substitute; do not trigger a broad uninstall or device cleanup without a tested rollback path.