OneDrive for macOS documentation issue. DefaultFolder plist example is missing array wrapper
Hi everyone, The Microsoft Learn documentation for configuring the OneDrive sync app on macOS currently contains an incorrect plist example for the DefaultFolderLocation setting. Documentation page: https://learn.microsoft.com/en-us/sharepoint/deploy-and-configure-on-macos#defaultfolderlocation In the “DefaultFolderLocation” section, the current plist example shows the DefaultFolder key as a dictionary: <key>DefaultFolder</key> <dict> <key>Path</key> <string>(DefaultFolderPath)</string> <key>TenantId</key> <string>(TenantID)</string> </dict> This format does not work correctly when deployed as a managed preference/configuration profile. The setting starts working when the DefaultFolder dictionary is wrapped in an array, like this: <key>DefaultFolder</key> <array> <dict> <key>Path</key> <string>(DefaultFolderPath)</string> <key>TenantId</key> <string>(TenantID)</string> </dict> </array> Please update the Microsoft Learn documentation to include the array wrapper in the DefaultFolder plist example. The current Microsoft Learn example is confusing because administrators may deploy the documented plist exactly as shown, but the setting does not appear to work correctly until the array wrapper is added.New iOS/iPadOS, visionOS, tvOS and macOS ADE enrollment policies experience
By: Anya Novicheva – Sr. Product Manager | Microsoft Intune Coming with the 2606 service release (end of June), iOS/iPadOS and macOS automated device enrollment (ADE) profiles will move to a new infrastructure which enables Intune to speed up the delivery of new features. These will be the new enrollment policies experience for Apple devices enrolling through ADE. With this update, you’ll notice the authentication methods are better organized, there’ll be no Company Portal authentication method or automatic deployment of the Company Portal application, Apple-deprecated settings have been removed, and there’ll be more granular admin controls for the policies page. All newly created enrollment policies for iOS/iPadOS/macOS will automatically be part of the new experience. Existing enrollment profiles won’t be affected. You’ll be able to delete, edit, and assign existing enrollment profiles but you’ll no longer be able to create them with the old experience. We recommend creating a new enrollment policy and setting it as the default as soon as this feature releases so new enrollments will use the new policy as soon as possible. All new features releasing after will be part of the new enrollment policies experience moving forward and will not be added to the old enrollment profiles. Coming with the 2604 service release (end of April), you'll be able to create visionOS and tvOS automated device enrollment (ADE) policies with enrollment time grouping. Go to Devices > Enrollment > Apple > Enrollment program tokens > select a token > Enrollment policies > Create. Here, new visionOS and tvOS enrollment policies can be created and assigned to devices that have synced over from Apple Business Manager or Apple School Manager. Additionally, enrollment policies can be deleted or set as the default by navigating to the ellipsis in a policy. Create a new enrollment policy for iOS/iPadOS and macOS ADE In the Microsoft Intune admin center, navigate to Devices > Enrollment > Apple > Enrollment program tokens > select a token > Enrollment policies > Create. Here, new enrollment policies can be created and assigned to devices that have synced over from Apple Business Manager or Apple School Manager. Additionally, enrollment policies can be deleted or set as the default by navigating to the ellipsis in a policy. Benefits of the new experience: Enrollment time grouping support - Enrollment time grouping in Microsoft Intune The columns control can be used to select which columns should be default, which one should be the primary column, and which ones to show or hide. The search bar can be used to search by any column field contents and isn’t case sensitive. The filters control can be used to filter the policies by platform. We’ll add more filtering for the other columns soon. Sort each column by the ascending or descending order by clicking on the column header. No more automatic Company Portal app deployment from the enrollment policy itself or Company Portal as an authentication method option in the drop-down setting. The Company Portal app can still be used and sent down as a required or available app to the device depending on your organization’s needs. We always recommend using Setup Assistant with modern authentication for ADE policies with user affinity as it is the most secure method. However, if you still want to deploy the Company Portal authentication method your users or devices, you can do userless authentication (Enroll with no user affinity for authentication) and deploy the application as needed along with the required app configuration policy to the targeted devices. Note that this is not recommended. The “Install Company Portal”, “Install Company Portal with VPP, and “Run Company Portal in single app mode until authentication” settings aren’t supported and have been removed from the enrollment policy for iOS/iPadOS ADE. For more details refer to the blog: Move to Setup Assistant with Modern Authentication for Automated Device Enrollment Shared iPad for iPadOS ADE has its own authentication method for devices with no user device affinity. Setup Assistant with modern authentication is the default and recommended authentication method for ADE enrollment policies. Assigning new enrollment policies to devices The device assignment flow for ADE policies is the same. Within the policy, navigate to the Devices tab to select a device(s) and select Assign policy. Ensure that you’re assigning a new enrollment policy to the devices. Existing (old) enrollment profiles (only applies to iOS/iPadOS and macOS) Existing enrollment profiles will remain in Devices > Enrollment > Apple > Enrollment program tokens > select a token > Profiles. New enrollment profiles within Profiles cannot and should not be created. Existing enrollment profiles can be deleted, edited, assigned to devices, and viewed. Their device assignments will not be affected or changed. We recommend you migrate your ADE devices from being assigned to old enrollment profiles over to new enrollment policies and always have the Await final configuration setting set to Yes. Additionally, we recommend you set your default enrollment policy to one of your newly created ones from the Enrollment policies tab. Important: If you delete an old enrollment profile, the device rename is no longer enforced (that is if someone changes the device name). Sending the Company Portal app to ADE devices with user device affinity (optional) - iOS/iPadOS only Previously within enrollment profiles, the Company Portal app was sent down automatically to devices with the creation of Setup Assistant with modern authentication and Company Portal authentication profiles. With new enrollment policies, the Company Portal application will never be sent down automatically from the creation or assignment of the enrollment policy. For enrollment policy with user device affinity, we strongly recommend you set the authentication method to Setup Assistant with modern authentication as the most secure and seamless method. For Setup Assistant with modern authentication, the Company Portal is no longer required because of Just in Time registration and compliance Remediation for iOS/iPadOS with Microsoft Intune. However, if you still want to send replicate the Company Portal authentication method for your users or devices, you can choose to Enroll without user affinity (userless) and then deploy the application as needed, along with the required app configuration policy to the targeted devices. Assigning the correct app configuration policy based on the authentication method is critical if you’re sending the Company Portal app to ADE devices without user device affinity. Otherwise, the Company Portal will cause issues on the device and won’t auto-update correctly. However, we highly recommend Setup Assistant with modern authentication as the ADE authentication method for your Apple devices with user affinity. Based on the Company Portal authentication method you use, send the following XML for the app configuration policy: If you're using the Company Portal on an ADE device enrolled without user affinity (also known as Device Staging): <dict> <key>IntuneUDAUserlessDevice</key> <string>{{SIGNEDDEVICEID}}</string> </dict> If you're using the Company Portal on an ADE device enrolling with user device affinity, such as the Company Portal authentication method: <dict> <key>IntuneCompanyPortalEnrollmentAfterUDA</key> <dict> <key>IntuneDeviceId</key> <string>{{deviceid}}</string> <key>UserId</key> <string>{{userid}}</string> </dict> </dict> Stay tuned to What’s new in Intune for the release! If you have any questions, leave a comment on this post or reach out on X @IntuneSuppTeam and we'll provide updates in the blog on the timing of this release. Post Updates: 06/26/25: Updated post with a new ETA of Q4 CY25 (previously Q2 CY25). Also revised the content to better clarify the new experiences and authentication scenarios. 09/12/25: Updated post with a new ETA of Q1 CY26 (previously Q4 CY25). 02/26/26: Updated post with a new ETA of Q2 CY26 (previously Q1 CY26) and expanded scope to include macOS ADE alongside iOS/iPadOS. 04/30/26: Updated post with new ETAs - 2606 (end of June) for iOS/iPadOS and macOS, and 2604 (end of April) for visionOS and tvOS. Title and content updated to reflect the expanded OS scope.Streamlining macOS security: Automatically enable AutoFill after Platform SSO registration
By: Chris Kunze - Principal Product Manager | Microsoft Intune Platform single sign-on (SSO) improves how macOS devices establish identity with Microsoft Entra ID, enabling a more secure and streamlined authentication experience. However, completing Platform SSO registration isn’t enough to deliver a fully passwordless workflow. To enable passwordless authentication in Safari, Microsoft Edge, and Google Chrome, the Company Portal AutoFill extension must also be enabled. In many deployments, this step still depends on the user. Devices may be fully enrolled, and Platform SSO may be successfully registered, yet users can still fall back to entering credentials manually if Company Portal AutoFill is not enabled. At scale, even small manual configuration steps can lead to inconsistent results. The goal of this post is to remove that dependency by automatically enabling AutoFill after Platform SSO registration, so users receive a complete passwordless experience without any additional steps. The challenge After Platform SSO is deployed to a macOS device, two conditions must be met before users receive the intended passwordless experience: Platform SSO registration must be completed The device must complete Platform SSO registration with Microsoft Entra ID. Company Portal AutoFill must be enabled The Company Portal AutoFill extension must be enabled for supported browsers so credentials can be supplied automatically. When Platform SSO registration happens after Setup Assistant, the user is prompted through the registration flow and receives a reminder to enable Company Portal AutoFill. However, enabling AutoFill is still a separate manual step that the user must complete. If the user skips or overlooks that step, the device can be successfully registered for Platform SSO while still requiring credentials to be entered manually. The result is a deployment that appears complete but does not consistently deliver the intended passwordless experience or security posture. Authentication should not depend on user action after enrollment. Especially valuable with the “Enable Registration During Setup” setting This approach becomes especially impactful when combined with the Enable Registration During Setup setting for Platform SSO. When used with Automated Device Enrollment (ADE), Platform SSO registration can be completed automatically during Setup Assistant before the user reaches the desktop. This helps ensure identity registration completes as part of the provisioning experience rather than requiring additional post-enrollment actions. Automating AutoFill after Platform SSO registration After registration has completed, AutoFill often becomes the final remaining step that still depends on user action. To close this gap, you can use a custom script to enable the Company Portal AutoFill extension after Platform SSO registration is complete. The sample script, Check-PSSO.zsh, available in the GitHub repository, was written by the Intune Customer Experience Engineering team. The script detects when Platform SSO registration has completed on a device and then enables AutoFill automatically. Important: Microsoft supports Intune’s ability to deploy scripts, but not the scripts themselves. Microsoft fully supports Intune and its script deployment capabilities. However, Microsoft does not provide support for individual scripts, including scripts published in Microsoft GitHub repositories. These scripts are provided as examples only. You are responsible for reviewing, validating, and testing their behavior in your environment before deploying them broadly. The script essentially performs four key actions: Wait for a user session - The script detects when a user session is active to ensure the device is ready for configuration. Verify Platform SSO registration - It confirms that Platform SSO registration has completed successfully before proceeding. Detect the AutoFill extension - The script waits until the Company Portal AutoFill extension becomes available on the device. Enable AutoFill automatically - Once detected, the script enables AutoFill programmatically, eliminating the need for users to manually configure the setting in System Settings. All activities are logged locally, providing visibility for auditing and troubleshooting. Supported browsers The Company Portal AutoFill extension works with: Safari (native support) Microsoft Edge (native support) Google Chrome (requires Microsoft Single Sign On extension) Once AutoFill is enabled, users can authenticate across all supported browsers on their macOS device without manually entering passwords. System requirements macOS 15 or later Company Portal version 5.2604.0 or later installed on the device Platform SSO configured via an Intune SSO extension profile Deployment via Intune The Check-PSSO script is deployed using a lightweight, scalable approach aligned with modern macOS management practices. The recommended method is to package the script as a payloadless PKG with a pre-install script. High-level steps: Build an empty PKG Attach the Check-PSSO script as a pre-install script Upload the package to Intune Assign it as Required Verify successful deployment through script logs Detailed instructions are available in the GitHub repository. Key Features Polling with timeouts The script waits for the required conditions to be met before continuing, including an active user session and completed Platform SSO registration. To avoid indefinite loops in edge-case scenarios, it uses timeouts while polling for those conditions. Diagnostic logging and auditing Optional verbose logging provides detailed troubleshooting information and an audit trail confirming AutoFill was enabled. Each run is logged locally under: /Library/Logs/Microsoft/IntuneScripts/checkPSSO Clear exit codes Exit 0: Success Exit 1: Failure Benefits of automating AutoFill Automating AutoFill helps ensure users can take advantage of passwordless authentication without additional configuration steps. It reduces reliance on user action, improves deployment consistency, improves security posture, and supports zero-touch provisioning. It also provides admins with verification through centralized logging and reporting. Get started If you’ve already deployed Platform SSO, automating AutoFill is a natural next step toward delivering a complete passwordless experience. By removing a manual configuration step that often depends on user action, you can improve consistency and user experience across devices. When combined with the Enable Registration During Setup setting, this helps create a true zero-touch experience from enrollment through authentication. Learn more Platform SSO for macOS Company Portal for macOS Payloadless Packages in Intune (Tech Community) Microsoft shell-intune-samples Repository Let us know if you have questions by leaving a comment below or reaching out 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.
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.Microsoft Intune and Apple platform updates: What to expect after WWDC 2026
By Benjamin Flamm | Product Manager, Iris Yuning Ye | Product Manager - Microsoft Intune Apple’s Worldwide Developers Conference (WWDC) is the annual starting point for the next wave of Apple platform changes. For Microsoft Intune customers, WWDC is also the moment when IT teams begin planning how new operating system capabilities will affect Apple device management, security, app deployment, and user readiness ahead of the fall OS releases. We’ve spent time watching and re-watching the sessions, sifting through new documentation with a magnifying glass, and philosophizing over the impact of what’s new this year. Just like every year, we’ll still have our day zero blog officially announcing what Intune supports for the new OS versions; however, this year we’ve heard your feedback that you’d like to know where Intune is prioritizing investments ahead of time so that you can prepare with confidence. What’s new in managing Apple devices Our team is absolutely thrilled by the latest WWDC announcements and what they mean for organizations using Intune to manage Apple devices at scale. Apple is executing their promise of a declarative future, and we’re excited to enable our customers to leverage the benefits of declarative device management (DDM) like efficient configurations and real time status reporting. Most importantly, Apple continues to provide new customer-delighting functionality that previously didn’t exist in the legacy protocol. Data-driven settings The Intune settings catalog is our data-driven experience that automatically generates UI based on a schema. Basically, Intune adds new settings very quickly. Our goal is to always provide new settings like restrictions and intelligence controls as fast as possible, but in a way that’s enterprise ready. Having to manually create policies in third party tools just to upload them into the Intune admin center is a thing of the past. That said, these are the configurations and settings announced at WWDC 2026 that will be available very soon in the settings catalog for testing on the OS 27 betas. Allow and deny binaries on macOS One of the biggest announcements for device management this year is the new App settings configuration which includes declarative binary management for Mac. Until now, admins have relied on third party tooling and scripting for controlling unwanted apps on macOS, which is a clunky and time-consuming process. This new configuration also brings privacy permission management to DDM, reducing the number of prompts that users see while ensuring that apps have the permissions they need. Content caching Content caching has been supported in mobile device management (MDM) and our settings catalog for years, but it’s becoming much more powerful as it moves to DDM in macOS 27. New status items provide richer information about the health, disk space, and usage of content cache services without requiring a separate monitoring agent. This will be especially useful for everyone who wants to significantly reduce network traffic due to large deployments such as multi-gigabyte app installations and OS updates. Platform Single Sign-on Platform Single Sign-on (Platform SSO) picked up a major set of upgrades this year as part of its transition to DDM: the option to require Touch ID as a built-in second factor for logging in and unlocking FileVault. Additionally, new web-based authentication that opens the door to customizable push notifications, one-time codes, and QR-code sign-in for shared-device environments. New skip keys for Automated Device Enrollment Our settings story wouldn’t be complete without mentioning skip keys, and we have so much to mention this year! You may have seen the news that we recently updated our Apple enrollment policies, but what you may have missed is that these use the same infrastructure as our settings catalog. Starting this year, you should now expect to see skip keys release as fast as the Apple settings catalog. Settings, settings, and more settings Everything we’ve talked about so far is only the tip of the iceberg for settings and what’s coming, so here’s the complete list of what you should expect to see in Intune this summer: App Settings Allow/deny macOS binaries App privacy Content caching DNS Settings DNS Proxy Extensible SSO Safari privacy Web Content Filter Apple Intelligence (Calendar) Device restrictions Skip keys Network configurations are now in DDM This is the announcement that we’ve been waiting for ever since Apple first showed us the power of DDM! While there isn’t Wi-Fi support yet, we’re thrilled to see this first step into DDM-based network configurations. The on-device user experience and admin configuration experience will see significant improvements in comparison to today’s profile model, especially when managing policies that depend on certificates for authentication. Our team is evaluating the new network configurations for our roadmap as we build support for these critical workloads in a declarative world. Fleet monitoring and MDM status The more device information that Apple moves to DDM, the faster Intune will become. The 15-minute check-in will soon be obsolete as MDM can solely rely on the device to detect drift or issues. This year, Apple has continued to add more device information to the DDM status channel, allowing admins to get a richer picture of the health of their device fleet. Device health reports that highlight whether a specific hardware component is operating normally, or experiencing an issue, will provide useful insights to organizations when planning their next device refresh cycle or monitoring for device issues before they affect productivity. Apple also added new status reports that show MDM-specific information for devices, such as if they’re enabled for return to service or shared iPad, and APNS-related information for MDMs to better stay in sync with devices. macOS package uninstall and the Managed App framework Over the past few years, Apple has been adding new features that are shifting traditional agent-based management to the DDM stack. The declarative package (.pkg) configuration introduced last year lets MDM send complex macOS packages and configurations without the constraints of the legacy install command. This year, they rounded out the story by adding package uninstall to remove data and files that were installed by a declarative package configuration as well as extending the Managed App framework to macOS. Just like with the new network configurations, our team is investigating what this means for Intune Mac management and re-evaluating our macOS roadmap. Streamlined log collection with AppleCare Apple introduced a new command to remotely trigger enhanced log collection which seems simple, but it has a lot packed into it. The old way involved lots of downloading and waiting and uploading and more waiting. With this latest announcement, Apple has streamlined this whole process by allowing MDMs to send a command to enable the device for logging with the correct logging state configured. The cherry on top is this new process will tell the device to directly upload its sysdiagnose to AppleCare without requiring physical access to the device or manual interaction from the device owner. It also wouldn’t be a new feature without DDM status, and devices will report their enhanced logging status every step of the way. This will reduce a lot of the friction, idle time, and “what’s actually happening?” that’s associated with getting a sysdiagnose file needed for engineering investigations. This new feature benefits IT teams, AppleCare, MDMs, and everyone in between, and our team is prioritizing this new workflow for the fall. Return to service (RTS) gets better and better Apple has continued to iterate on the return to service workflow since its introduction in 2023. Its first iterations showed how RTS can be useful for troubleshooting, quickly returning devices back to a fresh service state while also preserving apps across resets. This year, Apple announced 2 major improvements: the ability to trigger RTS directly from the device and the ability to configure an inactivity timeout. This makes RTS a must-have for shared device scenarios where you need to securely and quickly minimize downtime between user sessions. MDM software updates are no more DDM is now the only way to manage software updates, with the legacy MDM workload being fully removed from support in OS 27. We will be removing the legacy software update policies and settings from our UI in the coming months. Intune has supported DDM updates since they were first released in 2023, and we also have gold standard software update reports where you can see rich and fast OS update status every step of the way. More information is available on our Tech Community blog. How IT teams can prepare now Identify the Apple device populations that are most business-critical, including supervised iOS and iPadOS devices, shared devices, and managed Macs. Review enrollment, compliance, app deployment, and software update workflows that may be affected by major OS upgrades. Plan a beta validation ring with representative users, devices, apps, and different network conditions. Document known business-critical apps and confirm vendor readiness timelines for the fall OS releases. Test the available beta settings in the settings catalog and share your feedback with our team and Apple via Feedback Assistant. Watch for Intune documentation, Message center posts, and release notes as support details become available. Looking ahead Apple’s fall OS releases are an important planning milestone for every organization managing Apple devices, and Intune’s priority is to help our customers confidently adopt new capabilities securely and at scale. Keep an eye out for our yearly day zero blog to learn more about Intune updates and new feature support as we get closer to the OS 27 release this fall – happy beta testing! If you have any questions, 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.How to Configure macOS Privacy Preferences Policy Control (PPPC) Using the Intune Settings Catalog
By: Chris Kunze - Principal Product Manager | Microsoft Intune Privacy Preferences Policy Control (PPPC) settings on macOS are used to pre-approve privacy permissions for apps so users aren't repeatedly prompted by macOS for access requests. Common examples include Full Disk Access, Screen Recording, Camera, Microphone, Accessibility, Files and Folders, and Apple Events permissions. Organizations commonly deploy PPPC profiles to improve the user experience, reduce support calls, and ensure management and security tools have the permissions they require to function correctly. This is especially important for tools such as Microsoft Defender, remote support applications, compliance agents, and inventory tools. PPPC profiles also help standardize privacy settings across managed Macs and support zero-touch onboarding scenarios where users can begin working without manually approving a series of permission prompts. Intune’s settings catalog provides a straightforward way to deploy PPPC settings, but because macOS uses strict matching criteria, a few configuration details are important to get right. If these settings aren’t configured correctly, apps can either break - or worse, fail quietly. This article walks through the key configuration details that help ensure those settings are applied correctly. How macOS evaluates PPPC entries macOS evaluates PPPC entries using a combination of: App identifier (Bundle ID or Path) Code requirement (from the app’s signature) The specific permission being granted or denied. Apple requires each PPPC payload to use either Authorization or Allowed, but not both. If any of these values don’t align correctly, the policy won’t apply. Configure PPPC in Intune settings catalog Create a settings catalog profile. In the Intune admin center, create a macOS configuration profile using Settings Catalog. Search for: Privacy Preferences Policy Control. This is where you'll configure the PPPC permissions required by your application. Use the Authorization field When configuring, select the Authorization setting instead of the legacy Allowed setting whenever supported, but never both. Get the correct code requirement On a Mac where the application is installed, open Terminal and run: codesign -dr - /Applications/YourApp.app Replace /Applications/YourApp.app with the path to the application you're configuring. The output will contain a string similar to: designated => identifier "com.example.app" and ... Copy everything that appears after “designated =>” exactly as displayed. You'll use this value when configuring the PPPC entry in Intune. Note: Some applications return a multi-line code requirement. If that happens, paste the value into Intune as a single continuous string without line breaks. The content for the Identifier field can also be extracted from this command. Configure the PPPC entry After gathering the required information, configure the application entry. Field Value Identifier type Bundle ID or Path Identifier Application Bundle ID Code requirement Full output from the codesign command in Step 3. Authorization Allow Tip: Use Bundle ID for apps whenever possible. Bundle IDs are more reliable than file paths because they typically remain consistent when an app is updated or moved. Why PPPC settings may not apply If these settings fail, they fail silently. Intune may report the policy as successfully applied, but macOS evaluates PPPC entries when the app requests access to the protected resource. Upon app launch, macOS skips any entry where the code requirement doesn’t match the app’s current binary signature without any indication that the setting is skipped. The three most common causes are: Incorrect code requirement The code requirement must match the application's current signing information exactly. Even a small mismatch can prevent the PPPC setting from being applied. Mixing Authorization and Allowed Apple’s documentation states PPPC entries should use either Authorization or Allowed, not both. Wrong identifier type If the PPPC entry is configured with the wrong identifier type, macOS won't match the application correctly. Try it in your environment If you’ve been avoiding the settings catalog for PPPC, try this approach. Pull the identifier and code requirement directly from the app using codesign, use Authorization when available, and validate the configuration with a pilot group before broader deployment. Most PPPC issues come down to matching. Once you understand how macOS evaluates these settings it becomes much more predictable. If you have any questions, 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.New Platform SSO with registration during Automated Device Enrollment on macOS
By Iris Yuning Ye, Product Manager – Microsoft Intune & Justin Ploegert, Principal Product Manager – Microsoft Entra A new setting ‘Enable Registration During Setup’ for Platform single sign-on (PSSO) during Automated Device Enrollment (ADE) is now generally available for macOS devices in Microsoft Intune. With this new setting and a compatible version of the Intune Company Portal (5.2604.0 and newer), this feature enables users sign in with their Microsoft Entra account during Setup Assistant, complete device registration before reaching the desktop, and get immediate access to work resources and ready to be productive sooner. Why this matters Previously, Platform SSO registration occurred only after users completed Setup Assistant and reached the desktop. They then had to notice and act on a separate notification to finish Platform SSO registration. When Platform SSO registration isn't completed, it can cause issues with app authentication or lead to noncompliance, delaying users from getting started on the device: Missed notifications - Users dismiss or ignore the post-enrollment PSSO prompt, leaving devices in an incomplete device registration state. Broken app authentication - Apps like Microsoft Outlook could fail to authenticate because SSO isn’t fully configured. Compliance gaps - Devices are flagged as noncompliant in the Intune Company Portal because Platform SSO registration isn’t completed. Helpdesk burden - IT teams field repeated tickets for issues that should have been handled automatically during provisioning. Migration blocker - Incomplete Platform SSO setup slows down migrating macOS devices to Intune. Platform SSO during ADE with EnableRegistrationDuringSetup key eliminates these issues. Device registration, identity bootstrap, and credential setup all happen inline during Setup Assistant before the user ever reaches the desktop. What the feature enables Capability Details Microsoft Entra device registration during ADE The device registers with Microsoft Entra ID before the user reaches the desktop. A hardware-bound Workplace Join certificate is issued and stored securely on the device. Early device identity Device identity is established early in the provisioning process, enabling immediate access to apps and resources protected by Conditional Access. Platform SSO credentials during initial setup When configured with Secure Enclave, Platform SSO credentials are stored in the device’s Secure Enclave, providing hardware-bound, phishing-resistant protection aligned with Zero Trust principles. Minimized setup delays Users arrive at the desktop already signed in and ready to work, with fewer authentication prompts, less policy wait time, and fewer setup-related app access issues. How it works This feature requires three policies that work together. All three must be configured correctly before enrollment starts and assigned to the same static user groups: A Platform SSO settings catalog policy with “Enable Registration During Setup” configured to Enabled. Intune Company Portal (version 5.2604 or newer) deployed as a line-of-business (LOB) app, which provides the Microsoft Enterprise SSO extension. An ADE enrollment profile configured with Setup Assistant with modern authentication and Await final configuration = Yes. When a device enrolls with these three policies in place, here's what happens: The device powers on and begins the ADE enrollment flow. Intune delivers the Platform SSO settings catalog policy with Enable Registration During Setup enabled. Intune Company Portal is installed automatically as a LOB app, providing the Microsoft Enterprise SSO plug-in. During Setup Assistant, the user signs in with their Microsoft Entra credentials. This first sign-in starts the regular enrollment process. A second sign-in authenticates the identity in Intune Company Portal and fetches the SSO extension. The device registers with Microsoft Entra ID, and a Microsoft Entra device registration certificate is issued. The user arrives at the desktop fully authenticated, with SSO active and Conditional Access satisfied. Note: During enrollment, users are prompted to enter their Microsoft Entra credentials at least twice. We're working on improvements to reduce the number of sign-ins in a future update. Prerequisites Requirement Details macOS version macOS 26 or later. Enrollment method Automated Device Enrollment (ADE) through Apple Business Manager. Intune Company Portal Version 5.2604.0 or later, deployed as a line-of-business (LOB) app. Download it from Microsoft Download Center . Intune role for configuration An administrator account with, at minimum, the built-in Policy and Profile Manager role. Group type Assigned (static) user groups only. Dynamic groups and device groups are not supported. Important: Review the full Platform SSO prerequisites in the Platform SSO configuration guide before you begin. High level step-by-step configuration Step 1: Create or update the Platform SSO settings catalog policy In the Microsoft Intune admin center, go to Devices > Manage devices > Configuration. If this is your first time configuring Platform SSO, follow the full Platform SSO configuration guide. Add and configure the following setting: Setting Value Description Authentication > Extensible Single Sign On > Platform SSO > Enable Registration During Setup Enabled Enables the Platform SSO registration process during Setup Assistant. If using the Password authentication method, it’s recommended to add for password sync function: Setting Value Description Authentication > Extensible Single Sign On > Platform SSO > Enable Create First User During Setup Enabled Enables the password synchronization experience during Setup Assistant. This configuration is recommended when using the Password authentication method. Tip: Microsoft recommends using Secure Enclave as the authentication method for the strongest hardware-backed security. Assign the policy to your static user groups. Filter is also supported with correct static group setting. Step 2: Install Intune Company Portal as a LOB app Download the Company Portal for macOS PKG from the Microsoft Download Center. In the Intune admin center, go to Apps > All Apps > Create. Add Intune Company Portal as a macOS LOB app. Make it a required app and assign it to the same groups as the Platform SSO policy from Step 1. Important: Company Portal 5.2604.0 and newer is required. If you install an older version, Platform SSO fails. When Intune detects Company Portal as a deployed policy, it sends it with priority during enrollment. And clean up the App bundle ID that are not related to Company Portal, make sure only com.microsoft.CompanyPortalMac as the relevant App bundle ID is kept. Step 3: Set up the enrollment profile In the Intune admin center, go to Devices > Device onboarding > Enrollment > Apple tab. Create or edit an Automated Device Enrollment profile with these Management settings: Setting Value User affinity Enroll with User Affinity Authentication Setup Assistant with modern authentication Await final configuration Yes Locked enrollment Yes Assign the profile to the devices afflicated with the users targeted as Steps 1 and 2. Critical: You must assign all three policies to the devices afflicated with the users targeted. If any policy is assigned to a different group, or if any step is misconfigured, enrollment will fail. In that case, wipe the device and re-enroll with all steps correctly configured. Key things to remember ✅ Three policies, one group: Settings catalog, Company Portal LOB app, and ADE enrollment profile, all assigned to the same static groups or devices/users affliated with the groups. ✅ Static groups only: This feature does not work with device groups or dynamic groups. ✅ One SSO policy per device: If you already have a Platform SSO policy assigned to enrolled devices, make sure device is wiped appropriately before kicking of enrollment with new PSSO flow. ✅ Latest Intune Company Portal: Version 5.2604.0 or newer is required. ✅ macOS 26 required: This feature is supported on macOS 26 and newer. ✅ Secure Enclave recommended: For the strongest hardware-backed credential protection. For more details, refer to Configure Platform Single Sign-On (PSSO) during Automated Device Enrollment for macOS devices. Looking ahead: Reducing Platform SSO sign-in prompts Signing in multiple times during enrollment isn't the ideal experience, and we're actively working to streamline it with a new enrollment setting that enables users to complete both Intune enrollment and Platform SSO device registration with a single sign-in. This will further simplify the onboarding experience, reduce friction for users, and bring macOS enrollment closer to a truly seamless, zero-touch provisioning flow. Stay tuned to What’s new in Intune for the release. Related resources SSO in ADE profile (new article): Add Platform SSO policy to ADE Profile on macOS devices SSO scenarios: Platform SSO scenarios for macOS devices Platform SSO configuration guide for macOS devices using Microsoft Intune Common Platform SSO scenarios for macOS devices Install Company Portal for macOS as a macOS LOB app Set up automated device enrollment (ADE) Troubleshoot the Microsoft Enterprise SSO Extension plugin on Apple devices macOS Platform single sign-on known issues and troubleshooting As always, we'd love your feedback. If you've piloted Platform SSO during Setup Assistant, share your tips and lessons learned in the comments below or reach out to us on X @IntuneSuppTeam. Post Updates: 6/8/26: Refreshed guidance recommending this configuration for the Password authentication method and clearer targeting language around devices and users affiliated with the groups targeted.Intune macOS ADE: support for minimum macOS version enforcement before Platform SSO registration
Hi everyone, I would like to ask whether Microsoft Intune has any supported method, roadmap, or recommended workaround for enforcing a minimum or target macOS version during Automated Device Enrollment before Setup Assistant continues. The scenario is macOS zero-touch deployment with Intune, Automated Device Enrollment, Setup Assistant with modern authentication, Await final configuration, and Platform SSO registration during ADE. Platform SSO registration during Setup Assistant depends on newer macOS capabilities. In addition, some macOS deployment scenarios, such as Platform SSO password sync and macOS LAPS, may require or strongly benefit from a specific macOS version being installed before the user completes enrollment. Today, Intune can manage macOS software updates after enrollment using Declarative Device Management software update policies. However, that does not fully solve the issue where the Mac starts ADE on an older macOS version. In that case, the device may begin Setup Assistant and Platform SSO registration before the required macOS version is installed. What I am looking for is an Intune-native equivalent of enforcing a minimum or target macOS version during ADE, before Setup Assistant continues. Ideally, the macOS ADE enrollment profile in Intune would support options such as: - Minimum required macOS version - Target specific macOS version - Target specific build, if supported - Latest eligible macOS version for the device - Apply the OS update before Platform SSO registration and final configuration - Reporting in Intune showing whether the ADE OS update was required, started, completed, skipped, or failed Without this capability, organizations using Intune-only macOS deployment may still need manual IT staging or macOS restore/update before handing devices to users. This weakens the zero-touch deployment model, especially when adopting Platform SSO registration during Automated Device Enrollment. 1. Is there currently any supported way in Intune to enforce a minimum or target macOS version during ADE before Setup Assistant continues? 2. Is this capability on the Intune roadmap? 3. Are there any recommended workarounds for organizations deploying Platform SSO registration during ADE where a specific macOS version is required? Thanks in advance for any guidance from the Intune team or the community.Apple making device migration to Microsoft Intune easy with upcoming OS 26 release
By: Iris Yuning Ye – Product Manager | Microsoft Intune Apple recently announced a major update at their Worldwide Developers Conference 2025 that solves one of the biggest headaches for admins: migrating macOS and iOS/iPadOS devices from one mobile device management (MDM) solution to another without factory resets, manual re-enrollment, or missing configurations. With the new MDM Migration capability in macOS 26 and iOS/iPadOS 26, built directly into Apple Business Manager, IT admins are able to transition devices from third-party MDMs to Microsoft Intune seamlessly, and without user disruption. Migrating devices to Intune helps IT admins consolidate device management across platforms, enforce consistent security policies, and reduce operational complexity. In this blog, learn how to start using Apple’s MDM migration feature to easily move your macOS and iOS/iPadOS fleet to Intune. Prerequisite: macOS/iOS/iPadOS 26 and enrollment into a device management service is required to use the Apple MDM migration feature. 1. Pre-migration – preparation and set up Before starting the migration process, there are five major steps to follow for preparation. 1.1 Keep a record of your devices Start by creating a detailed inventory of all devices in your organization. This should include each device model, the version of OS it’s running, and whether it’s corporate-owned or user-owned. This step is critical because Apple’s new migration feature has specific OS version requirements. Knowing which devices are eligible helps you scope the migration accurately and avoid surprises later. 1.2 Document configurations in current MDM Before making any changes, document all existing configurations in your current MDM platform. This includes: Configuration profiles: Capture all profiles related to Wi-Fi, VPN, email, and certificates. These are essential for maintaining connectivity and access post-migration. Compliance policies: Note any rules that enforce password complexity, encryption, or device health checks. Security baselines: Record settings such as FileVault encryption, Gatekeeper, and the macOS firewall to ensure security standards are preserved. Custom scripts: List any scripts used for automation, monitoring, or maintenance tasks. Deployed applications: Document all apps currently deployed, including how they’re delivered (Volume Purchase Program, App Store, or custom packages). This documentation will serve as your blueprint for rebuilding these configurations in Intune. 1.3 Configure the Apple MDM push certificate Navigate to the Intune admin center, create and upload an Apple MDM push certificate. This certificate allows Intune to securely communicate with Apple devices. Without it, device management and policy enforcement can’t function. 1.4 Add Microsoft Intune to Apple Business Manager (ABM) or Apple School Manager (ASM) Next, integrate Microsoft Intune with ABM or ASM, by following these steps: Download the public key from Intune. Upload that key to ABM or ASM when creating a new MDM server. Then, download the server token from ABM or ASM and upload it back into Intune. This allows ABM to recognize Intune as a valid MDM server and enables device assignment. 1.5 Set up MDM Configurations in Intune Since migration is treated as a new device enrollment, you'll need to follow standard Intune ADE (Automated Device Enrollment) guidance to setup device enrollment profile. Some key steps include: Once the device is in ABM/ASM, token that must be created to link Intune with ABM. Then, the device needs to sync from ABM to Intune. There is an automatic sync every 12 hours, or admin can manually sync once every 15 min. After successfully synced device from ABM to Intune, you need to create the enrollment profile, and then manually assign it to the devices via device serial number, and then the device can power on and enroll through that assigned enrollment profile Using the configurations documented in step 1.2, begin replicating existing configurations in Intune. This includes but is not limited to: Rebuilding configuration profiles for network access and security. Reapplying compliance and security policies. Re-deploying applications. Rewriting or importing scripts as needed. Identify the other controls to implement that improves Zero Trust. Call to action: Please make sure testing the MDM configurations on a test device before assigning them to the devices you plan on migrating. And before initiating any migration, communicate with your endpoint users first, keeping them informed to avoid any confusion. 2. Migration – Admin step-by-step flow The admin experience starts from ABM or ASM. After logging into ABM or ASM, navigate to the Devices section. Select the device or group of devices targeted for migration to Intune. Selecting the ellipsis on the top right of device overview interface unveils the “Assign Device Management” button. Select the server you want to migrate the device to. In our case, it’s Intune. Confirm device assignment. 3. Migration – Endpoint step-by-step flow After completing the device management assignment, the device user receives a notification informing them that a management change is required. macOS iOS/iPadOS When the user selects the notification, they are guided through a simple approval process. If the user doesn’t initiate enrollment before the admin set enrollment deadline, an enforced migration occurs, which results in a non-dismissible and full-screen prompt that must be completed by the user before using the device. Regular migration Enforced migration (past deadline) Once the user approves the migration, the device communicates with Apple’s servers to get its new device management assignment. It then downloads and installs the new MDM profile. This migration process happens without rebooting the device. 4. Post-migration – Verification Lastly, verify the migration and enrollment successfully completed by navigating to the Intune admin center and confirming the new devices are listed. evice. Please note, it's important to have test device verifying required configurations running smoothly before migrating large number of devices and test your devices after migration to ensure everything is working smoothly. If you run into any issues, further adjustments may be needed. Special thanks to our Intune MVP, Somesh Pathak, whose content we leveraged in this blog! For more details and a video demo, check out Somesh’s blog at: https://intuneirl.com/mac-admins-your-migration-glow-up-just-dropped Summary In short, Apple’s new MDM migration in macOS and iOS/iPadOS 26 makes moving Mac, iPhone or iPad devices to Intune now easier than ever. With careful planning and a few simple steps, you can make the switch smoothly to manage your Apple devices all in one place. For Mac devices that aren’t running OS 26, you can check out our Intune Github for migration scripts and review the blog Managing and migrating Macs with Microsoft Intune. Let us know how your Mac journey is going by leaving a comment below, reaching out to us on X @IntuneSuppTeam, or join our Mac Admins Community on LinkedIn! Post updates: 12/04/25: Updated section "1.5 Set up MDM Configurations in Intune". 12/11/25: Updated MDM Migration URL.
