Authored by Anjali Tibrewal, co-authored by Monica Singh.
Mobile technology in enterprises is a key enabler to providing their workforces with a seamless digital workspace experience that must meet three important criteria: 1) securely interacting with enterprise data and 2) maintaining or improving productivity and 3) ensuring privacy. Be it real-time inventory and order fulfilment apps, production monitoring and management apps, or custom apps built for some specific use cases for an industry, there are many situations where personnel needs access to data to make decisions, manage daily tasks and respond to critical situations.
In many industries, the work conditions pose harsh and adverse environment challenges (e.g., factories, manufacturing plants or outdoors), and the use of typical device form-factors (workstations/desk devices) is prone to failures and un-viable.
Ruggedized devices and the use of mobile solutions based on rugged devices are designed for these adverse situations and give the personnel access to the data they need irrespective of where they are located. In many use cases, ruggedized devices are often used for a specific duration or purpose by a set of users and then at a later point in time need to be reconfigured for another set of users, tailored for their needs. This aligns well with the concept of shared devices and the associated capabilities offered by device management solutions. These capabilities offer a streamlined process around how a single device, typically owned by the organization, can be used by multiple users at different times of the day/shifts as required.
Below are the typical requirements for usage of shared devices in organizations.
- Cater to multiple categories of users – e.g., inspection managers, on the floor workers, operations or facilities manager. Each of them need a different set of apps on the shared device to be functional and productive at any time of the day.
- Ensure data separation between multiple users using a single device at different times of the day, ensuring that users have access to only the applications they need.
- Allow seamless exchange of devices, with the new user running their set of productivity apps in no time.
In this blog we provide instructions on how to setup and configure iOS and Android devices for use in a shared mode, with IBM Security MaaS360 with Watson. While native support from Apple or Android has separation at an OS layer, MaaS360 supports it by allowing different users to sign in to the MaaS360 service and configuring it on the go for their requirements. (Apple iPad devices support sharing features natively; read a blog on the topic here).With MaaS360 shared device support there is no dependency on Apple Business Manager (ABM).
Provisioning the device
On Android, these devices are primarily corporate owned devices and any form of Device Owner (DO) enrollment for Android devices would work. Any mode of DO (QR Code/ZT/KME+DO) along with user-less enrollment and device account type would work for enrolling the device. More details on how to generate QR codes are available here.
On an iOS device, follow these steps.
- Add a DEP profile, with Authenticate User turned off. Other settings can be based on configuration choices.
- Setting in deployment settings - "Deploy apps and configurations to devices that enroll without auth" should be turned on.
- Assign the profile to devices and enroll the device using DEP.
Groups
Create Groups for easy management of apps and default policies to be applied on device when it is in pool, i.e. ready to be picked up by a user.
Group for In-Pool Devices:
Ownership = Corporate Owned
AND
Username = Empty
![]()
Policy & Apps
Once a device is enrolled and is part of a shared pool, it may be required to prevent any unauthorized use of the device without performing a sign-in. To achieve this, policies can be configured to allow very limited apps to be accessible when a user is not signed in. Passcode settings can be turned off, so that any user can login on the MaaS360 app. These policies can then be applied to devices that are in pool.
On iOS, policy can have an allowlist of apps before sign in which can be configured under Supervised settings.
![]()
On Android, apply a policy with COSU enabled, with no other apps in allow-list except MaaS360 Launcher App. Complete list of policies supported when COSU is enabled on the device can be found here.
Once a user signs in, at this point, a user-group based policy can be applied that allows access to applications as needed. The policy can also enable passcode settings on the device. On Android, policies can be applied with COSU removed and access allowed to applications as needed. On sign in, this policy should get applied and users should be able to access relevant apps.
Sign in
Sign-in can be configured to authenticate using a user account created on MaaS360 or let the user simply use corporate credentials by federating authentication with the corporate directory. The user should be provisioned manually on MaaS360 before a sign-in is attempted.
A usage policy, that can be presented to the user upon sign-in to MaaS360, can be defined in the Persona policy and configured to be either read-only or acceptance of the usage policy can be enforced. Additional settings around configuring a grace period on a change of usage policy for a user and an action to be taken when user has not accepted the usage policy can be configured.
![]()
Sign Out
Apps would automatically get removed on sign out if “Remove on sign out” option is selected. G Suite (now called Google Workspace) apps should get logged out automatically if the Android Enterprise binding is done using G Suite.
Automatic sign out settings can be configured on Android that allows for signing in as a new user when the previous user have not signed out of the device. Additionally, an inactivity time period can be configured to sign out the user if the app is not used.
![]()
End user experience on shared devices
A user can pick from a pool of shared devices that are enrolled and kept ready for use. At this point, most applications cannot be used and the device doesn’t have any passcode. Any user can pick a device and sign into MaaS360 to start using it. This is what the IBM MaaS360 app would look like :
![]()
This is what the sign in experience would look like :
Once the user is done using the device, they could logout of the MaaS360 app and at this time the corporate apps would get removed. The passcode would also get cleared on sign out and the same default policy with no passcode would get applied.
We hope this blog was helpful to increase your understanding how to leverage MaaS360 so your workforce can get the most out of shared devices. As always, we encourage you to post comments and questions to this blog or start a discussion post on the Community.