Require Google Workspace authentication on Android Enterprise devices with Microsoft Intune
By: Samuel Vara, Software Engineer & Mayur Jadhav, Product Manager | Microsoft Intune We’re excited to announce that organizations using Android Enterprise can now require users on managed devices to authenticate with a managed Google Account. This capability is generally available in Microsoft Intune and helps organizations use their Google Workspace identities as the primary management identity on supported Android Enterprise devices. The new policy supports organizations that have upgraded their Managed Google Play enterprise to a managed Google domain enterprise. Use managed Google Accounts on enrolled devices Android Enterprise has traditionally used managed Google Play accounts solely to enroll and manage devices and distribute corporate apps, rather than as user identities for accessing Google services outside the managed device. With this policy, admins can now require users to enroll and authenticate with their organization’s managed Google Workspace Account instead of using the device’s managed Google Play account. This gives users access to Google apps and services with their organizational identity. This feature doesn‘t impact the Microsoft Entra account associated with the managed device. This capability supports the following Android Enterprise enrollment types: Corporate-owned, fully managed devices Corporate-owned devices with a work profile Note: Corporate-owned dedicated devices aren't supported because they aren't associated with an individual user. Prepare your environment Before you configure the policy, complete these prerequisites: Verify your organization's Google Workspace domain. Admins can verify an organization's domain on the Google Admin console by following the instructions from Verify your domain for Google Workspace | Domain management | Google Workspace Help Upgrade the Managed Google Play enterprise to a managed Google domain enterprise, if required, using the Upgrade button on the Intune admin center. Customers can follow the instructions in the blog New onboarding flow to managing Android Enterprise devices with Microsoft Intune to upgrade or onboard their tenant. Note that the admin performing the upgrade must have "Super Admin" rolein Google Workspace during the upgrade process. More instruction on how to assign such permission to a user can be found in Prebuilt administrator roles | User management | Google Workspace Help If users don't already have managed Google Accounts created in the enterprise's Google Workspace domain, create them following the instructions in the "Domain verified" section of Add an account for a new user | User management | Google Workspace Help Use an account with at least the Policy and Profile Manager role in Intune for the above oprations within the Intune admin center. Configure the policy in Microsoft Intune In the Intune admin center, Create a policy using settings catalog in Microsoft Intune or follow the instructions below: Go to Devices > Manage devices > Configuration > Create > New policy. For Platform, select Android Enterprise. For Profile type, select Settings catalog. In Configuration settings, open Device restrictions > Users and Accounts. Add Require users to authenticate with a Google Workspace account and set it to True. ssign the policy to groups containing users that want to use the managed Google accounts for authentication and enrollment on their Intune managed Android devices. Review and create the policy. You can assign the policy before enrollment or to devices that are already enrolled. If you assign it before enrollment, the authentication prompt appears after enrollment. On an enrolled device, the prompt appears after the device receives the policy. What users experience After the policy reaches the device, the user receives a Sign in with your work account prompt on the device. The user clicks on the prompt and adds a managed Google Account from the organization's enterprise domain and completes authentication. Until the user completes the prompt and authenticates with the Google Account, the policy setting reports an "Error" state, and the Gmail app, if present on the device, is disabled. This policy's non-compliance doesn't change the device's overall compliance state. Once a Google Account is chosen the user completes authentication, the managed Google Play account is replaced on the device by the chosen Google Account. ndroid phone lock screen showing a Device Policy notification prompting the user to "Sign in with a work account". Verify deployment Administrators can monitor the policy from Devices > Manage devices > Configuration > Policies in the Intune admin center. Select the policy to review device and user check-in status, device assignment status, and per-setting status. After the user completes authentication, confirm that the managed Google Account is available on the device. Conclusion This new Intune capability gives organizations greater control over how users access Google apps and services on supported corporate-owned Android Enterprise devices. By requiring authentication with a managed Google Account from the organization’s Google Workspace domain, admins can provide a consistent organizational identity and give users access to the Google Workspace resources and services assigned to that account, while retaining Microsoft Entra as the device’s management identity. Review the prerequisites, configure the settings catalog policy, and monitor deployment to bring this experience to your users.
Multi-App Kiosk not applying on Samsung A55 (Android 16)
Hello everyone, I’m facing a critical issue with Android Enterprise Multi-App Kiosk mode on a Samsung Galaxy A55 (SM-A556B). The problem started suddenly last week without any configuration changes, and now no Android Enterprise configuration profiles apply anymore. What happened originally The device was running Android 15, and it had been working fine for months in Managed Home Screen (Multi-App Kiosk). Then suddenly: Managed Home Screen stopped showing all apps The device booted into MHS, but the screen was completely empty No policy changes were made on our side I tried several troubleshooting steps, but nothing fixed it. Eventually, I factory-reset the device and re-enrolled it as a Corporate-Owned Dedicated Device (COBO). Current situation after re-enrollment Even after a clean enrollment: No Android Enterprise device restriction profiles apply (Multi-App Kiosk doesn’t start at all) The device stays in the normal Samsung launcher Only very basic commands work: Remote restart App install/uninstall via group assignment All assigned apps show as Installed Profile status in Intune shows Success, but nothing is actually enforced I then upgraded the device to Android 16 (patch 2025-11-01). Unfortunately, the behavior did not change. Current configuration Android Enterprise → Device Restrictions → Multi-App kiosk Allowed apps: Teams, Managed Home Screen, Contacts Managed Home Screen installed Enrollment type: Android Enterprise – Fully Managed / Dedicated No OEM kiosk (no Samsung Knox settings) No Work Profile on the device Symptoms now Managed Home Screen never launches Kiosk mode is completely ignored Device is fully usable like a normal phone Only app deployments work, nothing else This began while still on Android 15 Updating to 16 did NOT resolve the issue Questions Has anyone seen this behavior where Android Enterprise policies stop applying entirely after MHS fails? Is there a known issue with Samsung A55, Android 15/16, or Managed Home Screen? Could this be related to a bug in the Fully Managed/Dedicated enrollment flow for the A55? Any recommended workarounds or known fixes? Any guidance is appreciated — this behavior is completely blocking Kiosk deployments for us. Thanks!Support tip: Restore the Managed Home Screen Exit PIN
We identified and resolved a recent issue (IT1450132) that could cause the configured Managed Home Screen exit PIN to be removed from some existing Android Enterprise when updating older device configuration policies. While a fix has been deployed to address this, if a policy was already affected, you will need update the affected policy or policies and ensure the Exit Kiosk Mode PIN is set before saving. What you might see On an affected device, selecting Exit kiosk can display a message that a PIN to exit kiosk mode has not been set by the IT administrator, even though the policy was previously configured with one. See an example screenshot below. Note that this screen will also show on devices where you’ve intentionally disabled the Exit kiosk feature. Figure 1: Android device in kiosk mode displaying a message that no PIN has been configured to exit kiosk mode and advising the user to contact an administrator. Update the affected policy In the Microsoft Intune admin center, open the device restrictions policy assigned to the affected Android Enterprise dedicated devices. Under Device experience, confirm that Leave kiosk mode is set to Enable. Enter a new 4-6 digit value for Leave kiosk mode code. Save the policy and allow it to deploy to the affected devices. Verify that the new PIN can be used to exit kiosk mode. The previous PIN cannot be recovered after it has been removed, so a new PIN is required. For more information, see Android template device settings list to restrict features using Intune. If you need temporary access before the updated policy reaches a device, use the Suspend Managed Home Screen device action, provided the documented prerequisites are met. Figure 2: Microsoft Intune admin center showing Android Enterprise device restriction settings, with the “Leave kiosk mode” option enabled and a kiosk exit code configured. Summary The service-side issue has been resolved. Administrators with previously affected policies should configure and deploy a new Managed Home Screen exit PIN, then verify the behavior on their devices. We’ll continue to update this post as new information becomes available. If you have questions or comments for the Intune team, reply to this post or reach out to @IntuneSuppTeam on X.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.From the frontlines: Accelerating retail worker shared device experience (Part one)
By: Yusuke Shinoki – Sr Product Manager | Microsoft Intune This is the second article in the "From the frontlines" series. I'm Yusuke Shinoki, I wanted to share the insights I’ve gained from my retail customers who often talk to me be about their frontline worker device scenarios. Technology has revolutionized the retail industry by enhancing operational efficiency and customer experiences. Retail employees now use shared devices to access inventory data, check product availability, and manage orders on the go. Store staff monitor sales and productivity digitally, enabling frontline workers to better serve customers by quickly accessing essential information. In supermarkets and pharmacies operating 24/7, shared devices are rotated among shift workers to perform tasks critical to the business operations. Collaboration and real time access to data is becoming increasingly important for frontline workers. Simultaneously, it’s essential to maintain secure access in line with the Zero Trust security strategy. Let’s discuss how retail associates can benefit from using Intune-managed devices at work while balancing productivity and security. Retail associates device needs Let’s say retail giant ‘Contoso’ wants to provide shared devices to retail associates, so they can help customers and drive sales. They want each associate to be able to pick up a device at the beginning of their shift and allow them to feel like it’s their own for the duration of the shift. Additionally, they want their associates to be able to collaborate with other associates via Microsoft Teams and access their internal employee portal. At the end of their shift, they want associates to log off and return their devices to the central pool, confident that their personal data won’t be seen by the next associate. To support this scenario on shared devices, use Intune’s Android Enterprise dedicate devices enrollment solution with Microsoft Entra shared mode (Fig. 1) and Managed Home Screen. Android Enterprise dedicated devices with Microsoft Entra shared mode and Managed Home Screen allows IT admins to provide consistent shared device user experience. In Contoso’s case, the Contoso IT team needs to provide user experiences for retail associates such as: Easy experience for device sign-in when starting their shift and sign-out at the end of their shift. Setting a temporary session PIN for individual associates during their shifts while using devices. Easy app switching. Associates experience The Contoso IT team must ensure seamless device sign-in to maximize associate productivity during limited shift hours. Intune and Managed Home Screen provide options to reduce shift swapping time by allowing workers to simply enter their Microsoft Entra ID account into the device and sign in. Microsoft Entra ID accounts require entering a User Principal Name such as "user@contoso.com". By configuring the "Domain name" setting in Managed Home Screen, associates will automatically see the domain name options available to them. This allows associates to quickly enter their ID and start using the device efficiently. (Fig. 2) After completing the initial Microsoft Entra ID authentication on the Managed Home Screen, associates set up a temporary session PIN (Fig. 3). This session PIN allows them to securely use shared devices for their tasks throughout their shift. The associates’ credentials are then used to enable a single sign-on experience with supported apps. Usually switching apps in Kiosk mode is cumbersome, but Managed Home Screen leverages the virtual app switcher button to switch between apps quickly, just like they do on their regular Android devices. (Fig. 4) This feature enhances the user experience by allowing seamless transitions between applications, ensuring that workers can maintain productivity without unnecessary delays. Once the associate's shift ends, they can easily log out and return the device to the pool. This ensures that all apps are securely signed out, preventing the next shift's associate from accessing any personal data handled by the previous user (Fig. 5). Even if the previous user forgets to sign out at the end of their shift, it's not a problem. The next user can easily start their session by using the “Switch User” option (Fig. 6). These streamlined user experiences allow retail associates to concentrate on their tasks without delays, improving productivity and user experience. Setting up Managed Home Screen and the new simplified sign-in option Configuring Managed Home Screen can be done through the device configuration profile (Fig. 7) but if you need advanced customization you can use app configuration policies (Fig. 8). This configuration is the same as described previously for the healthcare scenario: From the frontlines: Revolutionizing healthcare workers experience. For step-by-step instructions on setting up Managed Home Screen, refer to the blog: How to setup Microsoft Managed Home Screen in kiosk mode on Dedicated and Fully managed devices. In addition to “Domain name” configuration, we’ve been working on further simplifying the sign-in experience. As of March 2025, we introduced QR code sign-in as a public preview. This new feature aims to streamline the initial sign-in process for frontline workers. For additional details on QR code authentication, refer to the following information: Simplify frontline workers’ sign-in experience with QR code authentication | Microsoft Community Hub How to enable QR code authentication in Microsoft Entra ID (preview) - Microsoft Entra ID | Microsoft Learn. Summary In this post, we explored how retail shop associates can use Android Enterprise dedicated devices with Entra Shared Mode and Managed Home Screen powered by Microsoft Intune throughout their shifts. This same type of configuration can be used in many other Android shared device scenarios such as warehouse operations, factory floor, and more. For more guidance review the Microsoft Learn articles: For information on how to set up shared Android devices refer to: Enroll Android Enterprise dedicated, fully managed, or corporate-owned work profile devices in Intune You can find more information on Managed Home Screen and how it can improve the user experience refer to: Configure the Microsoft Managed Home Screen app If you’d like to learn more about how Microsoft Entra Shared Device Mode can help your users easily sign in and sign out leveraging single sign-on review: Shared Device Mode overview - Microsoft identity platform To learn about how to setup maintenance windows and define application update conditions refer to: Corporate-owned Android Enterprise device restriction settings in Microsoft Intune For information on enabling new QR code authentication refer to: How to enable QR code authentication in Microsoft Entra ID (preview) - Microsoft Entra ID. If your device usage is similar to that of frontline workforces, consider using this solution and let us know how it works for you by leaving a comment below or reaching out to us on X @IntuneSuppTeam! In our next “From the frontlines”, we’ll dive into scenarios involving dedicated devices tailored for specific tasks that enhance customer service and efficiency in the retail industry. Check out From the frontlines: Frontline worker management with Microsoft Intune to see more “From the frontlines” blogs. Stay tuned!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.From the frontlines: Delivering critical early responder device management
By: Catarina Rodrigues – Product Manager 2 | Microsoft Intune In high-stakes environments like emergency response, speed, accuracy, and security are essential. Whether it’s paramedics delivering life-saving care or police officers responding to critical incidents, frontline teams need real-time access to information—right where the action is. To meet these demands, emergency services are increasingly deploying mobile devices, paired with advanced device management solutions, to empower their teams in the field. I’m Catarina Rodrigues, a Product Manager in the Microsoft Intune team, and in this blog of the “From the Frontlines” series, I’ll share my experience working with emergency services, exploring how to deploy and manage iPads and Android tablets using Intune. For more information refer to: Frontline worker device management overview in Microsoft Intune. Shared iPads in ambulances Ambulances operate around the clock, often with rotating crews. To ensure seamless and secure access to clinical apps, maps, and emergency protocols, organizations are increasingly often equipping vehicles with iPads that are prepared to be shared by personnel working shift. There are different ways to support Apple devices for frontline scenarios depending on the requirements. Shared iPad mode is recommended for shared use of iPads; it creates multiple user partitions, making it easy for several users to log in and access their applications and data according to their preferences. Intune together with Apple's Automated Device Enrollment (ADE) makes it simple to address this scenario seamlessly, enabling zero-touch provisioning and device supervision for additional security configurations. Below is an ADE enrollment profile configured to setup devices as Shared iPads: User affinity: Enroll without User Affinity Supervised: Yes Locked enrollment: Yes Shared iPad: Yes You can then configure the number of maximum cached users and inactivity settings for these profiles, as needed. Once iPads are enrolled and functional, users will be able to setup their profiles, where they’ll have access to the applications and data according to their permissions. Once their profiles are setup, users can see them in the login screen, as they will be available for them to login again in the future. Benefits of Shared iPad with ADE for IT admins and frontline workers Zero-touch deployment: Devices are automatically enrolled and configured via Apple’s Automated Device Enrollment (ADE), reducing manual setup and ensuring consistency across the fleet. Targeted assignment: Enables IT admins to permanently assign an iPad to a specific ambulance, streamlining shift handovers and ensuring paramedics always have access to the right tools. Persistent configuration: Shared iPad can cache up to 100 user profiles (24 recommended on a 32 or 64 GB iPad), ensuring device settings and apps remain consistent and reducing login friction. Enhanced security and compliance: While these devices are shared, device-level management and app protection policies keep sensitive data secure and encrypted. Remote actions and support: IT teams can monitor, lock, or wipe devices remotely through Intune, with supervision mode enabling deeper administrative controls, such as Lost Mode and Locate Device. This setup gives paramedics immediate access to clinical apps, maps, and protocols and all information they might need to access or share without compromising security or adding friction to their workflow. Fully managed Android tablets for police For police departments, data sensitivity is paramount. Officers need access to real-time intelligence, case files, and communication tools without risking exposure of confidential information. While there are other options to enroll Android devices in Intune (you can see an overview here), setting up corporate-owned, fully-managed Android tablets with Intune can deliver the data protection and device lock-down that police departments need, while ensuring police officers remain productive. Users won’t be able to change pre-defined configurations and install applications from the public store. These devices are associated with a single user, in this case a police officer, as they aren’t intended for shared use. To ensure minimal disruption in the working day of these users, IT admins can use device staging to decrease the number of steps needed to enroll a brand-new device and get it to a functional state. Device staging Device staging is designed to simplify and accelerate the deployment of corporate-owned, fully managed Android devices—especially in high-stakes environments. Instead of requiring police officers to navigate a lengthy setup process, IT teams or authorized third-party vendors pre-configure the devices using a secure enrollment token generated in the Intune admin center. This token allows the device enrollment and provisioning without needing the officer’s credentials, ensuring that critical apps, such as Intune and Microsoft Authenticator, are installed and ready before the device is even handed over. When the officer powers on the device for the first time, they simply sign in to the Intune app, and the device completes its configuration, applying all necessary policies and security settings (see image below). This approach not only saves valuable time during rollouts but also ensures that every police officer receives a consistent, secure, and fully operational device from the moment they turn it on—an essential advantage when reliability and speed are crucial. In the picture below, you see the steps users go through to complete enrollment which requires authentication using the Intune application, so that apps and policies assigned to that user identity are applied. Microsoft Intune and Android Enterprise corporate-owned, fully managed enrollment To enable device staging, IT sets up an Android Enterprise enrollment profile, with a token associated that has a configurable expiry date, up to 65 years in the future. This token can be revoked any time as needed. In addition, IT can also apply a device naming template to all the devices that are enrolled under the same profile, making it easier to identify and group devices by police station, department, or region. You can check the supported strings for this device naming template here. Below you can see an example of an enrollment profile configured with the following parameters: Token type: Corporate-owned, fully managed, via staging Apply device name template: Yes Device name template: {{SERIAL}} Benefits of corporate-owned, fully managed, via staging for IT admins and frontline workers End-to-end control and security: IT admins retains full control over the device lifecycle—from provisioning to retirement—ensuring that only approved apps, settings, and security policies are applied and maintained throughout use. Simplified, secure user experience with Managed Home Screen: Managed Home Screen provides a locked-down, customizable launcher that ensures users access only approved apps and settings. This minimizes distractions, enhances security, and delivers a consistent, role-based experience across all devices—ideal for high-stakes field environments. Faster, frictionless rollouts: Device staging eliminates the need for users to complete complex setup steps. Devices arrive pre-enrolled and pre-configured, so users can simply sign in and start working immediately. Consistent, compliant configuration: Every device is enrolled with the same baseline—apps, policies, and restrictions—ensuring compliance with organizational standards and reducing variability in the field. Reduced IT overhead: By shifting setup responsibilities to staging teams or vendors, IT departments can scale deployments without increasing support load or requiring one-on-one onboarding. Operational readiness from day one: Users receive devices that are mission-ready, with secure access to critical apps like dispatch systems, communication tools, and field data—right out of the box. This setup gives officers the tools they need while maintaining operational integrity and data confidentiality. Summary This blog post explored how to securely manage devices used by emergency services teams. These examples are applicable to other scenarios where workers need to access confidential, sensitive information while in the field. I hope this blog inspires you to try these methods and look forward to answering questions in the comments. This blog is part of the “From the Frontlines” series, where we explore different scenarios of how workers in field use devices and how IT admins can enable them. Check the other blog posts for more inspiration! Please refer to the documentation here for more guidance: For information on how to support Apple devices in the frontline refer to: Get started with iOS/iPadOS frontline worker devices. For information on how to set up Shared iPad refer to: Shared iPad devices. For information on how to support Android devices in the frontline refer to: Get started with Android frontline worker devices. For information on how to set up corporate-owned, fully managed Android devices refer to: Set up enrollment for Android Enterprise fully managed devices. If you'd like to learn more about incorporating device staging to reduce user steps during enrollment see: Device staging overview. To ensure your organization can navigate modern security challenges following Microsoft's Zero Trust approach see: Zero Trust security strategy. As always, if you have any questions let us know in the comments or reach out to us on X @IntuneSuppTeam or @MSIntune!
