Shared device management

Shared Device Management allows organizations to securely deploy a pool of shared devices to frontline, shift, or kiosk workers. Instead of assigning a permanent, distinct device to every individual user, organizations can maintain a flexible pool of shared, corporate-owned devices. This approach reduces hardware costs while ensuring that every employee receives a secure and personalized workspace during their shift.

Key features

  • Personalized Profiles: When signed in with user's work credentials, the device automatically loads user-specific apps, files, and settings.
  • Privacy & Automatic Cleanup: User session is private. When the user signs out, all local data—including app history, messages, and files—is automatically wiped, ensuring a clean slate for the next user.
  • Simple Sign-In: Users can access all work apps (like email, chat, etc) with a single sign-in. No need to log in to each app individually.
  • Stable Enrollment: Admins only need to set up the device once. It stays enrolled as a shared device, meaning it is always ready to use even when no one is signed in.
  • Constant Security: The device remains fully managed and compliant with company security rules, even during the lock screen or between user shifts.
  • Custom Branding: Admins can easily tailor the device's look and feel with the organization’s logos, colors, and welcome messages.

How It Works

A typical workflow for shared devices:

  1. The organization maintains a pool of Android tablets (for example, in charging cradles at a nursing station or warehouse dock).

  2. At the start of a shift, a worker picks up any available device and signs in using their corporate directory credentials.

  3. The system authenticates the user, fetches their role-based profile, and delivers personalized apps and configurations.

  4. At the end of the shift (or during breaks), the worker signs out. All session-specific data is securely wiped.

  5. The device returns to a clean, locked state — ready for the next user — without requiring re-enrollment.

Supported Operating Systems

MCM v3.7 supports Android devices with full multi-user workspace separation via Dedicated App/Device Owner mode.

Prerequisites

To successfully utilize the Shared Device Management feature, the deployment environment must satisfy the following system and requirements:

Category Requirement Details
Infrastructure Management Server Must be configured for HTTPS and linked to a valid Android Enterprise account.
Database An active SQL database is required to store policy settings and branding designs.
Hardware Device Type Corporate-owned Android devices.
Connectivity Reliable network access is required for users to sign in and for devices to receive updates.
Apps Required Both the BigFix UEM app and the Shared Device Frontline app must be installed.
Enrollment Setup Mode Devices must be enrolled in Dedicated Device mode.
Isolation Rule Critical: Do not combine this enrollment type with other types (such as Work Profile) within the same policy group.
Authentication Identity Provider Supports Azure Active Directory (Entra ID)
User Accounts Users must have a valid, active Azure Active Directory (Entra ID) account.
Administration Feature Setup The feature must be manually turned on in the "Feature Configuration" settings.
Access Rights IT administrators require write permissions for the WebUI configuration settings.

Administrative Setup Workflow

To successfully deploy Shared Device Management, administrators must follow a sequential configuration process. This workflow ensures that all security policies, branding, and enrollment parameters are established before devices are deployed to end-users.
Note: IT/MDM Administrators, anyone with write access to the MDM Web UI under the app configurations path (apps > MCM > admin > App configuration) can configure profiles, policy mappings, and branding parameters.

Follow these steps in the order provided to ensure a stable deployment:

  1. Configure Branding: Create the custom login interface (logos, colors, and branding) to match your organization's look and feel.

  2. Enroll Device: Set up Android devices in "Dedicated Device" mode.

  3. Create a shared device policy: Define authentication, session, and app access rules.

  4. Application and Session Configuration

  5. Deploy Policy Group: Group the policy with necessary configurations and deploy it to your devices.

Administrator Capabilities (Web UI Actions & Policies)

Through the centralized policy engine and Web UI, administrators can execute several actions:

  • Branding Configuration
    • Admins can customize the application theme to match their company's branding through Admin > App Configuration > Shared Device Branding Configuration.
    • Customizable options include the application title, colors, "About" message, copyright message, and logo uploads.
    • Currently, this customized frontline application is only supported for Android devices using the Microsoft Authentication Library (MSAL).

  • Shared Device Policy Creation and Device Restrictions:

    • The "Shared Device" policy option is available in the policy creation menu if Azure ID is configured.

      • Authentication: Currently supports Microsoft Authenticator. Future support may include Ping Directory and Okta.

      • App Registration: Admins must register the BigFix Frontline app in their Azure portal using a specific redirect URI (a JKS key) provided by the developers and configure graph API and Token claims to read User's group.

      • MSAL Configuration: After registration, the MSAL configuration string from Azure must be pasted into the policy.

    • Push dynamic security rules based on the user's group, such as disabling the clipboard, locking out camera/microphone access, tracking device location, and setting up automated logouts after a shift ends.

  • Application and Session Configuration:
    • Enrollment Type: Supported only for Android Kiosk (dedicated device) mode; the frontline app acts as the default launcher.

    • App Selection: Admins can select default applications for all users.

    • Guest Mode: Allows temporary access to a limited set of applications (e.g., for industrial visitors) for a configurable duration.

    • User Restrictions: Admins can define specific app groups for different user roles (e.g., doctors vs. nurses), which overrides default settings.

    • Shift Configuration: This is a mandatory section where admins define shift times using a 24-hour clock.

    • Session Management: Users receive a warning before their session times out (e.g., 60 seconds or 5 minutes), with an option to request a session extension.

    • Logout: Once a shift ends or a user logs out, the app automatically clears user data and returns to the login screen.

End-User Workflow (Sign In / Sign Out)

Signing In:

  1. Picks up an available device from the pool.

  2. The device displays the branded login screen (lock/sign-in state).

  3. The worker enters their corporate directory credentials in the Shared Device Authenticator App.

  4. The system authenticates the user via the configured IdP.

  5. User-specific apps, configurations, and content are delivered to the device.

  6. The device transitions to a personalized signed-in session.

Signing Out:

  1. The worker opens the Shared Device Frontline App and taps Sign Out.

  2. The system terminates the user session.

  3. All session-scoped data is cleaned:

    • App data and caches

    • Locally stored documents

    • SMS, call history, device contacts

    • Session tokens and cached authentication artifacts

  4. The device returns to the branded lock/sign-in screen.

  5. Enrollment and device-wide policies remain intact.

Known behaviors

  • Kiosk Mode Conflicts: Shared Device mode should not be concurrently layered on top of restrictive Kiosk constraints without ensuring the Shared Device app itself is permitted to run over the layout.

  • In-Progress Asset Blocks: To prevent broken image layouts on the endpoints, administrators are blocked from attaching a branding configuration to an active policy deployment if the background BigFix file upload process is incomplete.

Troubleshooting & Warnings

  • Deployment Warnings: If an admin creates a new Shared Device Policy while an underlying branding asset/fixlet action is still processing in the background, a warning notification will flag on the WebUI policy creation page.

  • Verification Checks: If branding assets fail to load on the target device, navigate to WebUI to ensure the branding configurations have fully merged with the core Shared Device Policy managed configuration payload (schema validation check). Ensure that the target URLs (brandLogoUrl, appBackgroundUrl) securely pointing to the <mdm-server> or CDN locations match the stored records inside the MSSQL database.