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.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.Hybrid Modern Auth for SfB and Exchange goes GA!
Today, I am very happy to announce General Availability (GA) for Hybrid Modern Authentication (HMA) for Skype for Business and Exchange. This is a major milestone in our Modern Authentication journey. This will enable customers to use Modern Auth enabled security features such as Multi Factor Authentication (MFA), Cert Based Authentication (CBA), AAD Conditional Access (CA) and Intune Mobile Application Management (MAM) for all their users, both those homed online as well as those homed onprem. Here is a visual of the topology: This design requires you to use Azure Active Directory as the authorization server for your onprem SfB and onprem Exchange deployments (note the blue arrow from SfB onprem and Exchange onprem to AUTH in the cloud). The prerequisites and instructions to enable HMA can be found here: https://aka.ms/ModernAuthOverview Updated list of SfB MA Supported Topologies is here: Skype for Business topologies supported with Modern Authentication Also, two of my colleagues have published their own excellent blogs on this topic. Announcing Hybrid Modern Authentication for Exchange On-Premises Hybrid Modern Authentication for Skype for BusinessWindows 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.SfB Server Now Supports Blocking NTLM Externally
I am happy to announce that with the CU7 version of SFB Server 2015, we have added the ability to block external NTLM traffic. This, along with the use of Cert Based Authentication, will allow you to protect your SFB servers from external DOS attacks using username/passwords. Let me explain. SfB server allows the following protocols that all accept username/passwords – NTLM, Forms Based Auth and Modern Authentication. In order to combat the DOS attacks, you have to shut down all the external ways that allow username/password. With the new Get/Set-CsAuthConfig cmdlets in CU7, you can shut down NTLM and Forms Based Auth externally. Then, you configure your servers to only accept Certificate Based Auth externally. (NOTE: You need Modern Authentication to use CBA.) Now all the username/password doors are shut and your users use CBA to get in externally. Here is an article that explains the details: Turn off Legacy authentication methods internally and externally to your network.
Deploying Platform SSO for pre macOS 26 with Microsoft Intune: Lessons Learned
By: Naveen Akkugari, Sr. Service Engineer and Michael Griswold, Principal Service Engineering Manager | Microsoft Intune Who we are Our internal Intune administration team at Microsoft is responsible for running Intune and Configuration Manager for the devices used by employees. We receive early access to features for evaluation and feedback using real world usage scenarios. As such, some features may be changed before the public release and be slightly different. The experience should be similar and we wanted to share our learnings when deploying platform single sign-on (PSSO). It is worth noting that since the time of this experience a new method for newer OS versions is available and you can read more about it at: New Platform SSO with registration during Automated Device Enrollment on macOS | Microsoft Community Hub. Why we implemented Platform single sign-on (PSSO) and what we learned As IT admins managing a growing Mac fleet, we kept running into the same gap. Our Windows devices had hardware-backed authentication, token protection, and seamless SSO through Windows Hello for Business, but our Macs were still relying on browser-based prompts with no easy way to enforce the same level of security and identity protection. Platform SSO finally closed that gap for us. It’s worth noting that new macOS allows new capabilities in this space and we are evaluating them as well. The new flow can be read about at https://aka.ms/Intune/MacPSSO-Setup. While there were fewer pip-ups, we found the changes in the security layer to be the real value to our operations. Platform SSO binds authentication tokens (Primary Refresh Tokens) to the device’s Secure Enclave hardware. Even if a PRT is intercepted, it’s designed to not be replayed from another device. For our team, this unlocked two things we couldn’t do on macOS before: Token protection policies: Conditional Access can now verify that tokens are device-bound, the same enforcement we had been relying on with Windows Hello for Business Phishing-resistant MFA: Secure Enclave keys act as FIDO2 passkeys, so users authenticate with Touch ID instead of passwords or SMS codes Getting from documentation to production took real effort for us. A password policy issue that silently blocked registration for half our pilot group, users who swiped away the registration banner without knowing what it was, and macOS updates that broke SSO overnight. This blog post is what we wish someone had written before we started. How it works under the hood: Intune delivers the SSO extension profile → macOS prompts the user to register → the device registers with Microsoft Entra ID and gets a hardware-bound workplace (WPJ) certificate → a PRT is issued and bound to device hardware (not designed to be exported) → SSO works across Microsoft 365 apps, browsers, and Kerberos resources, all with token protection enforced. Available authentication methods when we implemented Capability Secure Enclave Smart Card Password Sync Passwordless and phishing-resistant ✅ ✅ ❌ Touch ID / passkey (WebAuthn) ✅ ❌ Touch ID only ❌ Local password synced with Microsoft Entra ❌ ❌ ✅ Minimum macOS 13.0 14.0 13.0 Recommendation: Start with Secure Enclave. Keys are hardware-bound, phishing-resistant, and double as FIDO2 passkeys via WebAuthn, enabling browser-based passwordless login (Touch ID instead of passwords) and meeting Conditional Access multi-factor authentication (MFA) requirements. Unlike iCloud-synced passkeys, these are device-bound, aligning with Zero Trust. Quick setup using the Intune settings catalog Prerequisites: macOS 13+, Intune with Microsoft Entra ID, Intune Company Portal v5.2404.0+ In the Intune admin center, navigate to Devices > Configuration > Create > macOS > Settings Catalog > Authentication > Extensible SSO Setting Value Extension Identifier com.microsoft.CompanyPortalMac.ssoextension Team Identifier UBF8T346G9 Type Redirect Registration Token {{DEVICEREGISTRATION}} Use Shared Device Keys Enabled Screen Locked Behavior DoNotHandle URLs https://login.microsoftonline.com https://login.microsoft.com https://sts.windows.net https://login-us.microsoftonline.com Users see a “Registration required” notification → sign in → complete MFA → SSO works everywhere. What the user experience looks like Knowing what users see on their screen helps you write better rollout communications and cuts down help desk tickets. First-time registration flow: Profile arrives silently: After enrollment, Intune pushes the SSO extension profile to the Mac. Nothing visible to the user yet. Registration banner appears: macOS displays a notification: “Registration required: Your organization requires you to register your device.” The user must click this to proceed. (This is our #1 learning point, users swipe it away, and there’s no simple way to retrigger it.) Sign-in window: The user enters their Microsoft Entra ID email and password. MFA challenge: Authenticator app push, phone call, or other configured method. Secure Enclave key creation: macOS generates a hardware-bound key pair. The user may see a Touch ID or local password prompt to authorize this. Registration completes: Device registers with Microsoft Entra ID, a WPJ certificate and PRT are issued. User sees a success confirmation. SSO is active: From here, Microsoft 365 apps, Edge (natively), Chrome (with SSO extension), and Kerberos resources authenticate without prompts. Touch ID replaces password entry. Missed the registration notification? Here is how to manually register: This was our most common help desk ticket during rollout. If a user dismissed or missed the banner, they can still register manually through the following options: (Recommended) System Settings → Users & Groups → Network Account Server: This is the easiest method. Go to System Settings → Users & Groups, scroll down to “Network Account Server” and click “Edit.” This opens a panel showing two sections: Network Servers and Platform single sign-on. If the Platform SSO policy is deployed, “Mac SSO Extension” will be listed under Platform single sign-on. If the device isn’t registered, there will be a “Register” button that can be selected to start the Platform SSO device registration flow. Lock / Sign out and back in: Performing a lock or signing out of macOS followed by signing back in can retrigger the registration notification upon the next login attempt. Wait for the notification to reappear: macOS retries the notification periodically around every 15 mins. Last resort, reprofile: If none of the above work, an IT admin can remove and reassign the SSO extension profile in Intune. Before doing so, ensure any stale device objects are cleared from Microsoft Entra ID to avoid conflicts. Once the new profile lands on the device, the registration notification reappears. How to verify Platform SSO registration One of the first questions we got after rollout was “how do I know it’s actually working?” Here’s how both users and IT admins can confirm. For IT admins (Microsoft Entra ID & Intune admin centers): What to check Platform SSO registered device Non-registered device Microsoft Entra ID → Devices Join Type shows Microsoft Entra joined Join Type shows Microsoft Entra registered Intune → Device configuration SSO extension profile shows Succeeded Profile may show Pending, Error, or not assigned For users (on the Mac): System Settings → Users & Groups → Network Account Server: Scroll down in Users & Groups to “Network Account Server” and click “Edit.” If the Platform SSO policy is deployed, they will see “Mac SSO Extension” listed under Platform Single Sign-on. A registered device shows a green dot with “Registered” status and a “Repair” button (useful if registration gets into a bad state). If not registered, they will see a “Register” button instead. This is the quickest at-a-glance check for users. System Settings → Users & Groups: Click on the user account name in Users & Groups (on macOS 14+, click the info button “i” next to the user name). When Platform SSO registration is complete, a “Platform Single Sign-on” section will be listed under the account. If Platform SSO is active, the user account shows the Microsoft Entra ID identity linked to the local account. Company Portal app → Devices: The device should show as “Compliant” and “Microsoft Entra ID registered.” If registration failed, it shows “Registration required.” Terminal command: Run app-sso platform -s to check Platform SSO status. Troubleshooting Platform SSO errors If you run into issues during deployment, here’s how you can diagnose and fix issues. Step 1: Check the Platform SSO profile in Intune device management Before troubleshooting on the Mac itself, confirm the profile reached the device: In Intune: Go to Devices → select the device → Device configuration. The SSO extension profile should show “Succeeded.” If it shows “Pending” or “Error,” the device hasn’t received the policy. Check assignment groups, sync status, and whether the device is enrolled. Then on the Mac: Go to System Settings → General → Device Management (or Profiles on older macOS). Look for the SSO extension profile (com.apple.extensiblesso). It should show as “Installed” with no errors. If the profile isn’t listed, it hasn’t been delivered yet. Check Intune assignment and device sync. Step 2: Check registration status on the Mac Refer to the previous section “How to verify Platform SSO registration” for steps. Step 3: Check SSO extension logs Run in Terminal for real-time logs: log stream --predicate 'subsystem == "com.apple.AppSSO"' --level debug Then prompt a sign-in (open Edge or Outlook). Look for: Error 10002: Duplicate SSO profiles. Remove the extra one from Intune. Error 10003: Registration failed. Usually a network issue or TLS inspection blocking auth URLs. User cancelled: User dismissed the registration banner. Token refresh failed: PRT could not refresh. Check network and whether the Microsoft Entra ID password was recently changed. Step 4: Verify from the admin side Check How What It Tells You Profile delivery Intune > Devices > select device > Device configuration Whether the SSO profile reached the device and its install status Registration state Entra ID > Devices > search device > Properties Whether the device has PSSO registration and NGC credential Sign-in failures Entra ID > Sign-in logs > filter by user Error codes like AADSTS50076 MFA required, AADSTS700024 token issue, or AADSTS7000218 client assertion Token protection Entra ID > Sign-in logs > Conditional Access tab Whether token protection policy was applied or skipped Company Portal version Intune > Apps > macOS > Company Portal Must be v5.2404.0+ for PSSO; older versions silently fail Common error codes and fixes: Error Cause Fix 10002 Multiple SSO extension profiles assigned Remove duplicate profiles; keep only the Settings Catalog policy 10003 Registration failed network/TLS Allowlist Apple and Microsoft auth URLs from TLS inspection AADSTS50076 MFA required but not completed User needs to complete MFA during registration AADSTS700024 Client assertion invalid Password likely needs reset; have user reset Entra ID password and retry AADSTS7000218 Request body must contain client_assertion Company Portal version too old; update to v5.2404.0+ Best practices Have newer OS devices and use the new flow: New Platform SSO with registration during Automated Device Enrollment on macOS. Have users reset their password before Platform SSO registration. During initial enrollment, if password configuration or compliance policies are applied, users are required to reset their password after device enrollment and prior to initiating Platform SSO registration. Skipping this step can result in silent registration failures that are difficult to diagnose. Ensure this is communicated as the first step in your rollout guidance. Assign the SSO profile during enrollment, not after. Deploying during enrollment means the registration prompt shows up at first login, a natural part of setup. Retrofitting existing devices forces users to notice and click a notification banner. Many will not. macOS Tahoe (26) Simplified Setup will auto-register, removing this friction. One SSO profile per device, no exceptions. Duplicate profiles cause Error 10002. If you are migrating from a Device Features template to Settings Catalog, remove the old one first. Pilot with realistic scenarios. Don’t just test “can I open Outlook.” Test registration, SSO to Microsoft 365, on-prem file shares, password change mid-session, reboot behavior, and what happens when a user dismisses the registration banner. We found issues in every one of these. Align password policies end-to-end. For Password Sync, Intune compliance and Microsoft Entra ID password policies must match: length, complexity, expiration. Integrate legacy Kerberos properly. If you run a standalone Kerberos SSO extension, set usePlatformSSOTGT = true in its ExtensionData to reuse Platform SSO TGT instead of running duplicate flows. Requires macOS 14.6+ and Company Portal 5.2408.0+. Enable Kerberos SSO to on-premises Active Directory and Microsoft Entra ID Kerberos Resources in Platform SSO. Allowlist auth URLs from TLS inspection. Apple and Microsoft authentication endpoints must be excluded from proxy/TLS inspection. If they are not, registration fails silently with no error. Challenges we faced Challenge What we experienced Solution Password must be reset before registration during the new enrollment Half our pilot group could not register after the new enrollment as their Entra ID password had not been reset. Require a password reset before rollout; make this step 1 in user communications Users dismiss the registration banner The notification is easy to swipe away. Once dismissed, there is no simple way to retrigger it. Send screenshots and instructions before rollout; macOS Tahoe auto-registers via Simplified Setup SSO breaks after macOS updates After point updates, SSO stopped working until re-registration. Restart swcd process; some cases required full re-registration; check release notes Password policy mismatch Users changed Microsoft Entra password, but local Mac password did not sync, causing lockouts. Match Intune compliance and Microsoft Entra ID password policies exactly; test end-to-end Browser SSO inconsistency Edge worked natively, Chrome needed extension, Safari varied by OS. Deploy Chrome SSO extension via Intune; test Safari on each target OS version Conclusion Platform SSO delivers phishing-resistant passwordless authentication, seamless cross-platform SSO, and Conditional Access compliance with hardware-backed identity. Start your implementation with Secure Enclave, deploy via Intune Settings Catalog, pilot small, then scale. If you have questions on implementing Platform SSO, leave a comment below or reach out to us on X @IntuneSuppTeam. 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.SfB Hybrid Modern Auth w/ EXO goes Public Preview
Last week at Microsoft Ignite, we announced that Modern Authentication for Skype for Business server has gone to Public Preview. This means that the following topologies are now supported in Public Preview. Note: the grayed out boxes mean they do not exist in the deployment. These configurations will enable customers to use Modern Auth enabled security features such as Multi Factor Authentication (MFA), Cert Based Authentication (CBA), Conditional Access (CA) and Mobile Application Management (MAM) for users who are homed onprem as well as those homed in the cloud. Both of these topologies require you to use Azure Active Directory as the authorization server for your onprem SfB deployment (note the blue arrow from SfB onprem to AUTH in the cloud). To see the full list of pre-requisites and to join “Hybrid Modern Authentication - w/ Exchange Online” Public Preview, please go to http://aka.ms/skypepreview .
