Android 12 Sign-In Issue with HP Corporate Accounts via Intune Company Portal
Since yesterday, HP employees using older mobile operating systems (Ex. Android 12) have been unable to access Microsoft Outlook and Microsoft Teams on their smart devices. When launching Outlook or Teams, users are prompted to install the Microsoft Intune Company Portal app for authentication and device compliance. However, the latest version of this app appears to require a newer operating system version and is not supported on older devices. As a result, users with devices running Android 12 or earlier cannot complete the authentication process and are unable to use Outlook or Teams. ■ Please provide additional details 1) The issue started yesterday and affects employees using older Android and iOS versions. 2) On iOS devices, users can typically resolve the issue by upgrading to a newer iOS version. 3) However, some Android devices cannot be upgraded further due to manufacturer limitations. 4) For example, Samsung Galaxy Note 10 officially supports Android 12 as its final OS version and cannot be upgraded to Android 13 or later. 5) Because of this limitation, affected Android users are unable to install or use the required Microsoft Intune Company Portal app, which prevents access to Microsoft Outlook and Microsoft Teams. 6) This issue may impact multiple HP employees who are using Android devices that do not support Android 13 or later. Example affected device: Samsung Galaxy Note 10 (Android 12) Affected applications: Microsoft Outlook, Microsoft Teams, and Microsoft Intune Company Portal Business impact: Users cannot access corporate email, messaging, and collaboration services from their mobile devices. I have already posted this issue on the Microsoft Feedback Portal: https://feedbackportal.microsoft.com/feedback/idea/7bba2697-a2a2-f111-85ce-7c1e529382f4 However, this issue cannot be reproduced when using a personal Microsoft account. It only occurs when using an HP corporate email account because HP requires the use of the Microsoft Intune Company Portal app for authentication and device compliance. Since the problem appears to be related to the Intune Company Portal rather than Outlook or Teams themselves, I would like to post this issue here and seek guidance on resolving the Intune Company Portal authentication and compatibility issue affecting Android 12 devices.
Intune partner compliance onboarding
Hello, We develop a MDM solution and we would like to become device compliance partner to offer our customers conditionnal access functionality. After filling twice (the first time almost two month ago) the form "Intune partner compliance onboarding request" whose link is available on this page https://learn.microsoft.com/en-us/intune/device-security/compliance/third-party-partners, we didn't get any reply to our request. Would you know if there is any other way to integrate this partnership ? Any contact or anything to get some news about our request ? Thank you for your help. Best regards,
Problems identifying managed iOS devices when using APP
Hello, As the title says i am having a hard time getting this to work. We have been using APP for a long time, but it has not been necessary for us to have different policies for managed (we only use iOS) and unmanaged devices (all mobile device types). Now i want to remove APP from managed devices all together, and only enforce this on unmanaged devices (BYOD) Please see attached image of how it is configured today. I also have an CA policy which requires APP when using MS apps, where i have added and "Filter for devices" exclude with following syntax: device.enrollmentProfileName -contains "iOS standard profile" (which cover our enrollment profiles, both are fully managed) When enrolling a managed device, APP still is enforced. Does anyone have any tips? I wanted to try here before submitting a ticket to MS. As far as i have found out , the app.devicemanagmenttype is the only rule that can be used to filter managed devices when used with APP.Disallow O365 access from 'outside' of the Android for Work work profile?
Is there a way to block Android for Work users to connect to Office 365 with apps that are installed outside of the work profile? For example on my Android for Work capable device I have a work profile with eg. Outlook, which I can use to read my mail. However, i'm also able to use the Outlook app in my personal space to connect to Office 365, I was kinda expecting to only be able to connect to Office 365 from my work profile (?)
Windows App Application Protection Policy
I have been testing out an Intune MAM policy to restrict copy/paste and drive redirection to AVD session hosts based on the link here: https://learn.microsoft.com/en-us/windows-app/require-device-security-compliance-intune?tabs=web#related-contentHowever, I've run into problems (in two separate tenants) that have halted me from being able to test. Setup Intune App Protection Policy targeting Windows Devices & Microsoft Edge\ Conditional Access Policy enforcing App Protection Policy when users access 'Azure Virtual Desktop' target resource via https://windows.cloud.microsoft.com Results First When signing into a user account targeted by the policy, they are prompted to Switch Edge Profile which signs in the user to a new Edge profile for 'Work or School Account'. The account has to sign in again. The account can access Windows App resources When launching a desktop session, this authentication page pops up for an account "local@debugonly" Second When signing into a user account targeted by the policy, they are prompted to Switch Edge Profile which signs in the user to a new Edge profile for 'Work or School Account'. The account has to sign in again. After sign in, the account loops with 'Switch Edge Profile' and gets stuck here I'm curious if anyone has gotten this to work and what was your setup? Or if Microsoft or provide some assistance or if this is in the wrong forum, any help would be appreciated.Android Fully Managed devices treated as personal after AD password change
Hello! We have a huge problem... We have recently observed an issue in our organization affecting Android Fully Managed devices. After users change their domain password, within 1–3 days Conditional Access starts blocking access to Outlook and Teams. The system appears to treat the device as non-corporate, even though in Intune the device is still present, marked as corporate, and fully functional. It synchronizes both manually and automatically, and remote actions can be executed without any issues. However, when users open Outlook or Teams, they receive messages such as “We need to secure your device” and “Install the Intune app from Google Play,” which does not make sense because Intune is already installed on the device. When opening the Intune app, users see a “Update your password” prompt. After selecting it, they are redirected to a device registration screen. Previously, it was sometimes possible to complete this process (although we did not understand why it was required), but recently re-registration consistently fails. The user clicks “Register,” and the process spins indefinitely without completing. This issue is very difficult to troubleshoot. Device logs are not particularly helpful, and all users have Microsoft Authenticator configured. The problem appears randomly across users with no clear pattern—some devices were enrolled over a year ago, others just a month ago. The only clue we have found so far points to a potential issue with the broker authentication token, but we do not know how to verify or resolve this, nor why it is happening in the first place. We have been experiencing this issue since around January this year, but we noticed a significant increase in cases this month. In addition, there are more and more devices that can no longer be re‑registered from within the Intune app. Has anyone encountered a similar issue or can provide guidance on how to investigate or fix this?
Allow Teams desktop on unmanaged Windows, but block Outlook desktop using Entra conditional access
I need to allow Teams to run on non Intuned devices but not allow Outlook desktop to be available I am looking for a solution for Windows and Mac and ideally linux as well The issue is Ig I have Office 365 Exchange Online as my resource, it blocks Microsoft Team Services as well How can I fix thisMigrating 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.
