Shared Devices in 3S EMM

What Is a Shared Device?

A shared device is a company-owned phone or tablet used by more than one employee. Instead of assigning one device permanently to one person, the device belongs to a pool: a worker takes it at the start of a shift, signs in, uses the approved business apps, signs out, and returns it for the next worker.

This model is common in logistics, retail, healthcare, hospitality, field service, manufacturing, education, and warehouse operations. The business reason is simple: many employees do not need a dedicated device for the whole day. If devices can be shared safely, a company can reduce hardware cost, SIM cost, charging/storage overhead, spare-device inventory, and support work.

The challenge is security and usability. A shared device must not expose the previous user's data. It must also be fast enough for real shift changes. A shared-device solution normally provides:

• A managed sign-in screen.
• A way to assign the current device session to a real company user.
• Per-user or per-role policy after sign-in.
• A sign-out flow that prepares the device for the next user.
• App cleanup, app restrictions, or app data isolation where supported.
• Admin visibility into who is currently using the device.

Where Shared-Device Solutions Already Exist

Samsung Knox Authentication Manager

Samsung Knox Authentication Manager, or KAM, is Samsung's dedicated shared-device authentication product for supported Samsung enterprise devices. Samsung describes it as a managed app for shared Samsung devices that provides multiuser facial biometrics and sign-in automation for frontline productivity.

KAM is designed for Samsung environments and integrates with supported UEM/EMM products. It can work with managed launchers such as Workspace ONE Launcher, Microsoft Intune Managed Home Screen, SOTI MobiControl, and Samsung Knox Manage. Samsung documents requirements such as fully managed devices, Managed Google Play access, a Knox Suite license, supported Samsung Secured by Knox devices, Android version requirements, network access, and a shared encryption key for user profile/device group communication.

KAM's strength is convenience: face/PIN-style sign-in and app sign-in automation can make shift handoff much faster. Its tradeoff is ecosystem dependency: it is Samsung-specific, licensed, and tied to supported management modes, supported devices, and KAM-compatible workflows.

Source: https://docs.samsungknox.com/admin/knox-authentication-manager/

KAM vs 3S EMM in simple language

Samsung KAM is a mature Samsung shared-device product. 3S EMM shared devices are a simpler EMM-native workflow focused on policy switching, sign-in gating, and cost-efficient device sharing.

The main differences:

In short: KAM is the richer Samsung-first authentication and credential automation layer. 3S EMM shared devices are the lighter EMM-controlled version: fewer dependencies, easier setup, and enough control for many cost-saving shared-device deployments.

3S EMM is not trying to claim every KAM feature in the first release. The current goal is more focused: put a managed sign-in screen in front of the launcher, allow only users from shared-device-enabled groups, apply that user's group policy, and return the device to a clean shared state on sign-out.

Samsung Knox Manage Shared Android Devices

Samsung Knox Manage also has a shared Android device mode. Samsung describes this as a special shared mode where multiple assigned users authenticate through the Knox Manage agent sign-in screen. Knox Manage uses a staging user between regular user sessions and supports temporary and persistent shared-device types.

Temporary mode is closer to a guest workflow: app and user data are deleted when the user signs out. Persistent mode is more suitable for shift workers, where data and apps may be retained between sessions. Samsung documents limits, including a maximum of seven secondary users per device in that shared-device model, device/version requirements, and Android API limitations such as secondary users not being able to make normal phone calls or send SMS.

Source: https://docs.samsungknox.com/admin/knox-manage/original-console/quickstart-guides/shared-android-device-quickstart/

Microsoft Entra Shared Device Mode

Microsoft Entra Shared Device Mode is identity-driven. It lets organizations configure iOS, iPadOS, or Android devices for shared use. A user signs in to a supported app, and supported apps can participate in single sign-on and single sign-out. When the user signs out, participating apps should clear the previous user's state and prepare for the next user.

The important limitation is app support. Microsoft is clear that applications need to support shared device mode to get the full benefit. Apps that do not support it will not automatically participate in single sign-on, single sign-out, or cached data cleanup. This makes Entra Shared Device Mode strong for Microsoft and MSAL-aware apps, but less universal for arbitrary Android applications.

Source: https://learn.microsoft.com/en-us/entra/identity-platform/msal-shared-devices

Apple Shared iPad

Apple Shared iPad is Apple's built-in shared-device model for iPad. It requires supervised devices, a device management service, and Managed Apple Accounts owned by the organization. Multiple users can sign in to the same iPad and get a personal experience on shared hardware. Apple also supports temporary sessions where guest data is deleted when the guest logs out.

This is a strong model when the deployment is iPad-based and the organization uses Apple Business Manager or Apple School Manager. It does not solve Android shared-device use cases.

Source: https://support.apple.com/en-euro/guide/deployment/-dep9a34c2ba2/web

Android Enterprise Dedicated Devices

Android Enterprise dedicated-device management is not a full shared-user system by itself. It is the base management model for company-owned devices dedicated to a work purpose. It gives EMMs APIs for kiosk/lock-task behavior, persistent preferred activities, keyguard management, system update policy, and other controls.

Many Android shared-device products are built on this foundation: the device is fully managed, the EMM controls the launcher or sign-in app, and the EMM applies role/user policy after sign-in. The limitation is that Android does not generally provide a simple, universal multi-user business session model that works the same way across all enterprise Android devices and apps.

Source: https://developers.google.com/android/work/requirements/dedicated-device

Why 3S EMM Implemented Shared Devices

3S EMM customers often manage fleets where the same physical device can serve multiple workers. Buying a dedicated device for every worker is not always necessary. In shift-based operations, one phone can serve morning, evening, and night shifts if the sign-in and sign-out workflow is controlled.

We implemented shared devices because:

• Companies can reduce device and SIM cost.
• Devices can stay assigned to a site, vehicle, warehouse zone, or department instead of one person.
• Workers can use a familiar sign-in flow instead of device enrollment.
• Admins can apply different policies based on the active user's group.
• A device can be returned to a safe signed-out state before the next worker uses it.
• 3S EMM can support shared-device workflows without requiring Samsung KAM licensing for every deployment.

The 3S EMM implementation is inspired by the same operational goal as Samsung KAM: one managed Android device can be used by many workers across shifts. But it is not a Samsung KAM clone, and it does not depend on KAM internals.

Who Each Approach Fits

Choose Samsung KAM when:

• The fleet is mostly or entirely supported Samsung Knox devices.
• The customer already has or plans to buy Knox Suite.
• The organization uses Microsoft Entra ID, Azure app registration, AD/LDAP, or another supported enterprise identity flow through its UEM/EMM.
• The workflow needs PIN+Face sign-in, app credential autofill, and profile sync between many shared Samsung devices.
• The customer is ready for a more advanced setup with Samsung-specific requirements and network allowances.

Choose 3S EMM shared devices when:

• The customer wants to share devices mainly to reduce hardware and SIM costs.
• The first requirement is simple: block launcher access until an allowed worker signs in.
• The company wants to use 3S EMM tenant users, groups, and policies without first building Microsoft Entra, Azure, AD, or LDAP integration.
• The deployment needs role-based policy switching more than biometric sign-in or credential autofill.
• The customer wants a lighter setup for small and medium fleets, warehouses, field teams, stores, workshops, or regional operations.
• The business apps already use their own cloud login, or the company is comfortable testing explicit app-data cleanup for selected packages.

This makes 3S EMM useful for teams that need the operational savings of shared hardware but do not need the full complexity of Samsung KAM on day one.

3S EMM Approach

3S EMM uses a managed-session model inside the primary fully managed Android user. This is important:

• We do not create Android OS secondary users.
• We do not rely on deprecated or restricted Samsung multi-user APIs.
• We do not promise full per-user Android app sandbox isolation.
• We treat the active user as a 3S EMM session profile on a company-owned Device Owner device.

The current implementation has these main parts:

• The device is enrolled as a 3S EMM managed device.
• A policy enables standard.shared_device.
• When the policy is applied, the agent stores shared-device settings locally.
• If sign-in is required and no user session is active, the agent enables a special shared-device HOME launcher.
• The shared launcher opens the 3S EMM Shared Device sign-in screen.
• The worker signs in with their 3S EMM tenant user email and password.
• The backend verifies the device bearer token, organization, password, and shared-policy group membership.
• Only users who belong to a group whose policy also has shared devices enabled may sign in.
• On login, the backend assigns the device to the signed-in user's group and returns the effective policy.
• The agent applies the returned policy and releases HOME back to the normal launcher/kiosk experience.
• On sign-out, the agent clears local session state, optionally clears configured app data, calls backend logout, and returns HOME to the shared sign-in screen.
• Logout restores the device to its original shared-device group so the device is ready for the next worker.

Security Model

3S EMM shared-device login is controlled by both device policy and user policy.

A sign-in is accepted only when:

• The device is authenticated with its existing device bearer token.
• The device belongs to the same organization as the user.
• The device's current group policy has standard.shared_device.enabled=true.
• The user email/password is valid.
• The user is a member of at least one group whose assigned policy has standard.shared_device.enabled=true.

This prevents a member of an unrelated group from signing in just because they have a valid company account.

How Admins Set It Up

1. Create or choose a shared-device policy

In the admin app, open the policy editor and go to Standard Policy. Enable shared devices in the Shared devices section.

Recommended first setup:

• Shared devices: on
• Require sign-in before launcher: on
• Shared-device idle timeout: 30
• Sign out on lock: on only when the workflow is ready for it
• Public packages: keep the default 3S EMM agent package
• Cleanup packages: leave empty for first test
• Preserve packages: leave empty for first test

2. Assign that policy to a shared-device group

Create a group for the device pool, for example Warehouse Shared Phones or Prokiosk. Assign the shared-device policy to this group.

Put the physical shared devices into this group. These are the devices that should boot or return to the shared sign-in screen.

3. Allow users by group policy

Create or choose the user groups that should be allowed to sign in. Their assigned policy must also have Shared devices enabled.

This is deliberate. A user is not allowed to sign in to shared-device mode only because they exist in the tenant. They must belong to a group that is explicitly shared-device enabled.

4. Push policy to the device

Push or sync the policy. When the agent applies the policy successfully, the command result should show:

{
  "enabled": true,
  "session": "signed_out",
  "home_lock": "shared_sign_in",
  "shared_launcher_enabled": true,
  "require_sign_in_before_launcher": true
}

On the device, pressing Home should show the 3S EMM Shared Device sign-in screen.

5. Test sign-in and sign-out

Use a tenant user who belongs to a shared-device-enabled group. Sign in with email and password. The device should apply that user's group policy and open the normal launcher or kiosk experience.

Then sign out. The device should clear the local shared session, restore the shared-device group, and return to the sign-in screen.

Also test a user from a non-shared group. That user should be rejected.

Policy Values

standard.shared_device.enabled

Turns shared-device mode on or off for the policy.

When false, the agent disables the shared HOME launcher and clears local shared-session state.

When true, the agent can route the device to the shared sign-in screen.

standard.shared_device.require_sign_in_before_launcher

Controls whether the user must sign in before reaching the normal launcher.

Recommended value: true.

When true and no session is active, 3S EMM sets the shared sign-in activity as the HOME target. This prevents normal launcher access before sign-in.

standard.shared_device.idle_timeout_minutes

Planned timeout value for future automatic sign-out. Current accepted range is 1 to 1440 minutes, with 30 as the default.

Current limitation: the value is stored, but automatic idle timeout enforcement is not implemented yet.

standard.shared_device.sign_out_on_lock

Planned setting for automatic sign-out when the device locks.

Current limitation: the value is stored and delivered, but automatic lock-triggered sign-out is not implemented yet.

standard.shared_device.public_packages

Comma-separated package names that are considered public or safe in the signed-out state.

Default: the 3S EMM agent package.

Current limitation: package suspension/hide behavior for public vs non-public packages is not fully implemented in this slice. The value is already used to avoid clearing preserved/public packages during explicit cleanup.

standard.shared_device.cleanup_packages

Comma-separated package names whose app data should be cleared on explicit sign-out.

Example:

com.company.delivery,com.company.inventory

Current behavior: on Android 9+ where Device Owner APIs allow it, the agent calls DevicePolicyManager.clearApplicationUserData() for these packages during explicit sign-out. Some apps may not allow full cleanup depending on Android behavior, app state, protected roles, or device policy restrictions.

standard.shared_device.preserve_packages

Comma-separated package names that must not be cleared during sign-out cleanup even if they appear elsewhere.

Use this for core management apps, shared utility apps, or apps where data should persist between workers.

3S EMM always preserves its own agent package.

Current Limitations

3S EMM shared devices are currently a managed-session implementation, not full Android OS multi-user isolation.

Current limitations:

• No Android secondary users are created.
• App data is not automatically isolated per worker unless the app itself uses cloud identity or the package is cleaned on sign-out.
• Idle timeout is stored but not enforced yet.
• Sign-out-on-lock is stored but not enforced yet.
• Public vs private package suspension is not complete yet.
• PIN, face sign-in, and credential autofill are not implemented yet.
• There is not yet a dedicated shared session history table in production; current state is represented by device assignment and local agent session state.
• Offline sign-in is not supported by default.
• Physical app behavior depends on Android, Samsung Knox APIs, app design, and whether the app supports its own logout or account switching.

These limits are intentional for the first release. The first priority is a reliable, auditable sign-in gate and policy switch. Stronger cleanup, timeout, app isolation, PIN, and credential features can be added in later phases.

Recommended Deployment Pattern

For production, use shared devices first with role-based business apps that store user data in the cloud and already support user sign-in/sign-out. Add app-data cleanup only for apps that have been tested.

Best first deployment:

• Samsung fully managed Android devices.
• 3S EMM agent installed as Device Owner.
• One shared-device staging group for the device pool.
• One or more user groups with shared-device-enabled policies.
• Require sign-in before launcher.
• Keep cleanup list small and tested.
• Avoid offline sign-in until the security policy is agreed.
• Train workers to sign out at shift end.

Roadmap

The planned direction follows the same KAM-style product plan:

• Dedicated shared-session history and audit table.
• Admin force sign-out.
• Active session visibility in device detail.
• Idle timeout enforcement.
• Sign-out-on-lock enforcement.
• Signed-out package suspension/hide for non-public apps.
• PIN fast sign-in after first password sign-in.
• Optional app credential fill only for allow-listed apps, with encryption and user consent.
• Cross-device profile sync only after key management is designed.

The goal is practical: make one managed Android device safely usable by multiple employees while keeping setup simple for admins and predictable for workers.