Migrating frontline mobile devices: Identity considerations for assigned and shared devices
By: Carol Burns - Principal Product Manager | Microsoft Intune and Sucheta Gawade, Microsoft MVP (Azure & Security / Intune) Practitioner perspective from Sucheta Gawade, Microsoft MVP (Azure & Security / Intune), with deep experience in secure frontline mobility, including regulated healthcare environments. In previous articles in this series, we focused on understanding the reality of your frontline device estate and preparing for real-world testing through stakeholder alignment. One of the most critical areas to get right during the testing phase is identity and security, particularly given the often fast-paced, shift-based nature of frontline work, where organizations must account for the distinct requirements and challenges of devices assigned to a single individual versus devices shared across multiple users or shifts. Identity decisions directly affect security posture, sign‑in experience, operational support overhead, and worker productivity. Getting them wrong is one of the most common reasons pilots stall or fail. This article explores how to think about identity on frontline devices by distinguishing between assigned and shared usage models, clarifying when individual sign-in is required, and highlighting patterns to avoid such as shared accounts and passwords. Start by distinguishing device usage models Frontline mobile devices generally fall into one of two broad categories. Assigned devices Assigned devices are issued to a specific individual, often for the duration of their role. These devices: Typically require persistent access to user‑specific data Align with user‑based identity, Microsoft Entra ID Conditional Access, and audit controls. Enable greater accountability and traceability by associating activity with an individual user rather than a shared credential. Common examples include: A doctor using an individually assigned clinical tablet, where uninterrupted access to patient data and clinical systems is essential and actions must always be attributable to a named identity A field engineer assigned a single device that retains configuration, credentials, and offline content across jobs and locations An inspector or supervisor using an assigned device for approvals, reporting, and decision‑making that requires traceability Shared devices Shared devices are used by multiple people across shifts or tasks. These scenarios introduce additional identity complexity and generally fall into two distinct models. Shared devices without user sign-in (task or kiosk-based) Some frontline devices exist to perform a narrow, often repetitive task and don’t require sign in with a user account. Typical examples include: Retail price-check devices used on the shop floor to scan an item and display its current price or stock availability, with no need for access to personal or user-specific information Environmental monitoring devices used to read and record temperature or humidity in a storage area, ward, or vehicle, where the task is simple, repetitive, and not tied to an individual user identity Warehouse or facility scanning devices used for a narrow operational task such as scanning an asset, bin, or location code to confirm status, location, or completion of a step in a process In these cases: Devices are locked down to a specific task No user-specific data is stored, and access is limited to the minimum required for the task “When a device is truly task-only, removing sign-in friction is a huge win, but only if we’re aware what data the device can access. When things like patient context or personalized tasks enter the picture, identity becomes required” - Sucheta Gawade, Microsoft MVP Shared devices with individual user sign-in Organizations are increasingly digitizing and modernizing frontline workflows end-to-end. Paper processes and simple apps give way to connected systems, manual handovers are replaced with digital task lists, and workers begin to rely on mobile devices as their primary interface from completing tasks. As roles evolve, workers are expected to: Receive tasks, schedules, and updates digitally Communicate with supervisors and peers using collaboration tools such as Microsoft Teams Capture information at the point of work rather than transcribing later Interact with workflows that are increasingly automated or assisted by AI, such as guided steps, data validation, or suggested actions This shift delivers clear productivity and quality benefits, but it also means access must now be tied to individual identity to protect sensitive data, support auditability, and prevent information from being carried over between users. Common scenarios include: Retail store associates rotating across shifts, moving from paper schedules and verbal handovers to digital task lists, real-time communications, and collaboration tools such as Microsoft Teams Nurses sharing mobile devices in a hospital ward, where paper notes and whiteboards are replaced with secure access to patient-linked applications, care coordination tools, and role-based alerts Logistics workers signing in to shared devices to complete role-based tasks, capture data at the point of work, and interact with AI-assisted workflows. Don’t use shared credentials, always prefer individual sign-in Shared credentials may seem like a shortcut in frontline environments, but they undermine accountability and make policy enforcement and incident response significantly harder. “Shared credentials feel ‘efficient’ until your first incident. You lose auditability, Conditional Access becomes meaningless, and investigations turn into guesswork. Individual identity is the only scalable model.” -Sucheta Gawade, Microsoft MVP If access involves corporate systems or sensitive data, each worker should use their individual credentials to sign in, even on a shared device. Identity decision checklist for frontline devices Use the checklist to validate identity choices and confirm that the overall security posture matches the way the device is used. Decision area Indicators Use individual sign-in Users access personal or role-specific data. Auditability or compliance is required. Conditional Access or multifactor authentication (MFA) must be enforced. Applications rely on user identity. Use kiosk-style or device-only identity Devices perform a single task. No user-specific or sensitive organizational data is accessed. Workflows are entirely device-centric. Speed and simplicity outweigh personalization. Avoid entirely Shared usernames or passwords. Reused local accounts across shifts. MFA exclusions that weaken security without compensating controls. Choosing the right sign‑in experience The challenge in frontline environments is balancing: Security requirements Speed of access Ease of use across shifts “Frontline setups may fail because the sign-in flow doesn’t match reality. If authentication takes 60 seconds and the worker has to do it 30 times a shift, they’ll find a workaround.” -Sucheta Gawade, Microsoft MVP Typing complex usernames and passwords repeatedly during a shift is often impractical on mobile devices. QR code authentication is one effective option for shared frontline devices, but it’s not the only supported approach. For other supported methods, see Microsoft Entra authentication methods overview. QR code authentication Microsoft Entra QR code authentication is designed for frontline workers to sign-in efficiently on shared Android and iOS/iPadOS devices without repeatedly entering usernames and passwords. Note: For individually assigned devices, phishing-resistant, passwordless authentication methods are the recommended approach, such as Passkeys. QR code authentication enables workers to sign in using a unique QR code and a personal numeric PIN. This approach: Eliminates typed usernames and passwords Preserves individual identity Works well for shared devices with frequent user turnover Integration with Microsoft Intune, Managed Home Screen and Conditional Access QR code authentication should always be: Scoped to specific users and devices Combined with Conditional Access policies Evaluated during real‑world testing to ensure the right balance of usability and security Security posture and Conditional Access for frontline devices Individual identity is a critical foundation for stronger security posture, but it’s not enough on its own. Frontline device security also depends on management, data and app protection, session handling, and access policies that reflect the actual usage model. Conditional Access is an important part of securing frontline environments, but its effectiveness depends on aligning policies to the actual device and identity model in use. To ensure that the QR code authentication method can only be used by the frontline workers it’s intended for, create a custom authentication methods policy, which you can use in a dedicated Conditional Access policy. That Conditional Access policy should then be scoped to the group of users (frontline workers) who should log on using the QR code authentication method, and have the Require authentication strength control configured, which targets the custom authentication strength for "QR Code" which was previously created. During real‑world testing: Validate that design and controls support the intended usage model Ensure policies don’t block legitimate workflows Confirm sessions, access, and user targeting behave as expected These decisions should also be validated in practice: can users sign in and out reliably across shifts, is personal data cleared between sessions, and does the chosen experience match the pace of frontline work? Summary This article walks through how identity choices shape security, usability, and day-to-day success for frontline mobile devices. It explains the difference between assigned and shared devices, when individual sign-in is needed, and why shared credentials can create risk. It also highlights QR code authentication and Conditional Access as practical ways to keep each worker’s identity protected while making sign-in simple enough for fast-paced frontline workflows. What’s next in the series In the next article, we’ll focus on Microsoft Intune enrollment models, exploring how different enrollment approaches support—or constrain—the identity and usage patterns discussed here, including their role in protecting session identity, enforcing the intended sign-in model, and preventing one user’s access or data from carrying over to the next. As always, we welcome your feedback and experience. If you’ve navigated identity decisions for shared or frontline devices, share your advice and lessons learned in the comments, or reach out to us on X @IntuneSuppTeam. For more guidance across frontline scenarios, explore our broader From the Frontlines series on frontline worker management with Microsoft Intune. Join our community! Discuss real-world scenarios, get expert guidance, connect with peers, and influence the future of Microsoft Security products. Learn more at aka.ms/JoinIntuneCommunity.Windows Early Launch Anti-Malware Detection Issue and Intune Compliance
First published on TechNet on May 04, 2017 Murali Krishna Hosabettu Kamalesha | Program Manager, IntuneIf you’re managing Windows using mobile device management, and if you’re targeting those devices with conditional access policies, there’s a known issue we wanted to make you aware of with the Windows early launch anti-malware (ELAM) driver.
