Assessing Knox Service Plugin with Sophos Mobile

The Knox Service Plugin (KSP) makes additional Samsung Knox settings available as a managed Android Enterprise app in Sophos Mobile. It is not a separate Sophos device policy and replaces neither Android Enterprise enrollment nor its management mode.

Production HOLD: Do not assign KSP settings for device access, networking, certificates, apps, passwords, or kiosk use in production until you have checked each policy, management mode, license, observed effect, and rollback path on the target device. An installed KSP app or completed Sophos task is not sufficient evidence.

Preflight: What needs to be resolved before a trial?

For an authorized trial on a non-production device, check the following:

1. Device, mode, and required settings: Record the model, ownership, Android/Knox/KSP versions, and management mode. Check each required setting against its intended scope of effect and the version-specific Samsung release notes. Support for any given setting is unverified.
2. Confirm Samsung support: For older devices, clarify with Samsung the separate Android 9 and Android 12 statements documented below. Android 12/Knox 3.8 alone does not establish eligibility for every policy.
3. Check the Sophos environment and license: In line with Samsung’s KSP minimum requirements explained below, confirm with Sophos that the specific console used for centralized device management (UEM) supports Android Enterprise, device management APIs, OEMConfig, and managed Google Play for the selected device-owner/profile-owner mode. Check the documented key field, valid entitlement, actual activation, and expiry date; assign responsibility for renewal and any required device reactivation through the UEM. Not verified; “free” does not mean “keyless.”
4. Avoid duplicate controls: Compare native Sophos policies and KSP settings for each restriction, taking account of Samsung’s specific recommendation for KSP device restrictions. A conflict-free combination has not been established.
5. Observe the effect and rollback path: Once approved, check the baseline state, the effect of each setting, available feedback, and the state after administrative removal on the test device. Provide secured administrative access and a recovery path.

Management mode and scope of effect

Sophos Mobile treats KSP as an app for Samsung devices with Knox Platform for Enterprise (KPE, Samsung’s platform for enterprise policies). The app is approved and distributed through managed Google Play. The sequence below is confirmed by Sophos documentation, not by testing in a Sophos tenant or on a device. For an authorized trial after the preflight checks, approval, configuration, and installation are separate steps:

1. Approve for the Android Enterprise account: Under Apps > Android, on the Apps - Android Enterprise page, use Open managed Google Play to open the embedded store. Open the KSP app, choose Select, and confirm with Yes. Optionally, use Organize apps to add the app to a collection. Close the window; the app now appears in the Sophos app list. This is the documented approval process, not yet an installation. Users see the app in their managed Play Store only when the device next synchronizes with Sophos Mobile. A visible console entry therefore does not mean the app is already available for users to install themselves.
2. Configure the app and send settings: In the documented Sophos workflow, select the KSP app under Apps > Android. Use Page and App category to set its location in users’ Google Play Store app. Then enable Use managed configuration and configure the Samsung-defined settings under Managed configuration. As specified in this documented workflow, enter the Knox license key in KPE Premium License key; the caveat below about the unverified current Sophos environment still applies. Then use Save followed by the separate Send app settings to Google command. According to Sophos, this command makes the configuration changes available to users.
3. Initiate installation separately: According to Sophos, KSP can be installed on selected devices or device groups; alternatively, users can install the approved app themselves from managed Google Play. For administrative installation, under Apps > Android, open the arrow next to KSP and choose Install. Select individual devices or use Select device groups to select groups, then finish with Finish. Sophos passes the task to Google; check the installation status under Show device > Installed apps. Send app settings to Google does not replace this installation step. According to Sophos, installing the previously configured KSP on a device applies the Knox policies; the documented workflow requires the Knox license key mentioned above.

Available fields can change with the KSP app version; whether a setting takes effect depends on the management mode and the specific Samsung policy. Neither sending settings to Google nor installing the app proves that a policy has taken effect on the device.

• Fully managed corporate device: Sophos Mobile can manage the entire device. This does not establish support for every KSP setting.
• Personally owned device with a work profile: Management extends only to the work area; a visible KSP field does not establish a device-wide effect.
• Company-owned device with a work profile: Samsung lists this mode for KSP. Whether settings can also take effect outside the work profile depends on the specific Samsung policy; Sophos support and the actual effect remain open questions.
• Dedicated device: This is a fully managed device additionally configured for kiosk use. Not every KSP setting is automatically supported here either.

Sophos distinguishes between fully managed devices, work profiles, and dedicated devices. A dedicated device uses fully managed enrollment with additional kiosk configuration; it is not a fourth, separate enrollment mode. Legacy Android device administrator, Knox containers, and Mobile Threat Defense are not interchangeable KSP management modes. For overlapping functions, Samsung generally recommends using the device management solution’s built-in controls and reserving KSP for additional capabilities. If native Sophos and KSP restrictions overlap, decide which system owns each restriction before a trial. In the specific case where even one KSP device restriction is needed, Samsung recommends managing all device restrictions within the KSP structure. This is not blanket approval for a mixed Sophos/KSP configuration; test overlaps on a supported device.

Which Samsung devices are candidates for KSP?

Samsung’s statements about KSP functioning and being supported conflict for older devices. The KSP minimum requirements (as of September 1, 2026) specify Android 12 or later. The supported Knox versions table (page updated September 2; table updated July 22, 2026) lists Android 12.0/Knox 3.8 for KSP, with feature-specific exceptions. The separately listed KPE platform value is not the KSP threshold. By contrast, Samsung’s KSP FAQ (as of September 14, 2026) answers a question about supported devices by saying that KSP works starting with Android 9/Knox 3.2.1. Because these statements conflict, the FAQ does not establish reliable current support approval for older devices.

Even for a device within the stated support threshold, check individual features. The KSP 26.08 release notes list app version 1.5.74, dated September 4, 2026. Auto Blocker requires Knox 3.14 or later; the USB exception list on locked devices requires Knox 3.14 and Android 17 or later. Peripheral Configuration policies are removed in this release. These limits apply to the named features, not to every KSP policy. A published app release does not prove that it is available in a particular Sophos tenant, that its configuration has been applied, or that any policy has taken effect on devices.

For planning: The support table distinguishes continued use from support. According to Samsung, older devices are not removed from Knox services solely because of the support threshold, but Samsung does not provide support for problems on those devices. This neither guarantees KSP functionality below Android 12 nor means that KSP cannot work there at all. The FAQ answer about supported devices remains contradictory on this point. For a new deployment, use the current minimum requirements and the Android 12/Knox 3.8 threshold as the basis; do not approve older devices without confirming the model and required settings with Samsung. Even within this threshold, the effect of individual policies in Sophos Mobile still needs to be checked.

Licensing: free does not mean keyless

The Sophos configuration requirements (as of August 8, 2023) require a key in the KPE Premium License key field; without it, the policies would not be applied. Whether this field and the policies behave the same way in a particular Sophos system today is unverified. Samsung says the app and KPE Premium entitlement are free but requires a valid KPE license. Specialized features may require separate paid entitlements. According to the Samsung license terms, the Premium entitlement expires two years after activation; expiration also affects existing devices. On expiration, Samsung requires reactivation of affected devices through the UEM as well as renewal, not just a renewed key. Whether and how this works in a particular Sophos tenant remains open. Expiration is not a rollback path.

“Free” means neither “keyless” in the documented Sophos workflow nor “automatically activated” in a particular Sophos Mobile environment. Do not put license keys in articles, screenshots, or unprotected tickets.

Verification on a test device

Before checking policy effects, first check the installation and app version. Sophos distinguishes two failure cases:

• If Installation request to be sent to Google persists for a long time, check whether KSP is available for the user’s country and device type.
• If Installation request sent to Google persists for a long time, open Pending downloads in Google Play on the device and look for a stalled task. The KSP task starts only after the tasks queued ahead of it have completed.

Updates: According to Sophos, app updates cannot be initiated from Sophos Mobile; users must perform them in Google Play. A new installation task is therefore not a documented update method. Record the KSP version actually installed and check the corresponding Samsung release notes and available configuration fields.

In particular, do not trial network, certificate, kiosk, or access restrictions in production without secured administrative access and a rollback path. Successful app installation or delivery to Google does not prove policy effect. According to Samsung’s KSP FAQ, per-policy feedback is available only if the UEM integrates the required Google interface. Whether Sophos Mobile displays this feedback in a particular environment remains unknown. Observe the actual effect on the test device.

Debug mode only for the limited trial

If feedback is missing from the console, Samsung describes a debug test directly on the device. Without Debug mode, KSP normally runs in the background without a visible app interface. Limit the trial to a few authorized, non-production devices. The following steps are documented but have not been tested in a Sophos tenant or on a device:

1. Under Apps > Android, open KSP and, with Use managed configuration enabled, turn on Debug mode under Managed configuration. Samsung notes that its location and appearance depend on the UEM interface. If the switch is missing from the available schema, clarify this with Sophos rather than using a different debug switch.
2. Configure only the previously approved test settings, choose Save, and send them with Send app settings to Google. According to Samsung, the KSP app opens the next time it receives new policies on the device. If it remains closed, first check delivery and the versions of Google Play services and the Play client. A saved console value does not prove receipt; Samsung’s general reference to a UEM update is not a confirmed Sophos click path.
3. In KSP, open the most recently received configuration. Check the results under Configuration results and use Policies received to compare the received settings in JSON format with the intended test values. Samsung displays successful policies in black and failed policies in red. Capture the error message for each failed policy. Document receipt, per-policy results, and error information separately, and also check the actual effect on the device. A success status does not replace this observation.
4. After the trial, turn off Debug mode in the same managed configuration, choose Save, and run Send app settings to Google again. Check that the test device receives the changed configuration. Samsung requires Debug mode to be turned off before broad distribution; doing so does not constitute production approval.

Stop the trial if an error remains unresolved. Take licensing issues to the reseller, UEM console questions to Sophos, and KSP issues to Samsung Knox Support.

Save diagnostic exports and request device logs

These steps are based on documented vendor information, not a device test. Maintain secured administrative access and a recovery path throughout the authorized, non-production trial.

1. Open KSP and select the most recently received configuration. In the export menu, choose Export results and use Save to save it under Internal storage > Download.
2. Repeat with Export policies received and Export historical events. The files are named ConfigurationResults_<timestamp>.txt, ReceivedPolicies_<timestamp>.txt, and HistoricalEvents_<timestamp>.txt; <timestamp> is the timestamp generated by the export. Results and received policies contain JSON; historical events also include previous policies and license activations.
3. Promptly after the error, have authorized Samsung Knox Support collect the dumpState ZIP file as well, because device logs can be overwritten. This article is not an executable SysDump collection recipe. Agree the model, Android version, access authorization, and capture timeframe with support before using system diagnostics.

Use Apply Latest Policies only to reapply already approved test settings. Delivery can be delayed; if necessary, retry after a few minutes. Neither tapping the control nor exporting results proves effect. Compare receipt, results, and actual device effects again.

On Android 15 or later, access to SysDump may require temporarily disabling Security and privacy > Auto Blocker. This weakens a security control: have authorized support do so only when the need is confirmed and explicitly approved, limited to the test device and capture period; afterwards restore and verify the original protection. Debug Level Mid is not a default step either: consider it only for a fault reproducible after a restart or at Samsung Knox Support’s request. Changing it restarts the device; approve the interruption, secure administrative access, and restore Debug Level Low after capture. This device debug level is separate from KSP’s Debug mode switch.

Check all four files for confidential content, including license keys, retain them securely, and submit them only through the authorized support channel. Use Delete dumpstate/logcat only after verifying secure retention, not as an initial or compulsory collection step. After diagnostics, verify restoration of protection and debug settings. No log collection or support investigation was performed here.

Rollback is not the same as uninstalling

For KSP, Sophos describes uninstalling the app as a way to remove Knox policies. There is no evidence that every setting then returns to its previous device state. Before issuing the task, document the baseline state and the planned recovery path; afterwards, verify app removal and the state of each test setting on the device, and record the device-verified recovery path.

For the authorized trial, Sophos documents this administrative uninstall task. It applies both to apps installed through Sophos Mobile and to apps users have installed from managed Google Play:

1. Under Apps > Android, on Apps - Android Enterprise, choose Uninstall.
2. Select the relevant individual devices or use Select device groups to choose the approved test groups. Before continuing, check that no production devices are included.
3. On Select app, select KSP.
4. On Schedule task, use Now to initiate the task immediately or Date to specify the scheduled day and time.
5. Complete the task with Finish. Sophos sends the tasks to a Google API; it may take a few minutes for uninstallation to begin. Even Now does not mean that removal on the device is immediately confirmed.

For a single device, Sophos alternatively specifies Show device > Installed apps and the trash icon next to the app name. After delivery, check actual removal and the device state. If a test setting remains in effect or administrative access is interrupted, do not assume recovery and do not continue the rollout.

Removing a catalog entry does not uninstall apps that are already installed. Uninstallation by the user is not an equivalent rollback path either. If the administrator installed the app through Sophos Mobile, Google reinstalls it immediately by default after the user uninstalls it. According to Sophos, permanent removal by users depends on Allow app uninstall in the Restrictions configuration assigned to the device or work profile. Do not change this permission as a blanket rollback step; it is not a documented prerequisite for the administrative uninstall task.