From the frontlines: Frontline worker management with Microsoft Intune
So, here we are. You’ve been asked to start managing frontline devices for your organization with Intune. You may be a pro with Intune management - with experience managing Windows devices, personal mobile devices, or corporate-owned productivity user based mobile devices. Maybe you just completed your migration efforts from another product to Intune for some portion of your device estate. Or this may be your first interaction with Intune. Regardless of where you’re starting from, managing frontline worker devices in Intune is simple, and you can even leverage existing Intune policies you already configured. So, get out that rugged bar code scanner, Android tablet, kiosk device, shared iPad, wearable device, or any other frontline worker device and let’s get started! My name is Dan Andersen, Principal PM Manager at Microsoft. My team partners directly with engineering to assist in product development and our worldwide team has assisted over 1,800 enterprises successfully onboard their device scenarios into Intune. In this post I’m introducing a blog series focused on frontline worker (FLW) device management. Why focus on FLW? This space represents a multitude of devices and use-cases that have enabled frontline workers, and we’ve worked with others like you to craft great FLW solutions. We will use this series to share these solutions and options with you and hopefully make your FLW journey with Intune seamless and exciting. Before getting into the series, if you’re looking for some background on FLW usage examples, check out the Microsoft Intune Blog: Microsoft Intune empowers frontline workers in retail and beyond. Throughout this year we’ll deliver monthly blogs delving into FLW use-cases and how to manage these devices. We’ll dive into key scenarios and explain how to approach them and at times, specifically how to configure them. Instead of rewriting product documentation, we’ll include links to more details when applicable, and keep the posts focused on enabling success. Each blog post will be published here in the Microsoft Intune Customer Success blog and include “From the Frontlines:” in the title for easy searching. For quick reference, we’ll keep this table updated as we publish the series, so stay tuned here or follow us @IntuneSuppTeam on X for more in the coming months! Blog topic Publish date From the frontlines: Revolutionizing healthcare worker experience February 28, 2025 From the frontlines: Accelerating retail worker shared device experience (Part one) March 25, 2025 From the frontlines: Accelerating retail worker shared device experience (Part two) April 23, 2025 From the frontlines: Delivering great dedicated device experiences for retail workers May 28, 2025 From the frontlines: Managing warehouse devices with Microsoft Intune July 01, 2025 From the frontlines: Managing common kiosk scenarios in your business August 28, 2025 From the frontlines: Delivering critical early responder device management September 30, 2025 From the frontlines: Empowering call center agents with Windows 365 Frontline October 31, 2025 Migrating frontline mobile devices: A frontline-first approach to moving to Microsoft Intune March 30, 2026 Migrating frontline mobile devices: Understanding the reality of your estate April 15, 2026 Migrating frontline mobile devices: Aligning stakeholders before real-world testing May 1, 2026 Migrating frontline mobile devices: Identity considerations for assigned and shared devices July 1, 2026 Designing Intune enrollment for frontline workers: Choosing the right path for real-world devices July 23, 2026Designing Intune enrollment for frontline workers: Choosing the right path for real-world devices
By: Shawn Catlin – Senior 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. Enrollment methodology is one of the most consequential design decisions teams make for frontline environments. It shapes how devices are used, how identity is handled, how failures are recovered from, and how much friction workers experience before they can do their jobs. Frontline use cases aren’t limited to shared devices. They can span nearly every enrollment type available in Microsoft Intune, including user-assigned, shared, dedicated, kiosk, corporate-owned, BYOD, and zero-touch deployment models. The right choice is often influenced by business need, operational workflow, budget, support model, and security requirements. But it must also account for platform and operating system design. Android, iOS, and iPadOS may offer similar enrollment concepts, but they don’t always behave the same way or support the same management patterns. That distinction matters. A kiosk or dedicated-device model, for example, is intentionally designed for a locked-down, task-focused experience. It manages the device around a specific function, not around a personalized user workspace. In that model, broad app availability, persistent personalization, and user-driven app installation are not the primary management paradigm. Similarly, a shared-device model should not be selected simply because an organization cannot provide a dedicated device to every worker. If identity, app access, compliance, or user context are required, those needs must be part of the enrollment decision from the beginning. There is no copy-and-paste frontline enrollment strategy that works across every industry, business unit, or device scenario. Some frontline devices are shared across shifts and must remain reliable where connectivity, identity, and support are not guaranteed. Others are assigned to supervisors, clinicians, field workers, or shift leads who need persistent access to apps, settings, and data. When enrollment choices are made without accounting for these realities, especially platform differences and OS-level limitations, friction surfaces quickly during pilots and scales painfully during rollout. This article explains how to approach Intune enrollment for frontline devices through a practical, reality-first lens: start with how the device is used, align the management model to the workflow, and then plan how the device will be enrolled, replaced, and reprovisioned at scale. “In a hospital environment, frontline does not mean one type of device or one type of worker. A shared clinical workstation, a nurse’s mobile device, a patient check-in kiosk, a barcode scanner, and a supervisor’s assigned device may all be considered frontline, but they each have very different identity, security, app, and recovery requirements. That is why enrollment decisions have to start with the workflow. Sucheta Gawade Practitioner Enrollment Is a Design Decision, not a Checkbox Enrollment does more than bring a device under management. It defines how the device is expected to work, where the security boundary sits, how identity is applied, and what recovery looks like when something fails in the field. There is no single “best” enrollment model for frontline. There is only the model that best fits how the device is actually used. The right choice depends on whether the device follows a person, a shift, a task, or a business process. It also depends on how much identity matters to the experience, whether apps need to be personalized, whether Conditional Access or compliance is required, and how quickly the device must be replaced or recovered. This is why many problems that look like policy, app, or configuration failures are actually enrollment design problems in disguise. A device can be successfully enrolled and still be poorly designed for the job it needs to do. “A device can be successfully enrolled and still fail the workflow. If a shift worker cannot access the right app quickly, if a shared device retains the wrong user context, or if a replacement device cannot be brought online during a shift, the issue may look like an app or support problem. In reality, it often traces back to an enrollment model that did not match the workflow. Sucheta Gawade Practitioner Separate Two Decisions: Management Model and Provisioning Method Frontline enrollment planning becomes easier when teams separate two related but different decisions. The first decision is the management model. This is the architectural choice. It answers questions such as: Does the device need to represent a specific person? Is the device shared across multiple workers? Is it dedicated to a narrow task or workflow? Does the device require personal apps, persistent settings, or user-specific data? Does the workflow require Conditional Access, compliance, auditability, or individual identity? This decision determines whether the device should be user-associated, shared, dedicated, kiosk-style, personally owned, or corporate-owned with a work profile. The second decision is the provisioning and reprovisioning method. This is the lifecycle choice. It answers questions such as: How will the device get into management the first time? Will it be staged by IT, a depot, a partner, or the site? What happens after a wipe, repair, refresh, or reassignment? Can the device recover without a specific user’s credentials? Will Wi-Fi, certificates, tokens, apps, and policies be available at first boot? Zero-touch, pre-staging, depot workflows, and reprovisioning plans support the selected management model. They should not replace the decision about which model is right for the scenario. Start With How the Device Is Used In the previous article, Migrating Frontline Mobile Devices: Understanding the Reality of Your Estate, we discussed why successful frontline migrations begin with understanding how devices are actually used in the field. That discovery work should now feed directly into enrollment design. The most reliable starting point is not the department, license, or ownership model. It is the device’s behavior in the field. Ask: Does this device follow a person? Does it follow a shift? Does it follow a task? Does it need to know who the user is? Does it need persistent user context? Does it need to be quickly replaced with minimal IT involvement? Does the platform support the experience you expect? The answers help map real-world requirements to the right Intune enrollment approach. Before selecting an enrollment model, organizations should also understand how identity is expected to function on the device. If you have not yet reviewed assigned versus shared identity patterns, see our previous article, Migrating frontline mobile devices: Identity considerations for assigned and shared devices, which explores how user identity, authentication, auditability, and device ownership assumptions can influence frontline management decisions. Decision indicator Usually points toward Validate before choosing One person regularly uses the device and needs persistent apps, settings, approvals, or data User-driven or user-associated enrollment Whether identity and personalization are truly required for the workflow Multiple workers use the same device across shifts and need individual sign-in Shared or device-first enrollment with identity support How sign-in, sign-out, session cleanup, and auditability will work The device performs a narrow, repeatable task Dedicated or kiosk-style enrollment Whether the workflow can operate with a locked-down app set and minimal user choice The device needs corporate control but may allow limited personal use Corporate-owned work profile where supported Whether the OS supports the expected separation between work and personal data The device is personally owned and only work data needs to be protected BYOD / personally owned work profile / user enrollment Whether the workflow can tolerate limited organizational control The device must be replaced quickly with minimal IT involvement Pre-staged, zero-touch, or easily reprovisioned device-first model Reset behavior, network readiness, certificate delivery, and replacement speed The environment has inconsistent connectivity or limited support Simpler enrollment paths with fewer live dependencies What the device needs at first boot, during sign-in, and after wipe or reset Map Frontline Scenarios to Enrollment Models A practical Intune strategy starts by accepting that frontline is not one scenario. It is a collection of scenarios. Standardization is important, but standardizing on one enrollment method for every frontline use case is rarely the right goal. Mature organizations standardize the decision framework, not necessarily the deployment model. Device usage pattern Typical characteristics iOS/iPadOS enrollment Android enrollment User-assigned device One person regularly uses the device and needs personalized apps, settings, and data Automated Device Enrollment with user affinity Android Enterprise Fully Managed or Corporate-Owned Work Profile if personal use is permitted Shared device with individual sign-in Multiple workers share the device and sign in with their own identities Automated Device Enrollment with Microsoft Entra Shared Device Mode; Shared iPad when multi-user iPad support is required Android Enterprise Dedicated Device with Microsoft Entra Shared Device Mode Dedicated or task-based device Device performs a specific function and does not require a personalized user experience Automated Device Enrollment without user affinity, with supervised device and app restrictions Android Enterprise Dedicated Device Android device without Google Mobile Services Corporate-owned specialty device, often shared or task-focused Not applicable Android AOSP userless or AOSP user-associated enrollment Personally owned device Employee-owned device used for work BYOD User Enrollment Android Enterprise Personally Owned Work Profile Zero-touch or pre-staged deployment Corporate-owned device that needs scalable provisioning or replacement Automated Device Enrollment through Apple Business Manager or Apple School Manager Android Zero-touch Enrollment, Samsung Knox Mobile Enrollment, or equivalent supported provisioning path If the device follows a person, choose a model optimized for identity and personalized access. If the device follows a shift, workflow, or task, choose a model optimized for simplicity, consistency, and easy replacement. If you’re looking for more platform-specific guidance please see frontline enrollment resources for both Android and iOS/iPadOS: Get started with Android frontline worker devices Get started with iOS/iPadOS frontline worker devices These resources provide detailed implementation guidance, recommended enrollment approaches, and platform-specific considerations for frontline deployments. Platform and OS Differences Matter Teams often assume that similar enrollment concepts behave the same way across platforms. They do not. On Android, a shared frontline device that needs a locked-down experience and individual worker sign-in often maps to Android Enterprise Dedicated Device with Microsoft Entra Shared Device Mode. Android Enterprise Dedicated Device provides the task-focused management model. Entra Shared Device Mode adds the identity layer so workers can sign in as themselves. Intune Managed Home Screen then helps present a consistent launcher experience and enforce the sign-in flow between shifts. On iPadOS, a shared device with individual sign-in may be designed using Shared iPad for Business or Automated Device Enrollment with Microsoft Entra Shared Device Mode. The distinction becomes important when security requirements are involved. Shared iPad can support multi-user scenarios, but organizations should review its limitations carefully, especially if Conditional Access or device compliance enforcement is required. Where Conditional Access, compliance, and security-driven access controls are mandatory, ADE with Entra Shared Device Mode may be the better fit, although it introduces additional configuration considerations and dependency on compatible apps. See Shared iOS and iPadOS devices for more information. Platform differences also matter for corporate-owned devices that allow personal use. Android Corporate-Owned Work Profile provides a native work profile boundary between corporate and personal data. iOS and iPadOS do not provide that same OS-level separation for corporate-owned personally enabled devices, so organizations often rely more heavily on app-level controls and MAM policies. The practical point is simple: choose the enrollment model that fits the workflow, but confirm that the platform supports the management pattern you expect. “One of the most common mistakes I have seen is designing for the cleanest administrative model instead of the messiest operational reality. In FLW cases, the real test is not whether the device enrolls successfully on day one. It is whether the device can keep supporting the workflow after shift changes, network changes, app issues, wipes, repairs, and urgent replacements. Sucheta Gawade Practitioner When User-Driven Enrollment Makes Sense User-driven enrollment still has a place in frontline, but the use cases are narrower than many teams expect. It makes sense when the device needs to reflect a specific person, not just a task. This can work well for shift managers, supervisors, clinicians, field workers, or frontline leads who need persistent access to apps, approvals, notifications, data, and settings. In these cases, user-driven or user-associated enrollment can provide cleaner app targeting, stronger identity context, and a more familiar experience for the person carrying the device. Common indicators include: The worker keeps the device for most of its working life. The user needs email, Teams, approvals, or real-time app badges. The workflow depends on user-specific apps, settings, or data. The device may support some personal enablement where the platform supports separation. The worker is responsible for keeping the device available, charged, and ready for use. But personalization comes with operational cost. User-driven enrollment increases dependency on credentials, adds friction when sign-in steps fail, and makes recovery more complex when a device must be replaced quickly. It is usually a poor fit for shared workflows, high-turnover roles, or task-based devices where speed and predictability matter more than personalization. Designing for Shared and Shift-Based Devices Shared and shift-based devices are passed from one worker to the next. They are expected to stay productive across handoffs and often operate in environments where there is little time for sign-in friction or troubleshooting. For these scenarios, device-first enrollment usually aligns better with reality because the device is treated as a managed tool for a shared workflow, not as a personal endpoint tied to one individual. The goal is consistency: the next worker should be able to pick up the device, authenticate if required, and get to work without recovering from leftover state or complex setup steps. If shared devices require individual sign-in, identity must be designed into the enrollment model. Microsoft Entra Shared Device Mode and QR code authentication can help preserve individual identity without forcing workers through a full username and password flow at every handoff. This is especially relevant in environments such as retail, healthcare, warehousing, and field operations where shared devices still need auditability, Conditional Access, app access, or user-specific sessions. Shared-device success does not come from default settings alone. Teams should define: How sign-in and sign-out should work. What user context should persist. What should be cleared between sessions. Which apps need to support shared-device behavior. How quickly a device can be swapped or reprovisioned. Whether access depends on the user, the device, the app session, or a combination. “Especially in healthcare and clinical settings, shared devices have to be absolutely ready for the next worker, the next patient, and the next task. There is rarely time for complex recovery steps, unclear ownership, or leftover user state from the previous shift. A good shared-device design should support quick handoff, clean session behavior, and predictable recovery under pressure. Sucheta Gawade Practitioner Dedicated and Kiosk Devices: Avoid Personalization Drift Dedicated and kiosk-style enrollment is ideal when the device performs a narrow, repeatable function and individual identity is secondary or unnecessary. Examples include scanners, point-of-sale systems, check-in kiosks, digital signage, inventory devices, and task-specific handhelds. The strength of kiosk-style design is that it limits choice. That is also the boundary teams must respect. A kiosk is not intended to behave like a general-purpose device where users browse a catalog of available apps, personalize settings, or install what their business unit needs on demand. A common friction point occurs when organizations try to simplify IT support with one shared kiosk configuration for multiple businesses or personas, and then expect users to install the apps they need. That creates a mismatch. User-installed available apps are not the kiosk paradigm. If each business unit needs a different set of apps, the better design is usually to do the work upfront: segment the device scenarios, define the required app sets, and deploy the right configuration to the right devices. This is also important for identity and certificates. User certificates, persistent user sessions, and shared secrets can conflict with the assumptions of a device-first or kiosk model. If the workflow requires user identity, auditability, or user-specific access, that requirement should be addressed through the right shared-device identity pattern, not bolted onto a kiosk design after the fact. Enrollment at Scale: Plan for Provisioning and Replacement Once the right management model is selected, teams should plan how devices will be enrolled and reprovisioned at scale. At scale, enrollment becomes a lifecycle capability. The question is not only how a device gets into management the first time. Instead, it is how quickly that same device can be staged, replaced, wiped, repaired, reassigned, or reintroduced into service. Some organizations ship devices directly to frontline locations and complete setup during out-of-box experience. Others rely on depot, partner, or white-glove processes to front-load setup before the device reaches the site. Neither model is automatically better. The right choice depends on network readiness, site support, variability at first boot, app dependencies, certificate delivery, and replacement expectations. Replacement velocity is a real design constraint. In many frontline settings, a broken device cannot wait for a full troubleshooting cycle. A worker may need to drop one device at a charging bay and pick up another with minimal disruption. The more the enrollment and reprovisioning model supports a known-good state, the less productivity depends on one specific device surviving the shift. Common Friction Points in Frontline Enrollment Frontline enrollment problems are rarely caused by one dramatic failure. More often, they come from reasonable decisions made in the wrong order or optimized for the wrong thing. Friction point Why it happens Better design approach Treating frontline as only shared The organization assumes all frontline workers use devices the same way Segment by workflow: person, shift, task, or business process Choosing shared because dedicated devices are too expensive Budget drives the model before identity and workflow are understood Validate identity, app, compliance, and recovery needs before choosing shared Using kiosk for personalized workflows Kiosk seems simple and locked down Use kiosk only when the workflow is task-focused and does not require broad personalization Wanting available apps on kiosk devices One configuration is used for too many personas Build scenario-specific app sets and configurations instead of relying on user installation Using shared credentials Enrollment was not designed for individual identity Use Entra Shared Device Mode, QR code authentication, or another supported identity pattern Requiring user certificates on device-first or kiosk scenarios Security assumptions are copied from knowledge-worker designs Validate whether access can be controlled through device, app, or session design Over-securing setup at the expense of recovery Controls are designed for ideal conditions, not shift pressure Design security that holds up during replacement, poor connectivity, and limited support Treating enrollment as a one-time event Success is measured by initial provisioning only Design for wipe, repair, reassignment, refresh, and reprovisioning A deployment path that saves time on day one can create years of friction if it does not match how the device is used. In frontline scenarios, the best enrollment model is not always the fastest one to provision. It is the one that is easiest to sustain. “One of the most common mistakes I have seen is designing for the cleanest administrative model instead of the messiest operational reality. In FLW cases, the real test is not whether the device enrolls successfully on day one. It is whether the device can keep supporting the workflow after shift changes, network changes, app issues, wipes, repairs, and urgent replacements. Sucheta Gawade Practitioner Closing Successful frontline deployments are rarely defined by the sophistication of their policies alone. They are defined by how well design choices hold up under real-world pressure. Enrollment is one of the earliest and most visible signals to frontline teams about whether the technology is there to support their work or get in the way. By treating enrollment as a deliberate design decision and grounding it in how devices are actually used, organizations can reduce friction, improve resilience, and create a foundation that scales as frontline operations evolve. Getting enrollment right does not guarantee success, but getting it wrong sets a ceiling that no amount of policy refinement can overcome. For more frontline examples and implementation guidance, see related Microsoft frontline worker management resources, including the blog, From the frontlines: Frontline worker management with Microsoft Intune, and the earlier article, Migrating Frontline Mobile Devices: Understanding the Reality of Your Estate. “When enrollment, identity, security, and recovery are designed well, frontline teams can stay focused on the people they serve - customers, patients, guests, employees, students, and communities - instead of the device in their hands. That is the standard a frontline enrollment strategy should be measured against. Sucheta Gawade Practitioner 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.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.Migrating frontline mobile devices: Aligning stakeholders before real-world testing
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 the previous article, we focused on understanding the reality of your frontline device estate - what devices you have, how they’re used, and which tasks they must support. Now that discovery is complete, the next step is to assess what you’ve found and align your people and processes before beginning real‑world testing with Microsoft Intune and representative users and devices. This is where you turn discovery into an actionable plan your team can execute in real operational conditions. Many organizations refer to this stage as a Proof of Concept (POC) or pilot. In this article, we use these terms to describe limited real‑world validation of frontline workflows with representative users and devices, rather than internal IT feasibility testing. Use the pilot to confirm that users can reliably complete critical tasks in live operational environments before wider rollout. Translate discovery into decisions Discovery produces facts, but readiness requires decisions. Before beginning real‑world testing with representative users and devices, your team should be able to answer questions like: Are we migrating “as‑is,” or do we plan on correcting identity and usage anti‑patterns such as shared credentials or personal use on corporate devices? Which workflows are non‑negotiable and must work on day one, and which can be improved later? Do we need to refresh hardware now, or can we migrate current devices and plan standardization at refresh time? What are our top constraints (OS support, connectivity, etc.)? A useful way to structure discovery output is to categorize findings and determine whether they support limited real‑world testing or require further alignment before proceeding. Pre‑requisites for real‑world testing typically include clear ownership of devices and apps, supported OS versions, and a manageable device or OEM mix. Items that often require alignment before real‑world testing include shared devices without a defined shared‑device model, shared credentials or unclear authentication approaches, personal use on corporate devices (which affects wipe/re‑enroll decisions), certified app or peripheral constraints, and network or certificate dependencies that could impact enrollment and compliance. Identify the stakeholders you must align (and why) Real‑world testing of frontline workflows depends on more than technical readiness. A clear stakeholder map helps surface operational dependencies early and ensures that limited validation activities can be conducted safely without disrupting day‑to‑day work. Not every environment requires all of the roles listed below at this stage, but these are the most common stakeholders needed to support limited real‑world testing of frontline workflows. Operational stakeholders Stakeholder Why they matter What to align Operations / business leadership Define frontline outcomes and approve change windows. Critical workflows, downtime tolerance, shift patterns, pilot locations, operational sign‑off criteria. Funding owners / procurement Discovery often uncovers refresh or licensing gaps. Device and accessory funding, carrier plans, spares, and standardization strategy. Change management Testing may introduce new sign‑in flows or device behaviors. Communications plan, support readiness, rollback and escalation processes, exception management. In addition to operational alignment, technical readiness across supporting IT teams is required to ensure testing reflects production like conditions. Technical and support stakeholders Stakeholder Why they matter What to align Endpoint or Microsoft Intune owners Build policy, enrollment, apps, and compliance. Device categories, management models, policy approach, rollout waves. Architecture team Ensure alignment with enterprise standards. Reference architecture, lifecycle approach, dependency mapping. Microsoft Identity / Microsoft Entra team Underpins Conditional Access and shared‑device patterns. Authentication model, shared device sign‑in patterns, break‑glass scenarios. Network team Enrollment depends on connectivity and certificate flows. Wi‑Fi (EAP‑TLS), proxies, segmentation, roaming, known dead zones. Security / risk / compliance Define guardrails and exceptions. Wipe policies, logging, least privilege, auditability. App owners / vendors Critical frontline workflows depend on app behavior. Compatibility, offline behavior, deployment approach. Support / service Desk Manage user impact during testing. Runbooks, escalation paths, enrollment troubleshooting, shift‑based support. Project management (large environments) Coordinate testing across teams. Timeline, risk tracking, cross‑team communications. Readiness checklist before real‑world testing Real‑world testing often produces limited value when it focuses primarily on Microsoft Intune enrollment rather than operational use. Enrollment is a starting point, but the goal of this stage is to confirm that critical frontline workflows function reliably end‑to‑end in production‑like conditions. Readiness area Questions to consider before real‑world testing Licensing Do you have the correct Intune licenses for the devices or users in scope? Are any add-ons needed? Identity Is Microsoft Entra configured for your enrollment approach? Are Conditional Access policies ready for real‑world testing? For shared devices, what sign‑in model will you use? Stakeholder alignment Who owns the success criteria? Who approves the testing scope and change window? Who funds required accessories or device refresh? Operational readiness Who provides day‑to‑day support for test devices? What is the escalation path for a broken critical workflow? What is the rollback or recovery plan? Device lifecycle decisions Will you test by migrating existing devices as‑is, replacing end‑of‑life devices first, or using testing to define the future standard? OEM and ecosystem readiness Are the devices still supported by the OEM? Are required peripherals supported? Do rugged or certified requirements limit device options? Lack of clear ownership for testing success criteria is a common cause of inconclusive pilots, particularly where operational workflows span multiple teams. Decide what your real‑world testing must validate Real‑world testing often produces limited value when it focuses primarily on enrollment rather than operational use. Enrollment is a starting point, but the goal of this stage is to confirm that critical frontline workflows function reliably end‑to‑end in production‑like conditions. Real‑world testing should validate high‑value operational outcomes, ensuring: Critical workflows function end‑to‑end Scanning, inventory, delivery confirmation, POS, etc. Session transitions match shift patterns Offline or degraded‑mode behavior works as expected (where relevant) Security works without disrupting operations Compliance and Conditional Access do not block legitimate frontline activity Wipe and recovery processes are realistic for shared devices App protection controls align with user experience Supportability is operationally viable Device reset and re‑enroll processes are documented Troubleshooting steps are known and repeatable Escalation paths exist for frontline‑impacting incidents Representative device scenarios are included Include the different frontline scenarios identified during discovery, such as: Shared vs assigned devices Different OEM models or OS versions Sites with known connectivity constraintso Common peripherals that may introduce migration risk (for example, scanners or printers) Plan for future standardization (without delaying testing) You may need to begin real‑world testing using the environment you have today. However, this stage can also be used to identify patterns that may shape future procurement and standardization decisions without delaying validation activities. Practical prompts to add to your planning: If you could reset procurement going forward, would you reduce OEM or device model sprawl? What might your target “approved device set” look like for the next refresh cycle? Which procurement models could support consistent enrollment, warranty coverage, and access to spares across shifts? Standardization doesn’t need to be a prerequisite for real‑world testing, but it can become a valuable outcome of the migration effort over time. Moving from assessment to real‑world testing After you’ve aligned stakeholders, clarified dependencies, and defined what your real‑world testing must validate, you’re ready to move from assessment to limited operational testing with representative users and devices. The key takeaway is this: discovery tells you what’s real, but readiness determines whether you can safely test it in live operational conditions. As always, we welcome your feedback and experience. If you’ve already tested frontline workflows in operational conditions, what advice would you give organizations preparing for this stage? Share your thoughts in the comments below or reach out to us on X @IntuneSuppTeam. Explore the From the frontlines: Frontline worker management with Microsoft Intune series for additional guidance on managing frontline workers and devices.Migrating Frontline Mobile Devices: Understanding the reality of your estate
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. Frontline devices have evolved from a small set of task-specific tools into the way day-to-day work gets done. As new workflows, apps, locations, and teams get added over time, device estates expand quickly, making it harder to maintain consistency and visibility. For many organizations, the reality of the estate isn't easy to keep track of. Devices may have been purchased locally, inherited through acquisitions, shared across teams, or left unused in lockers. They may be repurposed for new workflows or kept running far longer than originally planned. This creates a gap between what teams think they have, how they expect devices to be used, and what happens in the field. “Frontline estates aren’t complex because teams don’t care, they’re complex because operations evolve faster than governance.” -Sucheta Gawade, Microsoft MVP If teams don’t close this gap early, it tends to show up during pilots and cutover: devices fail in real conditions, frontline teams revert to workarounds, and the migration slows down through rework, exceptions, and avoidable disruption. To understand the estate, teams need to start by determining what the business needs devices to do and not just who happens to use them. Start with what devices need to do While some devices are assigned to individual users, many are shared across shifts, used for specific tasks, or operate without a fixed user at all. Designing a migration around users or roles can obscure what really matters: the job the device must perform, when it must be available, and the impact if it isn’t. Anchoring on business needs helps teams: Focus on outcomes rather than ownership models Simplify stakeholder conversations Make clearer tradeoffs, when required, around user experience, productivity and security One simple way for teams to gather this information is by mapping business tasks to what devices must reliably do. Business Task What the device must do When it must work Impact if unavailable Take payment for goods Run secure POS applications Store open hours Lost revenue Pick inventory Scan bar codes quickly and accurately During shifts Orders delayed Document patient observations Capture and submit clinical data During care delivery Delayed or incomplete care This framing applies equally across retail, healthcare, manufacturing, transport, logistics and utilities. It creates a shared language between IT, operations, and security - one that is grounded in business impact rather than tooling. Once business needs and intended device usage are clear, the next step is understanding how those devices support frontline work day to day. Understand how devices are used in practice Frontline usage patterns often diverge from what business owners and IT expect. Devices may be shared across shifts or used by alternate users. They may also be repurposed to support new workflows or kept running beyond their intended lifecycle, all without IT or executive oversight. These gaps are best identified by partnering with operational and business owners to validate real-world usage through quick workflow walk-throughs, targeted questions, and a review of how devices are accessed and supported day-to-day. Some helpful questions: How are devices shared? When are they offline or unavailable? What workarounds exist to keep critical tasks moving? It’s also critical to confirm whether corporate-assigned devices have been used for personal activity. Personally used devices may also be treated as work devices, whether authorized or otherwise. This affects wipe and re-enroll decisions because personal use can introduce data retention, user impact, and acceptance risks. Intended usage Actual observed use Notes/Workarounds Assigned device Shared across the shift Shared credentials used Always connected Intermittent Wi-Fi Offline workarounds Single-app device Multi-app usage Local exceptions for multiple apps This is also where identity assumptions surface, particularly in environments where devices are shared but access shouldn’t be. “Identity reality matters: shared devices should not mean shared credentials. Migration is often the right moment to address this. Otherwise, teams simply re‑platform the same risks.” -Sucheta Gawade, Microsoft MVP Teams often uncover important dependencies at this stage. For example, some frontline workflows rely on constant connectivity, while others must function reliably in low‑bandwidth or offline conditions. Similarly, older operating systems or unsupported device models may still be in active use because replacing them has operational or budgetary implications. Understanding these realities early helps teams avoid designing for ideal conditions that don’t exist in the field. Ground plans in device inventory Inventory is most valuable when it supports planning decisions, not when it aims for completeness. For frontline migrations, teams need decision relevant information rather than a perfect asset register. Understanding how devices are procured and funded across the organization is important. For example, whether devices are purchased centrally through IT or sourced locally by business/departments. Procurement paths often explain why inventory is fragmented and help determine who owns refresh cycles, warranties, and enrollment readiness. At a minimum, this includes: Device types and OEMs OS version ranges and supportability Whether devices are active, dormant, or missing How devices align to business-critical tasks Where specialist or certified devices are required such as intrinsically safe or ruggedized devices This helps surface ecosystem considerations early: Are required apps and services supported on the OS versions in use today? Do OEMs still support the hardware? Do environment constraints affect enrollment, updates, or day‑to‑day operation? These questions are not about selecting solutions yet. They’re about understanding constraints that will shape options later. With business needs understood, usage patterns mapped, and inventory validated, teams are ready to start designing approaches that work in frontline conditions. Migration is also a good opportunity to plan for standardization and set a future procurement standard. Even if you migrate the current estate as-is, defining an approved OEM or model catalog for future purchases improves consistency. It can also accelerate troubleshooting and strengthen lifecycle governance as devices reach end of support. What we’ve learned The key lesson is simple: validate reality before designing anything. Teams that invest time here: Reduce rework during pilots Avoid late‑stage surprises Have stronger conversations with operational, security, and platform stakeholders “We don’t declare success at enrollment. We declare success when a frontline workflow can run end-to-end with predictable support.” -Sucheta Gawade, Microsoft MVP In future articles, we’ll look at how these insights shape design decisions. In the meantime, we’re interested in hearing what gaps you’ve uncovered between intended and actual device usage in your frontline environments. Leave a comment below or reach out on X @IntuneSupportTeam.Migrating frontline mobile devices: A frontline-first approach to moving to Microsoft Intune
Frontline organizations consistently tell us that unified management is the goal but the challenge is getting there without disrupting day-to-day operations. Smartphones, Android handhelds, rugged scanners, and shared tablets now sit at the center of how retail stores run, how clinicians deliver care, how supply chains move, and how field workers’ complete work. These devices are mission critical, and any disruption is immediately felt on the ground. To strengthen security, reduce costs, and simplify operations, many IT architects and administrators are now evaluating or planning to move to Intune. This new series, “Migrating Frontline Mobile Devices - is designed to help. We’ve worked side by side with frontline customers, observing what works, where projects stall, and how small decisions early on can dramatically improve outcomes later. The articles in this series distil those lessons into practical guidance for teams who are considering, planning, or actively migrating devices. Frontline devices serve different needs and follow different operational rhythms than knowledge worker devices. Frontline migrations aren’t the same as standard knowledge-worker migrations and treating them as such often leads to operational problems or rollout delays. This article explains what the difference means in practice and how it shapes planning for successful frontline migrations. Why failures hurt more on the frontline A failed knowledge worker enrollment is an inconvenience. A failed frontline device enrollment or non-functioning device can affect revenue, disrupt essential services, and in some industries compromise safety. When a device is unavailable, critical work halts immediately: Pickers can’t complete scanning tasks Cashiers can’t take payments Health practitioners can’t document or prescribe care Drivers can’t dispatch Production lines stop Workers can’t perform required safety or compliance actions What we’ve learned: Frontline migrations must be coordinated with business and operational leaders; store managers, shift supervisors, clinical leads, and supply chain teams because they decide what is required and when devices can be taken offline. Why mobile frontline device migrations are different The operational impact of failure is higher on the frontline because frontline devices operate in very different environments to knowledge worker devices. Knowledge worker devices usually run in stable, well understood environments with known device catalogues, predictable lifecycles, assigned users, and steady connectivity. Frontline devices operate in conditions that introduce unique design and migration challenges. The environments they run in directly affect how and when a device can be enrolled or updated. Devices may run in low bandwidth or intermittent connectivity environments, making enrollment flows and policy delivery harder to complete reliably. Some operate in high-risk industrial or clinical settings where devices can only be taken offline during narrow operational windows. Others return to charging racks between shifts, meaning migrations must align with shift changes rather than user availability. Many run in kiosk or locked task modes tied to a single workflow, so even small configuration changes can disrupt critical tasks if not planned carefully. These environmental and operational realities show up across the entire device lifecycle from provisioning to updates to support. To make the differences clearer, here’s a concise comparison of frontline and knowledge worker devices: Category Frontline devices Knowledge worker devices Devices Smartphones, handhelds, rugged devices, scanners, wearables, tablets Laptops, desktops, smartphones OS and patch posture Often older versions; inconsistent patch levels due to operational constraints Typically, current OS or N-1; regular security patching cycles Ownership Shared, shift-based or individually assigned depending on role Individually assigned Network conditions Variable, often constrained Generally stable Provisioning Zero-touch essential User-led viable Updates Highly controlled Standard update cycles Apps Task-specific, time-sensitive updates Broad, less time critical updates Workflow impact Operationally critical Productivity-focused Typical usage scenarios Point-of-sale, healthcare, barcode scanning, delivery routing, inventory checks Email, productivity tools, collaboration, creative workflows Failure impact Immediate operational issues Localized user disruption Standard knowledge worker migrations are designed for predictable conditions such as consistent users, steady connectivity, current OS levels, and a governed device lifecycle. Frontline fleets rarely match this baseline, so their migrations require planning and design that reflects actual device state and use. A migration is a design moment, not just a technical step A migration offers an opportunity to reassess business needs, tighten governance, simplify and modernize app delivery, and confirm assumptions about how devices are used. It’s also a chance to raise your frontline security, aligning devices with Zero Trust principles. In successful frontline migrations: Teams build in time for design, evaluation, and piloting. Early alignment across stakeholders supports smoother execution and reduces the risk of disruptive rework later. Understand your estate before designing the migration Frontline migration projects always reveal something unexpected. Common patterns include: Mixed iOS/Android versions and multiple original equipment manufacturers (OEM) such as Samsung, Zebra, Honeywell, Apple and more. Devices running outdated OS versions or custom OEM images. Devices that haven’t checked in for months, often sitting unused in cabinets. App delivery paths reliant on sideloading or site specific packages with no update mechanism. Multiple active mobile device management (MDM) systems inherited through acquisitions or decentralized teams. Most migration issues that appear later in the project can be traced back to decisions made before anyone understood what existed in the field, how devices were being used, or what the business needed them to do in the future. What we’ve learned: Migration success improves dramatically when teams validate device inventory, usage patterns, and business requirements before choosing an enrollment method and designing configuration profiles. Real-world data turns assumptions into facts and avoids costly rework. Plan for identity – even if devices don’t use it today Many frontline devices run with shared logins or no user at all. Intune fully supports these scenarios, but identity gaps - shared credentials, app only authentication, and managed access patterns - often emerge over years of organic growth. These gaps can show up during migrations as both user experience issues and security risks. What we’ve learned: Even if you’re not ready to modernize frontline identity or introduce Microsoft 365 tools for workers, consider laying out the foundation. Mapping which users or roles should have identities, simplifying and securing access, and aligning devices to Microsoft Entra foundations will future proof your estate. What’s coming next in the series This series will explore the areas that consistently shape successful frontline mobile migrations the steps, patterns, and design decisions that matter most in real frontline environments. Over the coming weeks we’ll cover themes such as: Understanding your frontline estate - what exists today, how devices are used, and the realities that shape migration decisions Designing for frontline conditions - identity foundations, shared device patterns, kiosk considerations, and reliable enrolment flows Designing for frontline device scenarios - single user, shared, rugged, kiosk, and high-risk operational models Consolidating to a single Intune tenant - simplifying governance, policies, and operating models Getting the ecosystem right - apps, connectivity, certificates, and the infrastructure dependencies that influence reliability Executing the migration safely - pilots, phasing, cutover windows, and planning for 24/7 operations Life after migration - monitoring, support readiness, and ongoing operational ownership We’ll share practical guidance, common friction points, and patterns we’ve seen work across industries. Future articles will include perspectives from Microsoft Product Managers and community experts with hands-on experience managing large scale frontline device estates. Look out for the next article in the series - Understanding the reality of your estate. We’d love to include your perspective. If you have questions, scenarios, or experiences you want this series to address, share them in the comments below to help shape the upcoming articles, or reach out to us on X @IntuneSuppTeam. Our goal is simple: To help you migrate frontline mobile fleets to Intune without disrupting the business.
