- Basics
- About Knox
- Knox licenses
- Knox white paper
- Sign up for Samsung Knox
- Latest release notes
- General Knox FAQ
- General Knox KBAs
- Submit a support ticket
- User Acceptance Testing
- For IT admins
- Knox Admin Portal
- Knox Suite
- Knox Platform for Enterprise
- Introduction
- How-to videos
- Before you begin
- Get started with UEMs
- Introduction
- Blackberry UEM
- Citrix Endpoint Management
- FAMOC
- IBM MaaS360
- Microsoft Intune
- MobileIron Cloud
- MobileIron Core
- Samsung Knox Manage
- SOTI MobiControl
- VMware Workspace ONE UEM
- Knox Service Plugin
- Release notes
- Migrate to Android 11
- FAQs
- Troubleshoot
- KBAs
- Knox Mobile Enrollment
- Knox Configure
- Mobile
- Wearables
- Shared Device
- FAQ
- KBAs
- Knox Capture
- Introduction
- How it works
- How-to videos
- IT admins: Get started
- Getting started with Knox Capture
- Step 1: Launch Knox Capture
- Step 2: Create a scanning profile
- Step 3: Select apps and activities
- Step 4: Configure the scanner
- Step 5: Set keystroke output rules
- Step 6: Test apps in your configuration
- Step 7: Share your configuration
- Step 8: Deploy Knox Capture in Managed mode
- End users: Get started
- Features
- Release notes
- FAQ
- KBAs
- Troubleshoot
- Knox Asset Intelligence
- Knox Manage
- Introduction
- How-to videos
- Get started
- Video: Getting started with Knox Manage
- Integration with Managed Service Provider
- Access Knox Manage
- Configure basic environments
- Create user accounts
- Create groups
- Create organization
- Set up devices and profiles
- Create a new profile
- Assign profiles to groups and organizations
- Enroll devices
- Shared Android device quickstart
- Non-shared Android device enrollment quickstart
- Android Management API device enrollment quickstart
- Apple User Enrollment quickstart
- View device information
- Apply profiles to organizations
- Set up Knox Manage deployment with a Knox Suite license
- Manage Chromebooks
- Manage Android devices with the Android Management API
- Manage Shared iPads
- Configure
- Licenses
- Organization
- Users
- Sync user information
- Groups
- Devices
- Content
- Applications
- Profile
- Knox E-FOTA
- Certificates
- Advanced settings
- Monitor
- Kiosk devices
- Knox Remote Support
- Active Directory
- Microsoft Exchange
- Mobile Admin
- Appendix
- Release notes
- Features
- FAQ
- KBAs
- Knox E-FOTA
- Introduction
- How-to videos
- Get started
- Features
- EMM integration
- Appendix
- Release notes
- FAQ
- KBAs
- Troubleshoot
- Knox E-FOTA On-Premises
- Legacy Knox E-FOTA products
- Knox Guard
- Introduction
- How-to video
- Get started
- Using Knox Guard
- Dashboard
- Manage devices
- Device management
- Accept or reject devices
- Upload devices
- Delete devices
- Complete device management
- Send notifications
- Enable or disable SIM control
- Download devices as CSV
- View device log
- View device deletion log
- Start and stop blinking reminder
- Lock and unlock devices
- Update lock message
- Send relock timestamp
- Turn on/off relock reminder
- Manage policies
- Manage licenses
- Manage resellers
- Manage admins and roles
- Activity log
- Knox Deployment App
- Release notes
- FAQ
- KBAs
- Support
- Open API reference
- Samsung Care+ for Business
- For Knox Partners
- Knox Deployment Program
- Knox MSP Program
Minimum requirements
You must meet the following requirements to use the Knox Service Plugin (KSP) with your managed devices.
What you need
-
Samsung devices that support Knox and run Android 9.0 (Knox 3.2.1) or higher.
NOTE — You can also use devices running Android 8.0 (Knox v3.x) if you use them in a fully managed device (DO) deployment. - A Unified Endpoint Management (UEM) solution that supports Android Enterprise deployments and is compatible with KSP.
- A valid Knox Platform for Enterprise (KPE) license for each of the devices managed with KSP. For more information about Knox licenses, see Knox Platform for Enterprise licenses.
- You must set up your devices in one of the supported Android Enterprise deployments, as described in Supported deployments.
Supported deployments
The first step to deploy a KSP policy is to create a DO or PO profile on your device. Without choosing one or the other, policies do not work and an error message is thrown.
In an enterprise deployment, Google provides three modes of Android Enterprise, Managed Device (DO), Work Profile (PO), and fully managed a with work profile.
- Work Profile — Helps admins manage the BYOD (Bring Your Own Device) use case, where a device user owns the device and uses it both personally and for work. The agent sits inside the container area as Profile Owner (PO) to separate work apps from personal apps. IT admins can control the work area only, and have visibility over the personal area.
- Managed Device — Also known as Company Owned, Business Only (COBO); helps admins manage devices that are owned by the enterprise. When a device is enrolled as a Managed Device, IT admins have full control over the device. The agent sits as Device Owner (DO) of the device.
- Work Profile on Company Owned Devices — Also known as Corporate Owned, Managed Profile (COMP) on Android 10, and WP-C (starting Android 11+) are company-owned devices that are personally enabled, with a container that is managed by PO. This deployment type targets enterprise-owned devices that require a separation of work and personal data. Employees can use these devices for either work or personal purposes. For more information, refer to Work profile enhancements for company-owned devices.
KSP works with the following Android Enterprise deployment modes:
- Android 8.0 — Fully managed device deployments only — Device Owner (DO).
- Android 9.0, 10.0 — Fully managed device — Device Owner (DO), Work Profile — Profile Owner (PO), fully managed device with a Work Profile, and Android dedicated devices (COSU) (Corporate-Owned Single Use) mode.
- Android 11 and higher — Fully managed device — Device Owner (DO), Work Profile on personally owned devices (PO), Work Profile on company-owned devices (WP-C), and Android dedicated devices (COSU).
Supported features
Your deployment must use policy configurations that KSP supports. KSP inherits its policies from the KPE framework. These policies can be either standard (free) or premium feature (paid). Paid features require a KPE Premium license. You can see the supported features and their classification on the feature overview page.
Supported UEMs
You need a UEM that supports Android Enterprise based deployments, device management APIs, and complies with the OEMConfig specification. Check with your UEM to confirm which version of their UEM console you need to use with KSP. Some UEMs offer more than one console. Some consoles may not support KSP.
UEM | Schema | Feedback Channel |
BlackBerry | Supported | Supported |
Citrix | Supported | To be supported |
IBM MaaS360 | Supported | Supported |
Knox Manage | Supported | Supported |
Microsoft Intune | Supported |
Supported |
MobileIron | Supported | Supported |
SOTI MobiControl | Supported | Supported |
VMware Workspace ONE UEM | Supported | Supported |
UEM prerequisites for compatibility with KSP
In addition to previously noted compatibility considerations, UEMs must also:
- Support advanced app restrictions, including multilevel nested schema to show KSP's managed configuration options.
- Support a feedback channel, based on the appropriate Google SDK, for fetching results back from the KSP Agent and showing these results on the IT admin console.
- Customize OEMConfig apps for the UEM console, as compared to normal applications that support managed configurations. This distinction is necessary as some steps and options typically supported for normal apps—such as enforce VPN— may not apply for this OEMConfig app.
- Enable the auto update setting for the OEMConfig apps to reduce policy setup issues. For example, when different managed devices run different versions of KSP, and if the IT admin uses a newer version of KSP to set a policy on the admin console, devices running an older version of KSP cannot apply the policies.
- Restrict users from deleting individual policies or policy groups on the console. This restriction is necessary as it reduces chances of issues in subsequent policy updates if a user wants to add back a deleted policy.
- Include all the elements in the managed configuration data pushed to KSP, even if the IT admin did not modify some policies while editing the configurations. If all elements are included for each push, KSP correctly identifies all changes and interdependencies for deployment.
- Hide restriction types on the UI. Such restricted fields are reserved for the UEM backend and KSP only.
- Support KPE Premium License activation.