Sophos Mobile: Prepare dedicated Android devices safely

In Sophos Mobile, a dedicated Android device is a fully managed Android Enterprise device with a kiosk mode configuration in its Android Enterprise device policy. Enrolling a device as fully managed does not, by itself, restrict it to particular apps. A personal Android device with a work profile is not a substitute: Sophos manages only the work profile in that case.

This decision aid helps you choose and safeguard a provisioning path; it is not authorization for a reset or a fleet-wide rollout and does not provide instructions for physically exiting kiosk mode. That exit must be demonstrated in practice before deploying to the fleet.

Decide before provisioning

1. Entitlements and ownership: Check for Sophos Mobile Device Management or the combined Mobile license, Android Enterprise registration, administrator permissions, company ownership, and the intended device mode. A Mobile Threat Defense-only environment is not an Android MDM environment. Do not treat existing Device Administrator devices as new dedicated Android Enterprise devices.
2. Data and unlocking: For devices already set up, establish an approved backup and confirm that it can be restored before making any changes. Fully managed devices must be unconfigured or factory-reset for enrollment; for subsequent removal of management, Sophos specifies wiping the device rather than a separate unenrollment step. First clarify any possible Factory Reset Protection (FRP), as access protection after certain resets, along with required accounts, network access, and recovery arrangements with the device owner. A reset is not a harmless retry.
3. Pilot and identity: Choose an authorized, expendable pilot device for each selected path; define the expected user assignment or explicitly userless operation, the Android Enterprise device policy, app access, device group, and a reachable support/exit channel. Do not distribute serial numbers, credentials, or enrollment codes without control.

Prepare Managed Google Play apps: For each intended Managed Google Play app, check organizational approval and addition to Sophos Mobile; then plan targeted installation on the intended devices or device groups. The app approval and targeted installation workflow explains prerequisites, app types, and checks. Catalogue approval, selection in the kiosk policy, and actual installation are separate steps: for Install managed Google Play app, Successful in Task view initially means only that the request was sent to Google. Check the installation status under Show device > Installed apps and the actual availability of every required app on the pilot device. The separate Sophos COSU/Device Owner workflow specifies only Managed Google Play apps in its kiosk configuration; this does not establish a general Managed-Play-only rule for all the kiosk provisioning paths distinguished here. The separate preflight check for required system and launcher apps remains necessary.

Keep provisioning paths distinct

For Samsung devices, check dual registration before choosing Zero-touch: if the device is registered and configured in both KME and Zero-touch, KME takes precedence. The read-only check and stop conditions are in the Zero-touch section.

QR code: Preparation, identity, and network

For QR enrollment, the code is scanned during initial Android device setup to bring the device under full Android Enterprise management. Plan this only for new devices or devices reset with separate authorization. Userless means that no email account is connected during enrollment and Sophos Mobile does not assign a user to the device. There is a separate QR code for this; userless operation is not simply a skipped sign-in in the user-associated workflow.

Google also assigns an internal user account to userless QR and Zero-touch devices. This account is distinct from user assignment in Sophos Mobile. A user can be assigned manually later if needed; such a change requires separate authorization and is not part of the enrollment described here.

The internal Google account identifier can be checked read-only on the Internal properties tab of the device record. The property name depends on the enrollment mode:

• Managed Google domain: android.enterprise.bte.userless-device.account-id
• Managed Google Play Account: afw_play_emm_managed_device_account_user_id

Do not change these internal values. The presence of an identifier alone does not prove that no user is assigned in Sophos Mobile, that the device is in full-device mode, or that enrollment succeeded. Check the actual user assignment and device mode separately.

For an authorized pilot, prepare the appropriate branch under Setup > Google setup and check it before handing over the device:

• QR code enrollment for user-associated devices with Configure Android Enterprise QR code enrollment, or QR code enrollment (user-less) with Configure Android Enterprise QR code enrollment for user-less devices. Enable only the branch intended for the planned assignment and provide its code.
• Under Configure enrollment, verify the intended Task bundle and Device group. The bundle is transferred to the device; the group determines its assignment. The task bundle needs Assign policy for an Android Enterprise device policy, but no Enroll task.
• Under Configure QR code, use Language to select the Android user interface language and set the network connectivity. This applies to both user-associated and userless QR codes. For Wi-Fi, the security type, Wi-Fi SSID, SSID is hidden where applicable, and Wi-Fi password must match the intended setup network. With Don’t configure Wi-Fi, the code contains no Wi-Fi configuration. Use cellular network allows the cellular data connection to be used for enrollment if Wi-Fi is unavailable or no Wi-Fi is configured in the code; that connection must be available on the device. Check the system app selection separately before a kiosk lockdown, as described below.

Before initial setup, the correct QR code and, for the user-associated path, the sign-in credentials must be ready. This path requires a Fusion user with the User role and a non-federated Fusion sign-in; the account credentials are entered during enrollment. These prerequisites do not apply to the explicitly userless path. The different domain prerequisite on the QR setup page is explained below and does not authorize bypassing this sign-in restriction.

Network connectivity may be needed before scanning: on some devices, Android must first download the QR code reader over Wi-Fi. After scanning, a manual network connection is required if the code contains no Wi-Fi configuration or the Wi-Fi configured in it is unavailable. A code containing Wi-Fi details therefore does not, by itself, establish enrollment readiness. Before distributing devices, clarify the planned connection and an acceptable alternative with the device owner.

QR enrollment on the authorized pilot device: Start only after company ownership, device mode and the prerequisites above have been confirmed. For a previously used device, data loss, backup, restorability and any reset must have separate approval; the following sequence does not authorize a reset.

1. Have the appropriate QR code ready and power on a new device or one already reset with separate authorization.
2. On the Welcome page of the Android setup assistant, tap the same spot six times to open the QR code reader.
3. If the device first needs to download the reader, establish the Wi-Fi connection required for this.
4. Scan the provided QR code. If it contains no Wi-Fi configuration or the configured Wi-Fi is unavailable, establish a network connection manually.
5. Follow the enrollment instructions on the device and enter the credentials required for the selected identity path.

According to Sophos, this enrolls the device as a fully managed Android Enterprise device. Afterwards, check the actual full-device status and user assignment; app availability, kiosk policy and physical exit require separate acceptance checks. This sequence is a documented manufacturer workflow, not a device outcome tested here.

Use Print to print the code for enrollment without access to Sophos Mobile Admin. The same code can be used for multiple devices; it is not a one-time code. Treat network details in the code, along with digital and printed copies, as sensitive access material and make them accessible only for the intended devices. Explicitly revoking a code prevents further enrollments with that code. Generating a new code invalidates the previous code; the new code can still enroll devices. Sophos describes stopping future enrollments and invalidating the previous code here, but does not state an effect on devices already managed. Distinguishing this from removing existing management is therefore an interpretation of that documented scope, not a product effect tested here. Do not plan on revocation or replacement as Unenroll, a reset, or a kiosk exit.

Samsung KME: Profile and device handover

KME allows multiple Samsung devices to be enrolled in Sophos Mobile. Prerequisites include a compatible device with Knox 2.8 or later for Android Enterprise Full Device Management, a Samsung account, and the Knox Admin Portal. Before distributing devices, check that each is enabled for KME and registered in the KME console; compatibility and the Knox version alone are not enough.

Before handover, the network owner must confirm connectivity to the KME server and the required firewall exceptions using Samsung’s Samsung Knox firewall exceptions documentation. Have the responsible owner also confirm availability at the intended deployment location using Supported locations. For KME, the documented destinations are *.samsungknox.com, *.secb2b.com and *.samsung.com, each over HTTPS 443. These documented destinations replace neither a review of the complete, current Samsung firewall exceptions nor a check of supported deployment locations. Neither a successfully modified firewall nor reachability on your own network has been verified here; handover remains stopped without the confirmations listed above.

In Sophos Mobile Admin under Setup > Google setup > Samsung KME, check that Use Knox Mobile Enrollment is enabled and the enrollment details under Enrollment settings are configured. There, Device group determines which device group KME devices are assigned to during enrollment. Compare this selection with the planned device group rather than accepting or changing it without checking.

If setup is missing or needs to be changed, obtain separate authorization for it. Only for such an approved setup, save the Sophos enrollment settings with Save before creating the Samsung profile. This save is separate from subsequently saving the Samsung profile; a preflight check alone requires neither changes nor saving.

Depending on the profile, KME can also select the older Device Administrator mode: KME alone does not establish that the device is dedicated. Device Administrator is unavailable on Android 10 or later; the older mode is an option only on Android 9 or earlier. For Android Enterprise Full Device Management, User authentication must be enabled; without this setting, KME supports only Device Administrator mode, provided the Android version allows it. During device setup, users enter their credentials for the Sophos Fusion Self Service Portal (SSP). If users are synchronized from Microsoft Active Directory and an LDAP connection between Sophos Mobile and AD is configured, they enter their AD credentials instead. Without this LDAP connection, an invitation to the SSP is required. As a preflight check for the AD branch, the email address in Fusion must match the AD mail attribute; the directory owner must confirm the LDAPS connection and the firewall access required for the Fusion region. No LDAP setup is reproduced here, and no credentials are collected.

When Use managed Google domain device enrollment is enabled, users instead authenticate with Google and need an account in the managed Google domain. KME does not support the older Device Administrator mode with this setting. Check these prerequisites in the tenant; do not apply the userless Zero-touch rule to KME. Disabling User authentication is not a userless full-device path.

Profile and handover for an authorized KME pilot: After KME setup on the Sophos side, the Sophos instructions describe an MDM profile for Sophos Mobile in Samsung Knox Admin Portal > Knox Mobile Enrollment. For Full Device Management, they specify the Device owner option and the tenant-specific values from MDM profile configuration under Setup > Google setup > Samsung KME in Sophos Mobile Admin; the Samsung profile is then saved. For separately authorized profile creation, open the Samsung portal in a separate browser tab. Use Copy next to each required Sophos field to copy its value to the clipboard. The values come from your own tenant, not a generic sample profile; protect the clipboard contents and copies as sensitive access material.

Samsung interface not yet mapped for Sophos: The available Samsung pages describe Profiles > PROFILES on the shared Enrollment page and Create profile. Selecting EMM under Basic info displays the sections for EMM details and device settings. Create profile creates the profile without assigning devices; Create and assign combines creation with assignment. This does not yet establish which current Samsung field corresponds to the Sophos instruction Device owner. Before proceeding with an actionable profile creation procedure, have this mapping confirmed in an authorized Sophos-compatible tenant or through official manufacturer clarification. Stop until then; do not use either an assumed replacement field or Samsung’s Knox Manage example as the Sophos DPC configuration.

The responsible administrator then assigns the saved Sophos Mobile profile to the selected KME-capable pilot devices in the Knox Mobile Enrollment console. If a device is missing there, clarify its registration with the reseller and stop the handover until this is resolved. Hand the devices over to the intended users only after assigning the profile and checking the prerequisites. When powered on for the first time, the KME setup assistant starts; once an internet connection is established, enrollment with Sophos Mobile follows with the required user authentication. The mode selected in the Samsung profile still determines whether Full Device Management or Device Administrator is used. This documented sequence is not authorization for a reset or a fleet-wide rollout.

For targeted assignment to an individual device, Samsung’s Assign profiles page describes the path Devices > IMEI/MEID > Enrollment profile > SAVE, requiring the Manage devices permission. Use this documented path for the selected pilot device only after the Sophos profile mapping has been confirmed. The sources differ on the menus in the shared device list: the Samsung tutorial specifies Actions > Assign enrollment profile, while the assignment page specifies Actions > Common > Assign enrollment profile. These variants remain separate; no confirmed current click path is inferred from them here.

Check the KME task bundle: The Sophos KME setup page specifies Task bundle (Android) for Device Administrator and Task bundle (Android Enterprise full device management) for Android Enterprise Full Device Management; the Samsung MDM profile determines the mode. These selectors show bundles without an Enroll task. With managed Google domain device enrollment enabled, the Device Administrator selector is unavailable and the full-device selector is labeled Task bundle. For separately approved setup, use the selector appropriate to the mode; during preflight, only compare the selection and policy assignment in the actual tenant. This is not a complete enrollment sequence and must not be replaced with the older COSU bundle order.

Check KME system apps separately: If Samsung’s System apps selector is used during authorized profile creation, Disable system apps means that preinstalled apps are hidden during enrollment; according to Samsung, certain default apps such as My Files, Contacts and Play Store remain available. Enable system apps allows access to preinstalled apps. This OEM selector is neither the Enable system apps switch in Sophos for QR/Zero-touch nor the subsequent kiosk app selection. Check required system and launcher apps on the pilot device without assuming a default value or that the setting can later be reversed. If Knox Configure is also used, clarify possible profile conflicts with the responsible administrator.

Profile changes do not repair a device already in operation: Changed or newly assigned KME profiles do not automatically take effect on devices that are already enrolled. Samsung specifies reprovisioning with a factory reset to apply them; this is a task requiring separate approval, not authorization here to attempt a reset. Advanced settings are optional, require a Knox Suite - Enterprise Plan and remain outside this workflow. Enabling them later is not an automatic update either. Unenrollment from Knox Guard is also not authorized here.

Google Zero-touch and shared preflight checks

Zero-touch allows bulk registration of compatible company-owned Android devices as fully managed Android Enterprise devices. Prerequisites include devices purchased through a Google-approved enterprise reseller and an existing account for the Google Zero-touch portal. The reseller usually creates the portal account with the first device purchase; this does not replace checking that access is available. Distinguish the portal account from the user account for subsequent device enrollment.

For Android Zero-touch enrollment, the documented destination is www.googleapis.com over HTTPS 443. Check reachability from the intended setup network with the network administrators; this is neither a Google administrator account nor an inbound SCEP firewall allowance, and it does not prove successful provisioning.

Check Sophos settings before configuring Google

In the correct Sophos Mobile tenant under Setup > Google setup > Zero-touch, check that Use zero-touch enrollment is enabled and enrollment is set up. If settings are missing or do not match the planned path, stop provisioning and obtain separate authorization for the setup. The following sequence describes preparation for an authorized pilot, not authorization for a tenant-wide change:

1. A task bundle for QR code enrollment is required: it contains Assign policy for the intended Android Enterprise device policy and no Enroll task. Also check the domain prerequisite described below before starting; neither enabling a domain nor migrating the registration is authorized here.
2. Under Zero-touch configuration settings > DPC extras, verify the device settings. Language determines the language of the Android user interface, and Time zone the device’s time zone. System app selection is covered in the shared app preflight check below. Use cellular network uses the cellular data connection for enrollment. If no cellular network is available, the user must connect the device to Wi-Fi; a suitable setup connection must therefore be ready. This Zero-touch rule is not the Wi-Fi/cellular selection in the QR code.
3. Under Enrollment settings, check the actual target values: Device group determines the device group to which devices are assigned; Task bundle is the task bundle transferred to the device. User authentication must match user-associated or explicitly userless enrollment.
4. Disable User authentication only for the userless path. In this case, no email account is connected during enrollment and Sophos Mobile does not assign a user; a user can be assigned manually later if needed. Google nevertheless assigns an internal user account. Userless therefore does not mean “without any Google account.” On the user-associated path, the user needs a Sophos Fusion user account; when Use managed Google domain device enrollment is enabled, the user instead authenticates with Google and needs an account in the managed Google domain. Before enabling a domain, all users must be prepared as described below.
5. For a separately approved setup, save the enrollment settings with Save before creating the Google configuration. Sophos generates the tenant-specific configuration code for the Google portal from the DPC settings.

Transfer the DPC code to the Google portal

Only after completing the Sophos setup, go to Setup > Google setup > Zero-touch and use Copy next to DPC extras to copy the current configuration code. Sign in to the Google Zero-touch portal in a new browser tab and create a new configuration for Sophos Mobile under Configurations > Add Configuration. Under Name, enter a short, recognizable name for the intended use. Under EMM DPC, select Sophos Mobile Control and paste the copied code into DPC extras.

Include the support details in this configuration as well: under Company name, enter a company name employees will recognize; under Support email address, enter the responsible support team’s email address; and under Support phone number, enter a reachable support number. The company name and contact details are displayed during device setup; the email address and phone number are available before provisioning begins. The email address is not clickable there. Choose a short address that can be entered on another device; calls must also be made from another device. Under Custom Message, you can optionally add a short message of one or two sentences about the process or how to contact support. Verify these details with the responsible support team before assignment. Do not use generic sample values or codes from another tenant; protect the clipboard contents and copies as sensitive access material.

Portal inventory and initial device handover

Registering a device that is already set up in the Google Zero-touch portal factory-resets that device. Therefore, before registering it, establish an approved backup, confirm restorability and FRP accounts, and obtain the device owner’s authorization; no device registration or reset instructions are provided here.

Before any assignment or distribution, check that every intended device is actually registered in the Google portal. The reseller usually adds the devices, but this usual responsibility is not proof. If a device is missing, stop the handover and clarify the portal entry with the reseller rather than registering it unchecked as a troubleshooting measure.

Check Samsung dual registration read-only: Before Zero-touch assignment or handover, check with the responsible portal administrators whether the Samsung device is registered and configured in both KME and Zero-touch. In that case, KME takes precedence: the device enrolls through KME and applies its KME configuration, not the Zero-touch configuration. This differs from the EMM default-profile precedence described below. Stop assignment and handover while the effective enrollment path is unresolved. Refer any required removal of the assigned KME configuration to the responsible administrator under separate authorization; this preflight does not authorize portal deletion, revocation, a reset or unenrollment.

Automatic reset after skipped Zero-touch enrollment: If setup has no data connection, or the connection blocks traffic to Google servers, Zero-touch enrollment is skipped. If the device nevertheless has an assigned Zero-touch configuration, it resets itself after its first later connection to Google servers. Google describes a warning to the person using the device one hour before the reset; this does not guarantee that data can be backed up in time. Escalate the data-loss risk to the device owner and review data, backups, restorability and FRP accounts. Do not hand over the device for normal use until its actual enrollment state and effective path are understood. Do not deliberately connect it as a reset experiment or treat this warning as reset authorization.

Check for an existing EMM link before assignment: Confirm with the Zero-touch account owner whether the account is already linked to an EMM and which Enterprise default profile it uses. If such a link exists, that enterprise default profile takes precedence over the Default configuration in the Google portal. Opening a new browser tab or creating a new Sophos configuration does not rule out an existing link. If the link status or associated profile is unclear, stop assignment and handover. This workflow neither creates nor removes an EMM link.

Then assign the Sophos configuration specifically to the selected devices and confirm the assignment. Without the precedence described above from an EMM link, an optional Default configuration can apply automatically to devices added in the future; it is not a selection limited to the pilot. Do not use the portal’s default configuration as proof of the actual pilot assignment. Only after confirming the assignment should you hand over the devices with the credentials required for the selected identity path.

When a device prepared this way is powered on for the first time, the Android setup assistant starts. According to Sophos, once an internet connection is established, automatic enrollment as a fully managed Android Enterprise device follows. This describes the manufacturer’s workflow, not a tenant or device outcome tested here, and it does not yet establish a kiosk lockdown. Separately verify the actual full-device status and user assignment on the authorized pilot device; do not attempt an unapproved reset for network problems.

Shared domain and app preflight checks

Check the domain setting for each path: For organizations that registered with Android Enterprise in “managed Google domain” mode before April 9, 2024, the QR, KME, and Zero-touch paths specify Use managed Google domain device enrollment as a prerequisite. The QR setup page additionally and independently identifies a federated Sophos Fusion sign-in as a trigger for this setting. This does not override the separate requirement for a non-federated Fusion sign-in for user-associated QR enrollment. Verify the registration, identity, and selected path in the tenant; do not interpret this setting as a general fix or as authorization for otherwise unsupported enrollment. If user-associated QR enrollment with a federated sign-in is planned, stop provisioning and involve the identity owner to clarify the situation.

The option is under Setup > Google setup > Android Enterprise > Managed Google domain device enrollment. Enabling it affects all new Android Enterprise enrollments in the tenant, not just the QR code or KME pilot currently being prepared: users then authenticate with Google instead of Fusion. Before an approved change, all users must have been added to the managed Google domain, for example through managed accounts in Google Workspace or Cloud Identity, or an external identity provider configured there. Check this tenant-wide prerequisite separately from userless device assignment. Hand the change over to those responsible for Android Enterprise and Google identities; it does not replace identity creation or automatically migrate existing devices.

If Use managed Google domain device enrollment is missing, the Android Enterprise registration must first be switched to a managed Google domain. In this case, stop the QR/KME launch and clarify the separate registration migration with the responsible administrator rather than changing portal or device values experimentally. Switching the organization’s registration and subsequently switching devices that are already enrolled are separate tasks; according to Sophos, the device switch cannot be reversed and is not authorized here.

App preflight for QR and Zero-touch: On these full-device provisioning paths, system apps with launcher icons are disabled by default unless enabled through the respective Enable system apps option. Before an authorized kiosk pilot, verify that required system and launcher apps are actually available; do not infer fleet-wide app restrictions solely from the planned policy.

Kiosk policy and safe acceptance

Only after confirming Android Enterprise Full Device Management should you plan an Android Enterprise device policy with kiosk mode for the intended apps: in the Select source selector, Custom and App list restrict the device to one app. For Custom, enter the app identifier; for App list, select the app from the list. App ID identifies the app users are allowed to open. App group allows multiple apps; the App group field identifies the group of apps users are allowed to open. None allows all apps and is not an app restriction. Verify the apps, device group, and policy actually assigned on the pilot device. Sophos describes a separate COSU/Device Owner workflow with its own task-bundle sequence; it is not a confirmed enrollment procedure for the QR, KME, and Zero-touch paths distinguished here and is not reproduced here.

Check App permissions before locking down: Identify the runtime permissions required by each kiosk app and deliberately set the default response and app-specific rules; grant only the permissions needed for the use case, rather than using blanket automatic approval as the default. The device policy for apps and permissions explains the options. App permissions controls only runtime permissions: requests for battery optimization or accessibility can still appear. Auto-accept and Auto-deny prevent users from editing the relevant permissions later. On the authorized pilot device, check whether required app functions work with these rules and whether remaining requests interfere with operation.

Check sound and diagnostics before locking down: Allow volume change enables use of the volume buttons. Disabling it mutes the device; users then cannot turn sound back on themselves. Show notifications displays notification icons in the status bar, heads-up notifications and the notification area. Without this setting, the confirmation required for an Android bug report cannot appear. In kiosk mode, users cannot send Sophos Mobile Control logs themselves, although remote retrieval remains possible; the procedure for retrieving app logs describes an authorized request and safe handoff. Without notifications, the bug-report attachment is missing. Enabling notifications does not automatically enable Quick Settings.

Check kiosk availability settings in the pilot: Turn off screen lock prevents the screen from locking at all; Stay on while charging prevents it from locking while connected to power. Assess each setting against access-control and power needs rather than enabling either by default. Show system information in status bar controls indicators such as time, connectivity and battery level; verify that operators can see the information they need. These settings do not prove managed-app delivery or a physical kiosk exit; confirm both on an authorized device before any fleet lockdown.

Accept the pilot device: In the device inventory, compare the actual full-device status, expected user assignment or userless state, policy, and visible kiosk apps. Check network access, volume, notifications needed for the use case, and remote diagnostics.

For KME, also compare Status = Provisioned in Samsung’s Devices table: Samsung uses this as evidence of completed enrollment. This OEM status does not replace Sophos task and app installation status, the correct full-device mode, the assigned policy, actual app availability or a working physical kiosk exit.

Before rolling out to the fleet, demonstrate the approved physical exit and recovery in practice together with the device owner. Do not lock down devices at scale without this evidence. Neither a tenant nor a device was tested here.

Stop and recover

Zero-touch network failures can trigger a later automatic reset: If enrollment was skipped because there was no data connection or Google servers were blocked, and the device has an assigned Zero-touch configuration, it resets itself after its first later connection to Google servers. Google specifies a warning one hour beforehand, not a guaranteed opportunity to back up data. Before further network recovery steps, involve the device owner and review data, backups, restorability and FRP; no normal use or handover until the enrollment state and effective path are understood. Do not deliberately reconnect or reset to test this; any separately required change still needs separate authorization.

Distinguish missing installation from incorrect display: First check task and installation status, the policy actually assigned, network access, and app availability on the pilot device. For an installation already sent to Google but not yet completed, look for a blocked download under Pending downloads in Google Play, if authorized access is possible. An installed app that is not displayed correctly is a different failure from an app that has not actually been installed.

Time required in the separate COSU/Device Owner workflow: In the Sophos workflow “Set up a device in corporate-owned single-use mode”, enrollment together with app installation can take up to 30 minutes on some devices. This is a possibility limited to that workflow, not a guaranteed duration, minimum waiting period, task timeout, or fixed stop threshold for QR, KME, or Zero-touch. Assess task status, installation state, and actual device availability; do not reset or re-enroll solely because time has elapsed. While acceptance fails, further fleet assignment remains stopped.

Consider a restart only for the relevant failure: For the same COSU/Device Owner workflow, Sophos mentions that a restart may be needed after enrollment if apps are not displayed or listed correctly. This does not mean that a restart installs missing apps or resolves general enrollment errors. After the status and network checks above, establish authorized access to the pilot device, the device owner’s consent, and a disruption window as an operational safeguard. A restart is not a factory reset, Wipe, re-enrollment, or a demonstrated kiosk exit, and it does not guarantee success. Afterwards, recheck actual app visibility, app functionality, and kiosk state; do not assign more broadly without successful acceptance.

Zero-touch revocation is separate from device exit: For an approved stop to future enrollments, the Sophos action is under Setup > Google setup > Zero-touch > Revoke zero-touch configuration. Afterwards, Zero-touch devices continue trying to register with Sophos Mobile; Sophos rejects the requests. To fully disconnect future enrollment, also delete the configuration for Sophos Mobile in the Google Zero-touch portal. The Sophos page on turning off Zero-touch describes automatic enrollment but does not specify the effects of revocation or deletion of the Google configuration on devices already managed. Distinguishing these actions from removing existing management is therefore an interpretation of that documented scope, not confirmation that existing devices remain unaffected, and not a product effect tested here. Neither revocation nor deletion of the configuration is unenrollment, a reset, a physical kiosk exit, or recovery of erased data.

KME revocation is separate from device exit: To stop future KME enrollment with approval, the Sophos-side control is Setup > Google setup > Samsung KME > Revoke KME configuration. Afterwards, KME devices continue connecting to Sophos Mobile for enrollment, but Sophos rejects these requests. To fully disconnect future enrollment, also delete the profile for Sophos Mobile in the Samsung Knox Mobile Enrollment console, not the device objects or all profiles indiscriminately. Sophos describes stopping future enrollments here, but does not specify the effects of revocation or profile deletion on devices already managed. Do not plan either action as unenrollment, a reset, a kiosk exit or data recovery.

If the mode is wrong, apps are missing, device controls become inaccessible, or sign-in fails, immediately stop further assignments, record the last policy and portal state and affected devices, and involve an available administrator. For devices not yet enrolled, assess the relevant QR-code authorization or Sophos KME/Zero-touch configuration and the Samsung or Google portal separately. Revocation is not unenrollment and does not restore erased data. For a device already managed, first establish the state of the data, FRP accounts, and a device-specific, confirmed exit; neither policy rollback nor removal of a portal configuration is presented here as a tested way to physically exit kiosk mode. Do not reset without separate approval and a tested backup and restore process.