Shared and Multi-User Device Configuration in Hexnode UEM

Why are shared devices difficult to manage across users and shifts?

Shared devices require consistent device settings while accommodating changing users, access requirements, and session data. Each handover introduces another set of requirements for identity, applications, and information that should persist or disappear.

For endpoint administrators, these requirements create familiar problems. An employee starts a shift and finds the previous user’s application session still active. Another signs in but cannot access a required application. Others wait while IT prepares devices for the next team.

Shared device configuration must establish a reliable baseline without treating every user’s needs as identical. Administrators need to define which settings apply across the device, what each person can access, and what happens to their sessions and local data when they finish using it and leave the device.

What happens when shared-device handovers lack clear controls?

Poorly controlled handovers can expose previous users’ information, interrupt work, and increase troubleshooting. An active application session may let the next person access records or perform actions under someone else’s identity.

Generic credentials weaken accountability because activity under one account may represent several people. Meanwhile, retained profiles and downloaded files consume storage, potentially leaving less capacity for applications and new sessions.

These problems translate into delayed shift starts, repeated access requests, and additional support work. Track handover time, failed sign-ins, support tickets, and incidents involving retained information to assess their operational impact. Record which devices and applications generate recurring issues so administrators can identify where handover controls need further investigation and correction.

What is shared device configuration?

Shared device configuration coordinates identity, applications, restrictions, storage, and session behavior on devices that multiple people use. It establishes a consistent operating environment while defining how users access resources and what happens to their information afterward.

Sharing hardware does not require sharing credentials. Individually authenticated sessions support personalized access and accountability. Anonymous guest access suits workflows that require temporary device use without a persistent personal profile, although individual applications may still require authentication.

Configuration also operates at different levels. Device-wide settings establish common restrictions and connectivity. User-specific settings govern individual preferences and access. Application sessions maintain their own authentication state and data. The operating system and application design determine which controls administrators can enforce and whether ending a device session also ends application access or removes locally stored information.

Persistent accounts, temporary sessions, and kiosks serve different needs

Choose a sharing model according to whether users need continuity, temporary access, or a restricted task environment. These models address different requirements and can overlap: a kiosk application may still require individual authentication.

Persistent profiles help returning employees resume work. Temporary sessions prioritize short-term access. Kiosks constrain available functionality.

Kiosk restrictions do not inherently create separate user identities or guarantee application-data cleanup. Administrators must configure and test authentication and cleanup independently.

Platform capabilities determine the sharing model

Platform selection must account for supported account types, enrollment prerequisites, storage behavior, and session termination. A design that works on one operating system may require different controls or application behavior on another.

Windows Shared PC illustrates these differences. When administrators configure account management, Windows can delete profiles at sign-out or according to storage and inactivity thresholds. Temporary Guest accounts undergo deletion at sign-out, while organizational profiles can remain cached until the configured cleanup conditions apply. This distinction affects both return-user convenience and local data retention.

Before choosing a design, verify the OS version, edition, management mode, and application compatibility against the required controls. Confirm whether applications support the intended account model and where they retain information. Test the actual sign-out and cleanup behavior on representative devices; do not assume that similarly named sharing features provide equivalent isolation or retention controls.

How do you configure shared devices for secure, reliable handovers?

Define the sharing model, establish identity and application requirements, configure session controls, and test complete handovers before rollout. Each decision should reflect how people use the devices and what information they leave behind. Follow these four steps to translate those requirements into a shared device configuration that endpoint administrators can validate, maintain, and apply consistently across the intended device pool.

1. Map users, tasks, and persistence requirements

Inventory device locations, operating systems, shift patterns, expected users, and required applications. Identify whether employees return to assigned hardware or select any available device from a pool.

Classify the information each workflow produces:

• Retain: Preferences or working files that returning users need.
• Synchronize: Business records that must reach an approved central service.
• Remove: Temporary downloads and session information that subsequent users must not access.

Record hardware capacity, available storage, enrollment requirements, network dependencies, and identity prerequisites. Confirm which tasks must continue during connectivity interruptions and where applications store work until synchronization resumes. Use these findings to define requirements for each device group before selecting account settings or session cleanup rules.

2. Establish identity and application access

Choose individual organizational accounts when workflows require personalized permissions and accountable activity. Use temporary guest access where users need short-term device access without persistent profiles. Limit routine users’ privileges to the tasks they perform.

Define whether each application requires device-wide installation or user-specific provisioning. Check licensing requirements for shared use, then verify that every intended user can launch the required applications with appropriate permissions.

Test application authentication separately from device authentication. Signing into the operating system does not establish how every business application handles identity. Document how users sign out of each application and test whether device session termination removes or preserves credentials. Confirm that the next user cannot resume the previous person’s authenticated application session through cached tokens or restored tabs.

3. Configure session endings and data retention

Define what each session-ending action must accomplish:

• Screen locking restricts immediate access but keeps the current session active.
• Signing out ends the user session; data retention depends on platform and application behavior.
• Profile deletion removes the selected local profile and its associated information.
• Device reset returns the device toward its initial state, with scope depending on the reset method.

Set inactivity limits, supported session-duration controls, profile-retention rules, and storage thresholds to match the sharing model. Keep lock timers separate from logout and cleanup requirements.

Before applying deletion rules, test unsynchronized work, downloads, browser sessions, and application caches. Confirm that required records reach their destination before cleanup occurs and define how users handle synchronization failures. Removing local-only data does not delete cloud records, but deleting files from actively synchronized folders can propagate deletions to the cloud. Verify synchronization behavior before cleanup. Manage those records through the relevant application’s retention controls and communicate any potential loss of unsaved local work.

4. Pilot handovers and define operating checks

Pilot the configuration on representative devices using a complete handover sequence:

1. Sign in as the first user.
2. Open required applications and create test data.
3. End the session through the intended mechanism.
4. Sign in as a second user.
5. Inspect for residual access, files, and application sessions.

Repeat the checks with abandoned sessions, reboots, low storage, connectivity loss, and unsynchronized work. Record expected and actual outcomes, including any information that remains accessible.

Set acceptance criteria for sign-in time, application readiness, and cleanup behavior. Track related support incidents during the pilot and after deployment. Define recovery procedures for access failures and interrupted synchronization, alongside a rollback procedure for configuration problems, before expanding deployment to additional device groups or locations with different operational requirements.

How does Hexnode UEM support shared device configuration?

Hexnode UEM provides configuration paths for Shared iPad, Windows Shared PC settings, and ChromeOS Managed Guest Sessions. These platform-specific approaches address different identity and data-persistence requirements. Administrators should select controls that match their devices, supported operating systems, and intended handover behavior, then validate the resulting experience with representative users and applications.

Featured Resource

Hexnode UEM: An inside look

Explore how Hexnode UEM simplifies device management, security, app deployment, and cross-platform administration.

Download the Infographic

Shared iPad settings configure user and guest experiences during enrollment

Configure Shared Device Settings through Enroll > iOS > Apple Business or School Manager > Enrollment Profile > Create Enrollment Profile. These settings form part of Automated Device Enrollment (ADE) for devices synchronized through Apple Business Manager or Apple School Manager.

Within the enrollment profile, select Enable Supervision under General Settings > Device Settings to make Shared iPad settings available. Configure the sharing behavior before users complete initial device setup.

Choose the mode according to your persistence requirements:

• User Mode: Supports multiple Managed Apple Accounts and locally cached user data. Allocate storage using Expected Number of Users or Per-User Quota, depending on the selected allocation method.
• Guest Mode: Provides temporary sessions without a Managed Apple Account and removes guest-session data at sign-out.

Configure Auto-Lock to lock the device after inactivity. Use User Timeout or Guest Timeout to sign out an inactive session. Both timeout controls require iPadOS 14.5 or later.

Keep these outcomes distinct when testing handovers: locking preserves the active session, while guest sign-out triggers session-data removal. Choose timeout values that accommodate task completion without leaving abandoned sessions available.

Windows Shared PC settings govern account models and profile cleanup

Hexnode’s Custom Configuration (OMA-URI / CSP) policy deploys Windows SharedPC CSP settings. Windows implements the underlying account-management behavior.

The relevant controls include:

• EnableSharedPCMode: Activates Shared PC mode.
• DeletionPolicy: Selects immediate deletion, disk-space-based deletion, or disk-space and inactivity conditions.
• InactiveThreshold: Defines inactivity in days.
• DiskLevelDeletion: Sets the free-space percentage that triggers cleanup.

Deploy SharedPC CSP settings through Hexnode’s Windows Custom Configuration policy, using Microsoft’s CSP documentation to determine payload requirements and configuration dependencies. Windows Shared PC mode supports Guest Only, Domain Only, and Guest + Domain account configurations. Administrators should verify the required CSP settings and their compatibility before deploying them through Hexnode’s Windows Custom Configuration policy.

Hexnode documents Windows Custom Configuration support for Windows 10 and Windows 11 Pro, Enterprise, and Education; verify each CSP node’s additional compatibility requirements before deployment. Verify the target Windows version and edition against Microsoft’s node-specific SharedPC CSP requirements before deploying the configuration through Hexnode UEM. Verify the target OS and edition against Microsoft’s node-specific requirements before deployment.

For account visibility, select a Windows device under Manage, run Actions > Sync Local Accounts, and open Local Accounts. Review account names, roles, local or network account types, and login status. Keep the Hexnode UEM app current on the device. This synchronization updates account visibility; it does not activate automatic profile cleanup or replace the SharedPC account-management configuration.

ChromeOS Managed Guest Sessions provide controlled temporary access

Configure ChromeOS guest access through Policies > New Policy > ChromeOS > Managed Guest Session > Basic. Managed guest sessions let users access the device without signing in with a Google account.

Use the session controls to define startup and handover behavior:

• Auto launch managed guest session: Starts the session automatically when the device starts.
• Auto-launch delay: Sets the waiting period before automatic launch.
• Session length limit: Automatically logs users out after the configured duration, ending the session.

Under Add App > Web Apps, select applications from the app inventory. Choose Forced install when applications must be available, and specify whether they launch in a New tab or New window.

Assign the policy through Policy Targets > Domains/OUs, selecting the appropriate organizational units under the integrated Google Workspace account.

Treat guest device access separately from business-application authentication. An application may still require individual credentials. Test its sign-in and sign-out behavior within the managed session before approving the configuration for shared use.

FAQs

Evaluate your shared-device workflow with Hexnode UEM

Evaluate one representative device pool against your required sign-in, application-access, retention, and handover criteria. Confirm that the selected platform controls produce the expected experience for both returning users and temporary visitors.

Use the evaluation to document configuration gaps, application dependencies, and questions about session behavior. Bring your platform mix, identity requirements, and data-persistence expectations to a product walkthrough so you can assess the relevant configuration paths against the workflows your administrators need to support.