Set up Android Enterprise in Sophos Mobile and enroll devices safely

Short answer: For MDM enrollment, the organization needs an appropriate Sophos Mobile Device Management or Sophos Mobile license, an Android Enterprise registration connected to Sophos Mobile, and a policy/task bundle suited to the intended device type. Sophos Mobile Threat Defense alone does not entitle you to the MDM management described here. With Full Device, Sophos Mobile can manage the entire device; with the Android Enterprise work profile on a verified personal device (BYOD) described here, it manages only the work profile. Company ownership does not prove Full Device management, and a work-profile policy does not make a company device fully managed. Before any enrollment, establish ownership, the actual mode, existing data, Google identity, and the authorized exit path. This guide does not authorize a fleet migration or reset.

For edition selection and license counting before the pilot, see Sophos Mobile licensing; actual entitlement in your own tenant still needs to be verified.

Preflight: which path can this device take?

New or reset company device — full management approved. Use Android Enterprise full device with an Android Enterprise device policy. Full Device enrollment is possible only before initial setup or after a factory reset; unenrollment later also requires a factory reset. Do not wipe existing device data with a reset without a verified backup.

Full Device enrollment does not require a personal Google account. By default, only apps approved in Managed Google Play are available; the Google Play configuration can allow access to all Play Store apps. Initially, only a minimum set of apps is enabled: Google Play Store, Contacts, Messages and Phone. Do not mistake missing preinstalled apps for failed enrollment. Managed apps can be installed, removed, or updated without user interaction; runtime permissions and supported app configurations are controlled through the appropriate policy. Check the actual app inventory and required approvals in the pilot.

Personal device — work data only. Use Android Enterprise work profile with an Android Enterprise work profile policy. This is not full-device management: do not treat a Full-Device-Wipe as the exit path. Removing the work profile deletes its apps and data; private data outside it is not part of this management path.

Consent, setup, and removal on personal devices are covered in the Android BYOD guide; it does not apply to company devices with a work profile.

Company device intended for a work profile, or unclear classification — stop. The work-profile path described here applies to BYOD, not to a separate organization-owned work-profile provisioning path with different reset and offboarding consequences. Do not classify a device as Full Device or BYOD based on ownership or policy name alone. Verify the device and OEM mode and the enrollment supported for this tenant separately first, and obtain authorization. Company devices with a work profile (COPE) are excluded from the following BYOD statements about profile removal, recovery, and offboarding.

Already managed in device administrator mode — plan migration separately. Do not simply start a new Enterprise enrollment over it. This obsolete mode is available only for Android 9 or earlier and is not permitted on Android 10 or later. Check the existing device and its backup; prepare a separate migration plan using the Device Administrator migration guide. It treats legacy unenrolment and company-device reset separately; this handoff does not authorise a reset or replace removal confirmed on the device.

Userless company/kiosk device — separate provisioning path. It can be provisioned as a fully managed Android Enterprise device with QR or Zero-touch. For organizations registered in managed Google domain mode before April 9, 2024, Use managed Google domain device enrollment must first be enabled; do not start this path without that switch. A userless QR package contains Assign policy for an Android Enterprise device policy, but no Enroll task. Do not assign an email address during enrollment. Kiosk/provisioning configuration is a separate workflow, not the standard user package. A Dedicated device is created by applying a Kiosk mode configuration to a fully managed device and is restricted to one app or a selection of apps.

For userless QR enrollment, use Setup > Google setup > QR code enrollment (user-less). For Zero-touch, User authentication on the Zero-touch tab determines enrollment with or without a user. Although no email address is linked and no Sophos Mobile user is assigned, Google creates an account internally. Under Internal properties, its ID is named android.enterprise.bte.userless-device.account-id for managed Google domain and afw_play_emm_managed_device_account_user_id for Managed Google Play Account. This ID does not prove assignment to a personal user; a user can be assigned separately later if needed. Provider assignment, QR creation, and physical setup must be established in your own provisioning workflow before deployment. Use the dedicated Android device guide for this preparation: it separates QR, Zero-touch and KME and describes the authorised QR pilot. The unresolved mapping of the Sophos KME profile to the current Samsung interface remains a stop before executable KME profile creation; neither this link nor a successful QR setup confirms KME, a reset or physical kiosk exit.

KME prerequisite: reconcile the device inventory between customer and reseller

For Knox Mobile Enrollment (KME), preparation starts before profile assignment: the customer’s IT administration and the reseller must be referring to the same organization and the same purchased devices. The following explanation covers this initial handoff, not the creation of a KME profile in the current Samsung interface.

Exchange and verify identities: The IT administration gives the reseller the Knox Customer ID of the intended customer organization; the reseller gives IT its Reseller ID. This must be a trusted, Samsung-approved reseller in the Knox Deployment Program. Before approving this relationship, cross-check both IDs and their associated organizations: an incorrect customer ID would assign the device handoff to the wrong customer’s inventory. These IDs are neither Google login credentials nor the Knox license key described separately.
Upload and share purchased devices: After purchase, the reseller uploads the list of purchased device IDs to the Knox Reseller Portal. These device IDs are shared between the reseller portal and KME and form the initial device inventory for the customer console. The upload is not yet a Sophos enrollment. Verification includes checking the correct customer organization and matching device identities against the order, delivery and internal inventory; clarify missing or unfamiliar devices with the reseller first, rather than bypassing the discrepancy by assigning a profile.
Separate notification from customer approval: The IT administration receives an email notification about the device upload and approves the upload on the customer side. The message reports the upload but does not replace approval. Before granting this approval, check the Customer ID, reseller association and reported device IDs again against the intended inventory. Only a correctly associated and accepted device inventory provides the basis for later profile assignment; this does not yet mean that a device has been successfully set up.

Automatic upload and automatic approval are separate decisions: Auto-upload concerns automatically uploading device data; Auto-approval concerns the customer’s automatic acceptance of uploads from the trusted reseller. One setting must not be inferred from the other. Automatic profile assignment is also a separate decision, not an inevitable consequence of an upload or its approval. Avanet recommends authorizing each intended automation separately for the named reseller and customer inventory and checking the settings actually in effect. Without explicitly confirmed automatic approval, do not treat manual customer approval as complete. Even with authorized automation, the customer ID, device identities and accepted inventory must still be reconciled before profile assignment; if there are discrepancies, stop and involve the responsible IT administration and the reseller. This explanation assumes neither current controls nor default values for these settings.

The KME handoff does not lift any operational hold: The verified inventory alone confirms neither the mapping of the Sophos KME profile to the current Samsung interface nor the management mode on the device. The provisioning guide linked above and its stop before executable KME profile creation remain unchanged. Profile assignment and subsequent completion of enrollment by device users are downstream steps; their outcome must be checked separately in Sophos Mobile and on the device. These prerequisites authorize neither a reset, release by the provider nor physical kiosk exit.

The Android tab under Setup > Google setup contains the mode selection Management mode > Android Enterprise > Save; this choice also controls which policy types appear in the interface. Sophos Mobile Threat Defense, by contrast, does not provide entitlement to this MDM mode selection; hosting the Intercept X app is a separate task. The Android Enterprise tab and Samsung Knox license tab serve different purposes again: account connection/FRP and, respectively, an optional Samsung Knox Premium license for the Knox container (key types KPE Premium or KLM Workspace). A Knox license key is neither required for every Android Enterprise device nor a Knox Mobile Enrollment assignment. Enter a key under Setup > Google setup > Samsung Knox license only when actually entitled to it, and select Save; check dependent devices/containers before Remove. Remove deregisters the key, not a KME provider assignment.

Scope of these settings: Host Sophos apps on your web server and Set synchronization interval (Android) on the Android tab are separate tasks; this article does not provide instructions for app hosting or setting the synchronization interval. On the Android Enterprise tab, Configure email placeholder is another separate task alongside setup and FRP. Checking the enrollment email in this article does not replace configuration of that placeholder. Hosting Intercept X in the Threat Defense edition is also outside this workflow.

Check Android push connectivity before the pilot: For Google Firebase Cloud Messaging (FCM), allow connections outbound from the Android device to Google over TCP 5228-5230; Sophos specifies all IP blocks in Google’s ASN 15169 for this. Google also specifies TCP 443 for Android FCM. This is not inbound port forwarding to the device. For IP-based filtering, retrieve the current Google IP range list as live JSON: prefixes contains ipv4Prefix and ipv6Prefix entries; creationTime and syncToken help document the retrieved version. This is a changing operational data source, not an outsourced guide or an FCM-exclusive address list. Google advises against IP-based FCM filtering because the large, frequently changing ranges can easily become incomplete or outdated. If this filtering is mandatory, compare the complete current ranges with the approved firewall objects, apply changes in a controlled manner and review the list at least monthly and again when delivery problems occur; do not use a frozen list from this article or only the smaller Google Cloud range list.

Check the actual device network path with the network administrators: verify the intended Wi-Fi/mobile network, any VPN, the effective outbound rule and return traffic. FCM push requires a direct connection and cannot be relayed through a network proxy; for NAT or Stateful Packet Inspection, set a timeout of at least 30 minutes for connections over 5228-5230. During the authorised pilot, correlate firewall logs or a targeted packet capture with the device timestamp, then check task acceptance in Sophos Mobile and on the device. If connections are blocked or drop, first investigate the rule, route, VPN/proxy and timeout, rather than registering the Google binding again. This push connection, including its TCP 443 path, is separate from HTTPS 443 to the regional Sophos Mobile device host and inbound SCEP firewall allowances; check each required path separately. A firewall allowance, JSON retrieval or successful account connection alone proves neither device enrollment nor task acceptance.

Connect the organization to Google — preserve continuity rather than registering twice

In Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise, first check the existing Android Enterprise mode and account details. If a registration exists, do not blindly create a second Google enterprise account or replace the connection. Document the responsible administrator account, domain access, and recovery arrangements internally before making changes.
Only if the organization is not yet connected: Open Configure > Register account. This redirects to Google. Enter an organization-controlled work email in Create Admin Account, select Next, and follow the enterprise registration steps Google displays for that identity. If Google does not yet know the email address, open the confirmation link sent to it; steps may differ for an existing Google domain or Microsoft identity. On the subscription page, select Android Enterprise; the Google Android Enterprise subscription is free, but additional Google subscriptions may cost money.
After returning to Sophos Mobile, enter the same email address used for the Android Enterprise admin account, select Finalize setup, and check the account details displayed on the Android Enterprise tab. A successful Google sign-in alone does not prove that device management works.

After registration of a work email previously unknown to Google, Google signs the administrator in to the new Enterprise Google Account. This account can also be used for other Google services, such as the Google Admin console at admin.google.com. Avanet recommends checking the identity and organization actually signed in there before making further changes. This is a planned check, not a sign-in test performed for this article. An existing Google domain or Microsoft identity may have a different registration workflow; do not take that as a reason to create a second account.

Do not confuse the connection with short-lived tokens: The existing Android Enterprise organization registration is not the time-limited Google token for enrolling a new device, nor the token for upgrading an already enrolled device. An expired or failed device task is no reason to run Configure/Register account again or remove the existing Google connection. First document account/domain ownership, the current registration mode and switch, device and user assignments, and the task; if the connection is unclear, stop and resolve it administratively instead of using a second registration as a repair. The two one-hour limits below have different start and end points.

Treat registration mode and device enrollment mode separately: Before April 9, 2024, organizations could choose Managed Google Play Account or managed Google domain as their registration mode; later new registrations use managed Google domain. The additional Use managed Google domain device enrollment setting determines how new devices enroll: users then authenticate with Google instead of Sophos Fusion and must already have a Google Workspace/Cloud Identity account (possibly via an IdP). Managed Google domain registration alone does not imply Google-domain device enrollment: Without the switch, Sophos Mobile manages the Google accounts itself for organizations registered after the cutoff. In organizations registered in managed-Google-domain mode before the cutoff, users are assigned through Sophos Fusion; Sophos Mobile creates the managed Google account during SSP enrollment but does not maintain that account thereafter. Without the switch, administrator enrollment is also restricted for these existing registrations: only users can enroll through the Sophos Fusion Self Service Portal. If the organization is registered in Managed Google Play Account mode and has not yet upgraded to managed Google domain, Sophos Mobile manages the Google user accounts itself. For Managed Google Play Account registration, there is a technical limit of 10 concurrently enrolled Android Enterprise devices per user; this is not a license-counting formula.

Only when domain-based device enrollment has been explicitly approved for new enrollments: Document the existing Android Enterprise mode, switch state, and Google/Sophos user mapping; all intended users must already exist in the managed Google domain. Then, under Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise > Managed Google domain device enrollment, select Use managed Google domain device enrollment and choose Save. Afterwards, check the switch state and test Google sign-in with the intended identity in the pilot; saving the setting does not prove successful device enrollment. If the switch is absent, do not create a new connection as a workaround: first check the organization’s registration mode and assess the separate upgrade to managed Google domain only with its own approval. For managed-Google-domain organizations registered before the cutoff, this also makes QR, Zero-touch and Knox Mobile Enrollment available; these methods were already available for other Android Enterprise registration types. KME with managed Google domain device enrollment does not support legacy device administrator mode.

Prepare the policy, package, and user identity

The Android Enterprise device policy for company devices explains the specific Full Device policy options; it does not replace the choice of enrollment mode.

Create an Android Enterprise device policy for Full Device, or an Android Enterprise work profile policy for Work Profile. Do not present a work-profile policy as proof of full management of a company device. For each device type used, create a separate task bundle with at least Enroll and Assign policy for that type’s policy. Record the target group and existing assignments before the pilot.
Before sending invitations, check the effective, saved SSP configuration: Under Setup > Self Service Portal, establish which existing configuration applies to the intended user groups: if several group assignments match, the configuration with the highest priority takes precedence; Default applies only if no other configuration matches. Check an existing configuration that already fits rather than creating a new one. Under Maximum number of devices, there must still be room for the planned enrollment; this SSP limit is neither the license count nor the technical Google limit. In the Android platform settings, check Owner, the target Device group, and Enrollment package against ownership, the approved management mode, and the prepared task bundle; personal and company devices can use different packages. Owner alone does not establish the actual Full Device mode. If the configuration is unclear or unsuitable, stop and involve the responsible administrators; do not switch to another account or enrollment type or make broad changes to Default.
The configuration check and pilot described in the SSP administrator workflow are prerequisites for invitations: If no suitable configuration exists, prepare one separately through that workflow. Before saving, limit changes to an authorized, tightly scoped pilot with only the required actions: Save can make actions immediately available to groups already assigned, even before a priority correction. Apply changed platform settings with Apply, then save the configuration with Save. As a verification step, Avanet recommends reopening the configuration and checking the saved settings and effective group priority, including Default, again. Before sending invitations or assigning groups more broadly, carry out the enrollment test described in the SSP administrator workflow with authorized test users and devices for every affected group and each intended ownership/management mode, and verify the outcome on the device and in Sophos Mobile; a visible portal option is not enough.
Approve the Sophos Mobile Control app in Managed Google Play, or it will not update automatically. Only after these checks and IT approval should you direct users to their portal or the organization’s invitation email and the SSP user handoff: users install and configure Mobile Control according to the specific instructions shown there. These general SSP steps do not replace a decision about mode or reset.
With Use managed Google domain device enrollment, create all intended users in the managed Google domain in advance, confirm their Google credentials with them, and check device assignment. For a task initiated by Sophos Mobile, the email assigned to the device must exactly match the email used to enroll with Google. A different person or a change to the prefilled email causes enrollment to fail. Sophos Mobile Control 9.8 or later is required; Work Profile also requires all available OS and app updates. For new domain-based device enrollment, the user must complete enrollment on the device within one hour of starting it; merely starting or using the token within that time is not enough. Preparing enrollment may remain displayed for several minutes without visible progress: keep the app open and do not switch off the device. If this step still fails, do not repeatedly launch tasks blindly. Manual removal of the work profile or a device factory reset are possible recovery paths. Do not choose freely between these interventions: first check ownership, the actual mode and state on the device; only for a verified personal device in confirmed Sophos BYOD work-profile mode, consider profile removal as a recovery path and assess its impact on work data; for confirmed Full Device, assess the impact of a factory reset on all device data. For company devices with a work profile or unclear ownership or mode, stop and separately verify the supported Sophos/OEM recovery path and obtain authorization. Before intervening, document ownership, a verified backup and recoverability, the affected user, and explicit approval; before a reset, also check FRP configuration and access to the designated Google accounts, as well as renewed QR/Zero-touch/KME assignment and the provisioning path. If credentials are unknown, do not reset. Only after confirming device state should you retry enrollment; neither an old device token nor a new organization registration substitutes for this preflight.

Administrator pilot: Under Devices > Add > Add device wizard, find the right person under User > Search for user and select them on User selection, set Device details > Platform to Android, and choose the prepared Android Enterprise package under Enrollment type. Whether the device becomes fully managed or a work profile depends on the policy assigned to the package; selecting Android alone does not determine it. For a legacy managed-Google-domain tenant without domain device enrollment enabled, use the permitted SSP path instead. For userless devices, use only the QR/Zero-touch procedure expressly configured for them, following the separate provisioning instructions.

Stop and check before changing an existing Google connection

Upgrading the organization registration from Managed Google Play Account to managed Google domain is different from enabling Use managed Google domain device enrollment for new enrollments, and different again from upgrading a single device that is already enrolled. The organization upgrade ties management to the work domain and Google Admin console instead of a single Gmail account. First establish domain ownership, identity management, existing accounts, and approval; do not claim an easy rollback.

Confirm the domain and contact details before proceeding

Check the exact domain of the intended work email and obtain approval to use it for this organization upgrade. The selected domain is permanently fixed once the upgrade is complete. For an existing managed Google domain, authorized access with its super-admin account is required. This sign-in authenticates the connection; ownership remains tied to the domain, not to that individual.

On a successful upgrade, Google deletes the contact information from the previous connection, including the Gmail address and details of the data protection officer and EU representative. Avanet recommends preserving any details needed before confirmation, under internal privacy and access rules, and assigning responsibility for their subsequent maintenance. This concerns the connection’s contact metadata, not a documented deletion of the Gmail account. If the domain is unclear, super-admin permissions are missing, or transfer of contact details has not been settled, stop before Upgrade.

Continue the Google upgrade from Sophos Mobile

After separate approval, open the Google redirect under Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise > Upgrade to managed Google domain. This EMM-initiated upgrade starts from the existing management console; the Sophos redirect is the entry point to the actual Google transaction, not a second initial registration or a general Google sign-in. Complete administrator account setup for the managed Google domain there, using the appropriate branch:

If a managed Google domain already exists, sign in with its super-admin account. Check the approved domain again and select Upgrade. If users are already synchronized, Google may also offer Authenticate using Google during connection. Obtain separate approval for the effects of this Google authentication from the identity administrators; do not enable it if its effects are unclear. This conditional Google step is not the Sophos Use managed Google domain device enrollment switch.
If no managed Google domain exists yet, create it with the approved work email and set up the administrator account. Confirm the email through Google’s message. Full domain verification is optional in this workflow. Check the domain again before confirming and select Upgrade. This continues the existing organization connection; it is not a second initial registration through Configure > Register account.

Then return to Sophos Mobile, refresh the page, and check Android Enterprise mode = Managed Google domain. Description must show the administrator account used for registration; correct it if necessary. These checks must be performed in the target tenant; they have not already been performed for this article. If the display differs, stop and resolve the connection with the responsible administrators.

After a successful upgrade, enterprise administration takes place in the Google Admin console of the newly connected domain; app management remains in Sophos Mobile as the EMM. Update the required contact details in that domain’s Google Admin console and check the entries. Reentering these details restores only contact metadata; it does not reverse the connection upgrade. Google’s recommended further setup steps 3 to 6 in the EMM setup guide are a separate Google administration task, not an additional license or OS prerequisite for this upgrade.

Plan new device enrollment and single-device upgrades separately

Only then assess domain device enrollment for new devices and the separate upgrade of existing devices. Successfully upgrading the organization does not prove that an existing device has changed its enrollment mode.

When enabling the new device enrollment mode, all users must already exist in the Google domain; for domains registered before the cutoff, existing usernames must be preserved or Sophos Mobile cannot map them. This means the part of the name before the @, not necessarily the same domain: for the fictional Fusion account anna@firma.example, the managed Google domain google.firma.example gives the account anna@google.firma.example. Replace the names and domains with those for your own tenant; for device enrollment initiated by Sophos Mobile, the exact email match with the Google sign-in still applies as well. During legacy SSP enrollment, Sophos Mobile combines the Fusion username with the managed Google domain, searches for that account, and creates it only if it does not already exist. Deleting a Mobile user does not delete a Google domain account. Further account maintenance takes place in the Google Admin console; directory integration through Google Cloud Directory Sync (GCDS) is a separate identity-management task.

A single-device upgrade cannot be undone. Only for an approved pilot, after confirming user assignment (including for devices previously enrolled without a user), an email address from the managed Google domain, Google credentials, enabled domain device enrollment, and Mobile Control 9.8+: use Devices > [device] > Show device > Actions > Upgrade to managed Google domain enrollment; the user must confirm the notification on the device and sign in to Google. The user must start the upgrade on the device within one hour of triggering the action in Sophos Mobile; after that, the Google upgrade token is invalid. This deadline concerns starting the upgrade, unlike completing new device enrollment above. If it expires, do not assume the token remains valid: check status and user assignment before any separately authorized new action; neither switch the connection nor blindly retrigger the action. A prior backup and alternative path are required; this action is not a migration from Device administrator to Android Enterprise and is not a general recovery path for failed enrollment. The action is unavailable for devices already using managed Google domain enrollment; a missing action is therefore no reason to register the organization again.

Verify the outcome and exit safely

In the pilot, check device identity, ownership type, the management mode actually shown, correct user assignment, completed tasks, and effective policy against the record; also confirm on the device that only managed apps/data are affected for a confirmed personal BYOD device with Work Profile, or that the company device has been set up correctly. A task or Google account entry being created does not prove enrollment succeeded. If a time limit expires, the email is wrong, or the policy has not applied, stop before another task, preserve device and task status, and investigate the specific failure.

Do not mistake offboarding for an enrollment rollback: Unenrolling a fully managed Android Enterprise device requires a factory reset; before approval, separately check ownership, a recoverable backup of all affected data, the reset method, Factory Reset Protection (FRP), the validity of and available credentials for the Google accounts configured for it, and reprovisioning. If account credentials are unknown or invalid, stop: after a wipe, the device may be unusable. QR requires scanning during device setup; with Zero-touch/KME, check active provider assignment and the return/reuse path before resetting, in the separate provisioning workflow. Even deleting a still-managed Full Device entry may trigger an automatic factory reset; do not treat that as risk-free cleanup. Only for a verified personal device (BYOD) with actually confirmed Sophos work-profile mode, after authorization, consider Devices > [work-profile device] > Actions > Wipe Android work profile: this removes apps and data in the work profile, not automatically the entire personal device. Trigger it with Yes in the confirmation dialog only after checking the device, mode, backup, and approval against the record. With Managed Google Play Account registration, a Google account may remain on the device after unenrollment and continue to count toward the concurrent-device limit; in that case, manually remove only the clearly identified managed account, not the user’s personal Google account, before treating the slot as available. Only after confirming device state should you clean up inventory and assignments; do not infer successful unenrollment from the disappearance of a console entry. Legacy Device Administrator Unenroll is not a substitute for a Full-Device-Wipe.

For checks of FRP accounts, device synchronization, and reset paths before approval, see Prepare and check Android FRP; this is not blanket authorization for a reset.

Scope of this guide: QR, Zero-touch, and Knox Mobile Enrollment, including resets and provider release; FRP account recovery; Device Administrator migration; detailed BYOD removal; and app/policy rollout are separate tasks. No device, tenant, token change, reset, or unenrollment was performed for this article; supported OS/OEM combinations, effective licensing, and actual Google/Sophos roles must be checked in the target system.