Best practices for securing Microsoft Intune
Microsoft Intune gives IT and security teams a powerful way to manage endpoints at scale - deploying apps, enforcing security baselines, and configuring the settings that keep users productive and your organization protected. That’s why strong admin protections matter, so the right people can make the right changes, in the right scope, with the right safeguards. In this post, we’ll walk through three practical approaches to strengthen Intune protections: Start with least-privilege, designing roles around real admin jobs Embrace phishing-resistant authentication and privileged access hygiene, leveraging Microsoft Entra capabilities to reduce account and token compromise Enable Multi Admin Approval in Intune for sensitive changes Below we outline how to put each approach into practice. 1) Start with least-privilege: design roles around real admin jobs Least-privilege works best when it’s grounded in how your team operates. As a best practice, don’t grant more administrative access than a role truly needs. In Intune, role-based access control (RBAC) lets you tailor permissions and scopes so teams can run day-to-day operations with the minimum set of permissions required, nothing more. Microsoft Entra ID roles that have access to Intune, such as Global Administrator and Intune Administrator, are considered privileged roles with broad permissions in Intune. The use and assignment of privileged roles should be limited and not used for daily administrative tasks within Intune. Least-privilege is about limiting both the actions an admin can take and the users/devices those actions can be applied to. In Intune RBAC, scope tags enable you to constrain an admin’s visibility and actions to a defined set of users and devices - for example, only the devices assigned to a specific region, business unit, or platform team. When implementing RBAC policies, limit both the actions and users/devices an admin has permissions over. Call to action: Treat Intune administration as a set of job-specific roles, not a blanket entitlement. Inventory who has Intune Administrator, Global Administrator, or other high-impact roles, then remove broad assignments that don’t map to a named job function. Leverage Intune built-in role definitions for common personas (Help Desk Operator, Application Manager, Endpoint Security Manager, Read Only Operator) and standardize assignments. Create custom roles for ultimate least-privilege control. Implement scoped administration (scope groups and scope tags) for business units, regions, or platform teams, and validate that admins can only affect resources within their assigned scope. Adopt time-bound privilege elevation such as Microsoft Entra Privileged Identity Management (PIM) for admin roles and require reauthentication on elevation and sensitive operations. 2) Embrace phishing-resistant authentication and privileged access hygiene The security objective is straightforward: privileged access should be hard to obtain and hard to reuse. Microsoft Entra ID capabilities (Conditional Access, phishing-resistant multifactor authentication (MFA), risk signals, and privileged access controls) provide the policy engine that governs who can administer Intune, from where, and under what conditions. Call to action: Every privileged Intune action (Intune RBAC Role Management, device wipe, script deployment) should require strong, policy-verified sign-in, not just a password. Create Conditional Access policies dedicated to privileged roles and admin portals (Intune, Microsoft Entra, and related admin endpoints): require phishing-resistant authentication only, require a compliant device, challenge high-risk users or sign-ins, and restrict access by location or trusted network where feasible. Reduce or eliminate policy exclusions. Eliminate standing access by using Microsoft Entra Privileged Identity Management to assign time-bound roles based on conditions and approval steps, including restricting access to who can administer and assign permissions to apps. Move privileged accounts to phishing-resistant authentication methods and disable weaker methods for those accounts and through policy (see Plan a phishing-resistant passwordless authentication deployment). Establish privilege admin workstations with higher security baselines and use them for Intune high privilege admin accounts. Operationalize your token theft response plan by investigating risky sign-ins and unusual admin activity in Microsoft Defender XDR with signals from Microsoft Entra, Microsoft Defender for Cloud Apps, and Microsoft Defender for Endpoints. Adopt a defense‑in‑depth strategy to reduce the risk and impact of token theft (see Protecting tokens in Microsoft Entra). 3) Multi-admin approval in Intune for sensitive changes Multi Admin Approval introduces a practical governance control: selected Intune changes require a second authorized admin to review and approve before deployment. This is enforced for both Intune admin center actions and actions performed through Intune APIs. Multi Admin Approval reduces the risk that a single action can result in tenant-wide impact. Call to action: Require a second approval for high-impact Intune workflows (such as Intune RBAC role management, device wipe, and script deployment) to add an additional safeguard and help contain potential tenant wide impact. Decide which change types require approval - start with high-impact changes such as Intune RBAC role management and device wipe. Then, add access policies for changes that affect authentication, compliance, security baselines, or broad assignment scopes. Define approver roles and coverage (who can approve, SLAs, and what happens during incidents). Document an emergency/break-glass path with explicit post-change review, so speed doesn’t erase governance. How these measures add up to strong administrative protections When combined, these practices help you shift from relying on “trusted administrators” toward building a more protected administration by design: least-privilege to contain impact, Microsoft Entra-based controls to ensure users are trusted and are who they say they are, and multi-admin approval to govern the changes that matter most. These practices help organizations advance safer speed, clearer separation of duties, stronger audit readiness, and more resilient endpoint operations. If you’re looking for a place to start, here are a few quick steps: start with a quick wins pass - inventory broad, standing Intune role assignments and replace them with least-privilege RBAC roles; enforce Conditional Access and adopt phishing-resistant multifactor authentication for all admin scenarios; and place Intune RBAC role management, device wipe, script deployment behind multi-admin approval.
Microsoft Feedback Portal account is not working
I changed my Microsoft password a year ago, and it updated everywhere other than the Feedback Portal. As a result, I get an error when I try to login, or do anything on the page. Microsoft account support's suggestion was to login to the Feedback Portal which is insane given I'm having issues accessing it. How can I get this issue resolved? I've got three separate support tickets now and they keep asking me to wait 24 hours to get the issue resolved. Can someone from the Feedback Portal team please contact me to resolve this?" This is what Microsoft Support have said: "understand your frustration, and yes—this is an account‑related issue because the Feedback Portal is still tied to your old alias, which causes login conflicts and forces you out. Your Microsoft account itself signs in correctly, but the Feedback Portal is pulling outdated identity data that you cannot update on your own. Since you cannot access the Portal to submit feedback, directing you back there is not a workable solution. What you need is for Support to escalate this to the internal Identity/Feedback Platform engineering team so they can manually correct the outdated alias mapping on the backend. In this situation, the Feedback Portal and Tech Community teams are the ones who manage and maintain that specific platform. Because the issue appears on the Feedback Portal side—even though your Microsoft account is working normally—only their dedicated team can make the necessary corrections on their end. That’s why we are guiding you to connect with them through the links provided: https://techcommunity.microsoft.com/ or https://feedbackportal.microsoft.com/feedback. They will be able to review the portal‑specific account data and assist you further. I understand why this is frustrating. Since you’re unable to stay signed in to the Feedback Portal, I completely see why posting there isn’t possible for you. However, I do need to be transparent: I’m not able to escalate this issue directly to the Feedback Portal team, as they don’t provide internal escalation channels for us and only accept requests through their own platform. "
My Azure login is stuck at MFA and cannot proceed
In August, I was still able to log in to Azure, and by logging in through GitHub I could bypass 2FA. But now, no matter how I try, logging in via GitHub always requires 2FA. I can’t access my Azure account anymore—nothing works. The system prompts me to use Microsoft Authenticator to confirm a two-digit code in real time. My Microsoft Authenticator on my iPhone is logged into the same Microsoft account, but I’m not receiving any verification requests for Azure login. No matter how much I refresh, nothing shows up. I’ve already updated the Microsoft Authenticator app to the latest version from the App Store. However, my personal Microsoft account works fine and can log in without any issues.
Microsoft Authenticator Passkeys for Entra ID on unmanaged devices
Hello, has anyone successfully registered passkeys on an unmanaged phone in an organisation with device compliance policies? Use case is to provide a phishing-resistant MFA option via Authenticator app for logging into apps on their desktop. Users already have authenticator app on their phone and do number matching MFA. https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-register-passkey-authenticator?tabs=iOS When I select "Create a passkey" - I need to log into my account. However I'm blocked from successful authentication because I have conditional access policies to require compliant devices. As my mobile phone is not enrolled into Intune, I never get to the step where the passkey is created and registered. Based on the constraints - it seems like passkeys cannot be used for unmanaged/BYOD devices for organisations that have device compliance policies. It can only be used for users who have enrolled their mobile phone. Looking to see if anyone has tips or different experience using passkeys on unmanaged mobile phones to log into Entra?Upcoming changes to iOS/iPadOS Company Portal app deployment for Setup Assistant with modern auth
Learn more about plans to remove automatic deployment of the iOS/iPadOS Company Portal app as a required app for Automated Device Enrollment (ADE) Setup Assistant with modern authentication enrollment profiles.Windows Hello for Business 0x80090010 NTE_PERM
Hi all, I'm encountering an issue with Windows Hello for Business on the latest version of Windows (July 2025 update). The setup process fails during initialisation, and no biometric or PIN options are being provisioned for the user. Environment: Windows version: 11 24H2 Enterprise (latest update) Deployment mode: Hybrid Cloud Trust Hybrid joined devices Symptoms: Users are prompted to set up WHfB but the process fails at the last step with error 0x80090010 Users who already have WHfB authentication methods created can successfully login Event ID 311 & 303 in the User Device Registration logs Screenshots: Troubleshooting so far: Unjoined and rejoined to Entra ID Granted modify permissions on folder in which NGC container would be created Rolled back to June 2025 update (this worked) So it seems like this is caused or related to the latest Windows Update, which is rather unfortunate for us as we are just beginning to rollout WHfB for our organisation. I'm posting here to raise awareness of the issue, if there is a more appropriate place to post then please suggest.Support tip: Aligning network policy with Microsoft Intune and Zero Trust
By: Jon Callahan – Sr Product Manager | Microsoft Intune Cloud services don’t just rely on the network. They redefine it. As organizations adopt Microsoft Intune and advance their Zero Trust strategies, many discover that traditional, perimeter-based architectures no longer align with modern security expectations or the connectivity needs of a distributed workforce. Zero Trust is built on the principle of "never trust, always verify,” where access decisions are enforced through identity, device health, and compliance signals. Microsoft Intune strengthens this model by extending security and management through the cloud. By removing dependencies on on-premises infrastructure, it strengthens network resilience and Zero Trust enforcement with policy-driven device management and secure connectivity to Microsoft endpoints. This is where friction occurs. Traditional enterprise networks were built around a castle-and-moat model of perimeter defense: build high walls around the perimeter and trust everything inside, rather than identity-based access. Centralized egress points, VPNs, proxy servers, and deep packet or TLS inspection worked well when apps, data, and users stayed inside the moat. Today, work and data are everywhere. Legacy network designs often force traffic into hairpinned routes (indirect paths through central gateways) that add latency, reduce performance, and increase management overhead for Intune, Microsoft 365, and other SaaS apps. The challenge deepens when network teams try to maintain allow lists for cloud services using static IP addresses. Microsoft’s endpoint IPs can change frequently, especially with CDN-backed services like Intune and Microsoft 365, to strengthen security, improve resilience, and scale globally. This is why Microsoft recommends domain-based egress policies, frequent updates based on the published endpoint lists, and bypassing SSL inspection for Microsoft-bound traffic that doesn’t support inspection. Enabling cloud services The shift to hybrid work environments shows the limits of perimeter-based networks. Users expect fast and reliable access to their apps and data whether at home, in the office, or on the go. To support this shift, organizations need to modernize their network architecture and policies. Local internet egress and optimized paths to trusted services like Intune are essential. Policies built on Zero Trust and cloud-native principles help ensure performance and security. In contrast, controls such as VPN-only access, TLS inspection, or centralized proxies often slow users down and block required endpoints. When networks get in the way, the impact is noticed: Device check-ins and compliance evaluations fail, leaving devices marked as non-compliant Enrollments stall or time out Apps download slowly, fail to update, or never install When these failures occur, users often blame Intune or their IT admins, even when the real issue is network policies. In a Zero Trust model, network policy works alongside identity and device-based signals to enforce access decisions. Network policy should enable cloud services, not obstruct them. Adopting cloud-native connectivity and Zero Trust enforcement protects users, devices, and data while improving reliability and user experience. This approach aligns with Microsoft’s Secure Future Initiative (SFI) and the principle of “Secure by Design,” which extend Zero Trust principles into the foundation of how services are built and operated. As part of this effort, Intune service endpoints are moving to Azure Front Door to enhance security, reliability, and performance while simplifying firewall management across Microsoft services. For details on required IP addresses and endpoints, see Support tip: Upcoming Microsoft Intune network changes. Outbound traffic management Aligning network policies with Zero Trust and cloud-native architecture can require trade-offs. Outbound traffic management is critical for Intune’s performance, but organizations differ in their compliance needs and tolerance for complexity. Below are three common models we see with our customers. Endpoint enforced access This model eliminates perimeter bottlenecks by moving enforcement closer to the user, device, and apps, which is the core of Zero Trust. Enforcement happens at the endpoint through identity, compliance, and device health signals, while the network provides fast, direct internet access with minimal restrictive filtering. Best for: Organizations ready to adopt a Zero Trust network architecture built on Intune and identity-driven signals, or those with minimal outbound filtering requirements. How to implement: Policy-based enforcement and compliance: Intune enforces and validates device health and measures device compliance and app protection policies for Microsoft Entra Conditional Access Identity-driven enforcement: Microsoft Entra Conditional Access evaluates signals such as user identity, device compliance, and risk level before granting access to cloud resources Threat protection: Microsoft Defender for Endpoint monitors device risk and blocks compromised endpoints from accessing cloud resources; enforce the built-in firewall on Windows and macOS devices Bypass traffic inspection: Don’t decrypt or inspect Intune and related Microsoft traffic using technologies like proxies, TLS inspection, deep packet inspection, or data loss prevention systems Use split-tunnel VPN and local internet egress: Route Intune and Microsoft 365 traffic locally to avoid unnecessary hairpinning Benefits: Establishes Zero Trust controls with identity, device, and threat-based enforcement Local internet egress and optimized paths to Intune and Microsoft 365 avoid latency and centralized paths No allow list or complex firewall rules to manage Avoids VPN, proxies, and TLS inspections and reduces the risk of interfering with user experience and device management failures This model requires strong endpoint management and identity controls to ensure Zero Trust enforcement. Domain enforced filtering When endpoint-only enforcement doesn’t meet your organization's requirements, Fully Qualified Domain Name (FQDN) filtering offers a middle ground by adding network controls while staying adaptable to dynamic cloud services. This approach should be paired with endpoint enforcement to maintain a Zero Trust architecture. Best for: Organizations that need outbound restrictions for compliance, while maintaining reliability and flexibility in cloud services. How to implement: Use domain-based rules: Filter traffic by FQDN rules that rely on DNS to adapt to changing IP addresses and CDN-backed services. Leverage automation: Leverage the consolidated endpoint list, Azure Firewall service tags, or vendor tools to keep rules up to date. Bypass traffic inspection for trusted services: Avoid decrypting or inspecting Intune traffic, which can break certificate pinning and cause service failures. Resolve locally: Use local DNS and Internet egress so devices connect to the closest Microsoft endpoint. Benefits: Builds on endpoint enforced Zero Trust controls Easier maintenance than IP-based filtering Automatically adapts to Microsoft's dynamic, cloud-hosted services Reduces service disruptions when automated Aligns with most regulatory and compliance frameworks This model requires more robust network automation and may introduce additional processing overhead compared to endpoint-enforced access. Domain and IP enforced filtering This model combines FQDN-based rules with IP filtering for the strictest assurance. It provides maximum control but introduces the most overhead. Like domain enforced filtering, this too should be combined with endpoint enforcement to maintain a Zero Trust posture. Best for: Organizations in highly regulated industries that require dual enforcement with domains and IPs to meet strict audit and assurance needs. How to implement for Intune: Combine domain with IP rules: Use FQDN alongside IP address ranges to filter traffic. Automate aggressively: Leverage the consolidated endpoint list, Azure Firewall service tags, or vendor tools to keep rules up to date. Bypass traffic inspection for trusted services: Exclude certificate-pinned services from TLS inspection to avoid breaking Intune functionality. Optimize performance: Architect your network to use local DNS and internet egress so devices connect to the closest Microsoft endpoint. Benefits: Builds on Zero Trust with the strictest network controls Provides dual verification for outbound traffic Helps satisfy strict regulatory and compliance requirements This model introduces the highest administrative overhead and complexity to maintain. It’s also the most likely to cause performance issues and service disruptions if not properly automated. However, for organizations with strict regulatory requirements, these trade-offs may be necessary to meet compliance obligations. Extending with cloud-first controls While traditional network models address outbound traffic at the infrastructure layer, a Zero Trust approach uses cloud-native security tools that eliminate many of these challenges. Issues like hairpinning, brittle IP allow lists, TLS inspection conflicts, and complex firewall rules stem from applying perimeter-era tools to cloud-based services. Cloud-first network and security tools reduce friction and strengthen Zero Trust. Cloud-delivered secure web gateway (SWG): Provides secure access to internet and SaaS apps while protecting against internet threats, building on the capabilities of traditional proxies (Microsoft Entra Internet Access) Zero Trust Network Access (ZTNA): Connects users securely from any device and any network without relying on VPNs or central tunneling (Microsoft Entra Private Access) Data loss prevention (DLP): Protects sensitive information across endpoints, Microsoft 365 apps, SaaS services, browsers, and on-premises file shares, with classification and policy enforcement (Microsoft Purview DLP) Cloud access security broker (CASB): Provides SaaS discovery, session control, and real-time policy enforcement (Microsoft Defender for Cloud Apps) Managing outbound traffic for cloud services is about more than connectivity. It’s about aligning network policies so they enable cloud services and embrace Zero Trust principles like identity, device health, and compliance signals over legacy perimeter defenses. Microsoft Intune supports through policy-driven device management and security that reinforce Zero Trust and cloud-native adoption. The result is an architecture that secures your environment and delivers the reliability and user experience needed for today’s hybrid work. Resources Intune network endpoints US government network endpoints for Intune China endpoints for Intune Support tip: Upcoming Microsoft Intune network changes Microsoft 365 network connectivity overview Azure Front Door Azure service tags Microsoft Secure Future Initiative (SFI) Microsoft Zero Trust As always, if you have any questions let us know in the comments or reach out to us on X @IntuneSuppTeam! Post updates: 11/06/25: Updated URLs for Automation category (see Domain-Enforced Filtering section).
failed set-up of a passkey for a personal MS account
After scanning the QR code (on the PC screen) in the Authenticator app on the Iphone, the error message “Error adding the passkey - Microsoft Authenticator does not support this passkey” (translated from German) appears. What does this mean ? How to prevent? Any help is appreciated.
