Set Up a Sophos Mobile Tenant and Hand Over Administration

Sophos Mobile is set up in an existing Sophos Fusion tenant. This procedure ends with preparation and an approval decision for a limited pilot, not with completed enrollment or a production-wide rollout. Mobile Device Management (MDM) and Mobile Threat Defense have different license entitlements and capabilities. Before making changes, record the tenant, edition, role, device platform, ownership model, and recovery path. General tenant activation and administrator security are covered in Securely Set Up a Sophos Fusion Tenant.

1. Confirm licensing and permissions first

In the correct Fusion tenant, open Profile icon > Licensing and compare the product, edition, and available entitlement with the assignment. Sophos Mobile Device Management (formerly Central Mobile Standard) covers MDM for Android, iPhone/iPad, Mac, and Windows; Sophos Mobile Threat Defense (formerly Intercept X for Mobile) covers management of Intercept X for Mobile and Sophos Chrome Security. Sophos Mobile (formerly Central Mobile Advanced) includes both. A visible Mobile interface does not prove any particular MDM entitlement. Do not redeem a license on a hunch: activation, renewal, and licensing consequences belong to the Fusion licensing procedure; verify the tenant and assignment there first.

Verify the region separately: Open My Products > Mobile in the relevant Fusion account, read the region from the browser URL after smc-user-if-cloudstation-, and record it for infrastructure/network approval. Sophos Mobile server destinations vary by region; the responsible network administrator must compare the connections required for the actual region and platform with the current Sophos network documentation. Do not infer the region from the organization’s location or language, or from an individual administrator’s time zone. Without a verified region and the required network approval, there is no go for the affected pilot route.

Use an authorized Admin or Super Admin for initial setup. Fusion roles map to Mobile as follows:

Assign responsible people and roles in Fusion according to Assign Administrative Roles Correctly, then check which menus and actions are actually accessible in Mobile using separate Help Desk and Read-only accounts. Do not downgrade the only working administrator account. The MDM documentation allows Helpdesk to enroll devices and install apps. Critical functions such as configuring settings and creating, editing, and deleting devices, device groups, and packages are excluded from this Mobile role. The Threat Defense role description lists only general support actions as permitted Helpdesk actions; it also explicitly excludes the critical functions listed above. Do not infer universal Helpdesk enrollment permission across editions. Directory/LDAP integration and identity synchronization require their own approval and recovery procedure; they are not side effects of assigning roles.

2. Set basic settings without changing devices

Personal display settings in Sophos Mobile Admin apply only to the signed-in administrator account. Sophos includes the configurable user interface language among these settings, but its personal settings page does not document a language selector, where to find it, or how to use it. The UI language is distinct from the language of outgoing emails described below; this documentation does not establish that the Fusion language is inherited automatically.

In Sophos Mobile Admin > Setup > General, distinguish the scope of each setting:

1. Personal: Set the time zone, units of measurement, table rows, Expert mode, and displayed device platforms for the signed-in administrator account, then select Save. The individual settings work as follows:

   • Time zone sets the time zone used to display date and time values.
   • Unit system sets the measurement system for lengths: Metric or Imperial.
   • Lines per page in tables sets the maximum number of entries displayed on each table page.
   • When Expert mode is enabled, the Show device page includes the Custom properties tab for custom device properties and the Internal properties tab for additional properties reported by the device. Several policy configuration pages also display an Extra settings section where optional settings can be configured.

   Enabled platforms control the visibility of relevant pages and settings; they neither activate a license nor enroll devices. After saving, check that the expected platform appears in the navigation. If views are missing, check the personal platform filter and role first; restore the previous selection if necessary.

2. IT contact: Enter a monitored support address and a reachable contact, select Save, and check the text on a designated test device only after separate pilot approval. This information appears on user devices. Do not enter a private phone number or unapproved personal information. Save corrections in the same tab and check again on the test device.

3. Email configuration: Set the language of emails sent by Sophos Mobile, then select Save. This does not configure an SMTP relay, Exchange mailbox, or EAS proxy. Test an actual Mobile message event during the pilot; Save alone does not confirm delivery. If the language is wrong, restore the previous value and assess another test message.

Setup also contains platform, privacy, and integration options. Do not enable APNs certificates, Android Enterprise, device synchronization, privacy permissions, or EAS indiscriminately. The personal time zone is not a global tenant time zone; the IT contact and email language, by contrast, are part of the general Mobile configuration. The getting-started guide also identifies the Fusion Self Service Portal as a separate setup step.

3. Prepare devices and enrollment only

For MDM, first establish ownership (organization-owned or personal), target platform, management mode, affected user group, device count, and consent/privacy text. For Android, approve the Android Enterprise mode and its prerequisites separately. For iPhone, iPad, and Mac, approve the APNs certificate required by Sophos Mobile, its owner, its one-year validity, and its renewal before enrollment. For a later renewal, the Apple owner must verify the original Apple Account and the correct certificate using the APNs Topic: a new or incorrect certificate with a different Topic can interrupt management of already enrolled devices and require reenrollment. Do not remove the APNs certificate as a recovery method for existing devices.

If the certificate is missing and none has ever been uploaded in this tenant, hand over first-time APNs certificate creation to the APNs owner; creation and upload require separate approval and must not be performed casually as part of this preparation procedure. For an existing certificate, the APNs owner handles identity verification and renewal. For the handover, require evidence of the displayed certificate details, expiration date, responsible Apple Account, and renewal responsibility; do not copy credentials into the verification record or treat an upload as pilot acceptance. The Apple Business service token is separate. The Threat Defense manual does not contain the same Apple/EAS setup tree as the MDM edition: shared basic settings are not a promise of identical device capabilities.

Only if automated enrollment through Apple Business is selected: The Apple/enrollment owner must demonstrate an organization registered in Apple Business (formerly Apple Business Manager), an authorized Apple Business account, an APNs certificate stored in Sophos Mobile, and the separate connection through an Apple Business service token. Record the token’s one-year validity and the person responsible for renewal; renewal requires the same Apple Account used for the original token. Resetting the integration deletes the token, Apple Business devices, and profiles in Sophos Mobile; it is not a harmless rollback. Without this evidence, there is no go for this route; Apple Business is not a blanket prerequisite for every Apple enrollment route. Do not create or reset tokens or profiles as part of this tenant baseline procedure.

Only if Android Enterprise is selected: Before the first Android pilot, the Android/Google owner must demonstrate the appropriate MDM license, Android Enterprise management mode, organization registration, and connection of the correct corporate Google account to Sophos Mobile. Selecting a mode changes the available policy types; it does not register an organization. Check the actual registration and enrollment mode and the origin and readiness of managed Google accounts for test users: depending on the configuration, Sophos Mobile manages accounts, or users must already exist in Google Workspace/Cloud Identity. Only if the organization was registered in managed Google domain mode before April 9, 2024 and Use managed Google domain device enrollment is disabled does Sophos Mobile, during SSP enrollment, check whether a managed Google account formed from the part before @ of the user’s email address in Sophos Fusion plus the organization’s managed Google domain already exists, creating it otherwise without managing its subsequent lifecycle. This managed user account is neither the corporate Google account used for Android Enterprise registration nor automatically an FRP unlock account; verify identity mapping and the account-recovery route independently before the pilot. Check a suitable policy for the chosen device type; for SSP enrollment, approve the assigned enrollment package with its Android Enterprise task bundle (Enroll and Assign policy) and the Managed Google Play approval of the Sophos Mobile Control app for automatic updates. Check that the specific enrollment route is suitable for the mode; fully managed Android devices may be enrolled only when unconfigured or after an approved factory reset. If an already used device is to be reset for this purpose, the device owner must check beforehand the device’s actual Factory Reset Protection (FRP) status, the intended reset method, and the approved unlock/account-recovery route. Arrange access to the Google accounts authorized for FRP on that device; the account used for Android Enterprise registration or the user account is not automatically an FRP unlock account. Depending on the reset method, FRP may require an account sign-in after the reset. Do not record credentials in the pilot documentation. This check applies to planned resets of fully managed Android devices, not indiscriminately to work profiles or Apple devices. Do not casually perform Google enterprise registration, account migration, or device resets during this baseline procedure.

Before sending an invitation, record the planned pilot configuration in Setup > Self Service Portal: permitted device types, ownership mode, suitable device group and enrollment package, and permitted self-service actions. The maximum device count limits devices per user, not the number of pilot users or the reach of the configuration. Limit the pilot group separately through the actual user/group assignment. Before changing any shared SSP configuration, inspect and document the effective default configuration (the fallback when no more specific assignment matches), all groups matching both pilot and non-pilot users and their priorities, the permitted actions, and effects on already enrolled devices. Before any write to shared SSP settings, obtain separate authorization from an independently authorized person for the specific change and its reach; record the previous settings, including default, groups, priorities, actions, and platform assignments, and the recovery path. Without this authorization, leave the configuration unchanged. After Save, but before invitations or enrollment, check and document the actually effective assignment for pilot and non-pilot identities, including default and multiple group memberships, and the effects on already enrolled devices and their SSP actions. If the reach is unexpected, stop further changes and invitations, restore the previous settings, and recheck effective assignments and device effects; if the effect cannot safely be reversed, no go and escalate to the responsible owners. This write authorization is separate from the later go for pilot enrollment. A seemingly narrow pilot configuration can affect other users through the default or multiple group memberships. Only if the approved pilot route requires consent to SSP terms: For the test identity and chosen platform, the SSP/enrollment owner checks the effective Enrollment texts and the platform-specific Terms of use field for approved content. If Terms of use is empty, no such text is shown before enrollment and no consent to it is collected; that SSP consent route gets no go. If consent instead follows a separate approved procedure, document that route; SSP terms are not a blanket prerequisite for other enrollment routes. Policies, compliance, and enrollment packages are separate prerequisites, not automatic consequences of basic settings.

Approval gate before any pilot enrollment: A second authorized person checks, in the actual tenant, the edition/license and available Mobile entitlement for the named pilot users or userless devices; roles; verified region and network approval; for SSP routes, effective SSP assignment for the test identity and a non-pilot identity, including default/priority and group reach rather than the per-user device limit; for userless dedicated devices instead, the separately approved fully managed Android enrollment route and device assignment; platform/management mode; consent; policy/package; and responsibility for backup, reset, and offboarding. If the approved route requires SSP consent, the go/no-go includes the effective Enrollment texts, a platform-specific Terms of use field populated with approved text, and the test identity. Otherwise, document the separate approved consent procedure. For selected Apple MDM routes, include proof from the APNs owner; for a selected Apple Business or Android Enterprise route, request the additional route-specific owner evidence described above. If a factory reset of a fully managed Android device is planned, explicitly include evidence obtained beforehand of FRP status, intended reset method, and the approved unlock/account-recovery route for the actually authorized FRP accounts. Routes not selected are not blanket blockers. Record an explicit Go/No-go for the named test accounts and devices. If evidence is missing or the decision is no-go: no invitation, no enrollment, no device change; return the case to the responsible owners. This documentation procedure does not itself grant approval or establish that the tenant or a device has been tested.

Only after separate approval does the responsible enrollment owner conduct a limited pilot for user-assigned routes with a dedicated, named test user for each approved platform, recording the enrollment identity, registration, assigned group, target policy, task status, IT contact, receipt of messages on that device, and recovery path. Only for a separately approved userless dedicated-device pilot does the responsible device/enrollment owner instead check the selected management and enrollment route without user assignment on the named test device, the enrollment identity or device assignment, the target policy including kiosk configuration, task status, and documented recovery/offboarding path; do not assume a test user or SSP group match for this route. Only if the approved route requires SSP consent, also observe and document display of the approved Terms of use before enrollment and their acceptance by the test identity; where a separate consent procedure applies, use its approved evidence route. Sophos recommends testing before inviting real users; approval here replaces neither those observations nor a later rollout decision. Depending on the mode, enrollment routes include the Add-device wizard, manual enrollment, Self Service Portal, or platform-specific automated enrollment; no universal click path for all devices is claimed here.

4. Recovery and handover

Before the pilot, document original values and permissions. Personal, IT contact, and Email configuration can be reverted by restoring the previous value and selecting Save again; then verify with the relevant account, on the test device, or with a new test message, as appropriate. Correct an inadvertently overprivileged Fusion role using an administrator account that remains available, then sign in again with the affected account. Revert pilot-group and SSP configurations only after checking their actual assignments; merely removing a configuration is not evidence that already enrolled devices have been unenrolled or further enrollments have stopped.

Explicitly hand device offboarding to the device/enrollment owner: For a userless dedicated-device pilot, also have the owner stop its approved enrollment route, verify that no further device can enroll through it, and inventory already enrolled test devices; blocking user/group invitations alone does not stop this route. If the pilot is aborted or ends, first have the responsible owner stop new invitations and enrollment routes for the actually affected users/groups and verify that this worked; then hand over an inventory of already enrolled test devices, including platform, mode, ownership, and assignment. The device owner decides on unenrollment, user/device assignment, and follow-up checks for each device and records the outcome. Unenrollment is not a settings rollback: depending on the platform, managed profiles, apps, certificates, accounts, and data are removed; fully managed Android Enterprise devices must be factory-reset to unenroll them. Before a factory reset of a fully managed Android device, have the device owner also demonstrate the FRP status, intended reset method, and approved unlock/account-recovery route for the actually authorized FRP accounts; do not reset without that evidence. Before actual unenrollment, check device mode, backup, ownership, approval, and the official platform-specific consequences. Deletion is not harmless inventory cleanup: First unenroll using the platform-specific procedure and verify the result, then delete a record for a device that is no longer managed. If an enrolled device is deleted instead, it unenrolls at its next synchronization; deleting a fully managed Android Enterprise device triggers a factory reset and can destroy data. Before deletion, check which device information and stored data must be retained; the deleted console row proves neither successful device unenrollment nor a data recovery path. Deleting the record of an enrolled Windows device, however, does not automatically unenroll it; verify the actual status on the device. For Apple devices, have the Apple/device owner check Activation Lock status and the responsible reactivation procedure before reset, unenrollment, or release; do not reset or remove an APNs certificate or Apple Business integration as a supposed offboarding method. The app option Unenroll and SSP action Unenroll device are separate switches; hiding one does not automatically disable the other. Do not present device deletion, license revocation, or reversal of tenant settings as a reversible shutdown method.

For operational handover, have a second authorized person recheck the tenant and Mobile license, the capabilities of delegated roles, saved basic settings, effective SSP reach, approval/stop procedures, and device-offboarding handover. EAS proxy and Exchange mail flow remain with the separate EAS owner; LDAP/directory synchronization remains with the identity owner. Without existing approved device/enrollment and EAS/LDAP runbooks, do not imply approval for those workflows or add dead links. This informational guide does not certify that any tenant or pilot device has been tested; actual device changes still require separate approval.