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.Support tip: Move to declarative device management for Apple software updates
By: Benjamin Flamm – Product Manager | Microsoft Intune Apple recently announced at the Worldwide Developer Conference (WWDC) in June 2025 that mobile device management (MDM) software updates are deprecated in the upcoming Apple OS 26 versions. Instead, software updates will need to use declarative device management (DDM). In this blog, we want to provide you with everything you need to know to navigate this transition and easily manage software updates in DDM. What is DDM? DDM is an enhancement to Apple’s device management protocol that makes devices more proactive and autonomous, and this is perfectly highlighted by the major improvements that DDM brings to managing software updates. Previously, Intune had to send update commands and repeatedly check for the update status. With DDM, Intune simply tells the device the required OS version and the installation deadline, while the device proactively updates Intune on its progress from download to installation. Move to DDM for software updates The MDM software update features in Intune will initially be marked as ‘deprecated’ in the Intune admin center and support will end shortly after Apple OS 26 releases. Devices will ignore MDM update settings when DDM update settings are being enforced, so the only steps you need to do are to create your DDM update policies using the settings catalog. The following table lists the MDM software update features that’ll be unsupported later this year, along with the matching DDM feature that is currently available or coming soon. Legacy MDM feature New DDM feature iOS/iPadOS update policies Software Update or Software Update Enforce Latest settings, located in the settings catalog under Declarative Device Management (DDM): macOS update policies iOS update installation failures report Apple software update failures (Devices > Monitor) which is expected to release with Intune’s August (2508) service release. macOS update installation failures report Software updates report (macOS per-device) macOS software updates (Devices > All devices, select a macOS device > macOS software updates) which is expected to release with Intune’s August (2508) service release. macOS Settings catalog > Software Update payload and settings Software Update Settings located in the settings catalog under Declarative Device Management (DDM): Settings in the iOS or macOS ‘Device restrictions’ template Settings catalog > Restrictions, software update delay settings How do I manage software updates using Intune? With Apple deprecating MDM software updates, DDM is the recommended method to manage software updates in your organization. For a thorough guide that highlights the differences between MDM and DDM, along with how to configure DDM software updates review: Managed software updates with the settings catalog. Useful resources Apple announcements: Announcement of DDM software updates at WWDC 2023 Introduction of Software Update Settings at WWDC 2024 Announcement of MDM update deprecation at WWDC 2025 Intune Apple settings catalog configuration list | Microsoft Learn Apple Platform Deployment guide for managing updates | Apple Support Stay tuned to this post for updates! If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune. Updates: 7/25/2025: Updated the expected release timeline of the new per-device software update report for macOS.Microsoft Intune and Apple OS 27: New settings, support, and platform changes
With Apple's release of OS 27, we’ve been working hard to ensure that Microsoft Intune provides support for Apple’s latest operating systems (OS) so that existing features work as expected, and adding support for new features that were introduced at WWDC. We’ll continue to upgrade our service and release new capabilities that integrate elements of the new OS versions. New DDM configurations and settings With continued investments in the Intune data-driven infrastructure that powers the settings catalog, we’re able to provide day zero support for new OS settings as they’re released by Apple. We’ve updated the settings catalog to support newly released iOS/iPadOS and macOS settings for both declarative device management (DDM) and mobile device management (MDM) to empower your IT teams to have devices ready for the latest OS release. Configurations that have been updated include: App settings (DDM) Control which apps can launch on supervised iPhone, iPad, Apple TV, and Apple Vision Pro devices and which binaries can run on supervised Macs using allow and deny rules. Define organization-suggested privacy permission defaults for apps - including camera, microphone, Bluetooth, location, local network, dictation, and accessibility - to present users with a single consolidated consent prompt. Intelligence settings (DDM) Control Apple Intelligence capabilities, including Visual Intelligence, Writing Tools, Genmoji, Image Playground, app-specific features in Mail, Notes, and Safari, and requirements for on-device dictation and translation. Accessibility settings (DDM) Configure organization-defined accessibility preferences - such as display, text, motion, audio, and interaction options - so supported settings can be applied consistently on managed devices. Safari settings (DDM) Manage Safari behavior and privacy, including cookies, fraud warnings, history clearing, JavaScript, pop-ups, private browsing, summaries, new-tab start pages, and website camera or microphone permission defaults. Siri settings (DDM) Control Siri availability and behavior, including Siri AI features, user-generated content, access while the device is locked, profanity filtering, and reduction of sensitive content. Content caching (DDM) Configure the macOS Content Caching service to store Apple-distributed software and iCloud content locally, define the clients and networks it serves, and optimize parent, peer, storage, and network behavior to reduce internet bandwidth use. DNS Proxy (DDM) Configure a DNS proxy network extension to handle device DNS traffic, including the provider app and its vendor-defined settings, so name-resolution requests can be routed through an organization-approved service. Web content filter (DDM) Configure a plug-in-based web content filter to inspect and control network traffic using an approved filtering app, with provider, authentication, and filtering settings appropriate to the organization. Login window (MDM) Customize the macOS login window and sign-in experience, including the information shown to users and the login options and controls available on managed Macs. Located under the Login Window category. More information on configuring these new settings using the settings catalog is available at create a policy using settings catalog in Microsoft Intune. New keys to skip Setup Assistant panes We recently added our new enrollment policies experience based on data-driven infrastructure that powers the settings catalog. This enables Intune to quickly and easily add new Skip Keys such as Liquid Glass and Accessibility Appearance. A list of Setup Assistant panes that can be managed is available in our Setup Assistant screen reference. Streamline AppleCare cases with enhanced logging support Microsoft Intune now supports Apple's Enhanced Logging device action on supported supervised devices running a compatible OS release. Administrators can start an AppleCare diagnostic-log collection session using an AppleCare-provided token and monitor device-reported status through DDM, reducing the need to coordinate manual log collection with the device user. More information is available in our device actions documentation for Enhanced logging. Support updates for legacy MDM workloads As more workloads are shifting to DDM, Apple is ending support for the following legacy MDM commands and payloads, which means they’ll no longer be updated or supported. You should instead manage these workloads using DDM through the settings catalog, which contains the latest settings. MDM payloads that are now deprecated with OS 27 include: Content caching service DNS settings DNS proxy Parental controls application restrictions Privacy preferences policy control Passcode Multiple settings have been deprecated in the MDM Restrictions payload, and we recommend using the equivalent DDM configuration to manage these features. The table below provides the new DDM location for these deprecated settings. DDM Configuration Deprecated MDM Settings App Settings Allow Listed App Bundle IDs Blocked App Bundle IDs External Intelligence Settings Allowed External Intelligence Workspace IDs Allow External Intelligence Integrations Allow External Intelligence Integrations Sign In Intelligence Settings Allow Apple Intelligence Report Allow Genmoji Allow Image Playground Allow Image Wand Allow Personalized Handwriting Results Allow Visual Intelligence Summary Allow Writing Tools Force On Device Only Dictation Force On Device Only Translation Allow Mail Smart Replies Allow Mail Summary Allow Notes Transcription Allow Notes Transcription Summary Allow Safari Summary Keyboard Settings Allow Auto Correction Allow Continuous Path Keyboard Allow Definition Lookup Allow Dictation Allow Keyboard Shortcuts Allow Predictive Keyboard Allow Spell Check Siri Settings Allow Assistant Allow Assistant User Generated Content Allow Assistant While Lock Force Assistant Profanity Filter Apple previously ended support for MDM device configuration templates, and software update commands and settings. These have been removed from OS 27, and you should use DDM for these instead. To align with this change, starting with the October (2610) release, Intune will remove the following legacy workloads from the Microsoft Intune admin center: iOS/iPadOS update policies macOS update policies macOS software updates report (per-device) iOS update installation failures macOS update installation failures More information on this change is available in the support tip: Move to declarative device management for Apple software updates. Support statement for “supported” versus “allowed” versions for user-less Apple devices As new operating system updates are released throughout the year by Apple, Intune plans to support critical functionality that comes with each new OS version. With the release of iOS/iPadOS and macOS 26, we’ll continue with our existing model for enrolling user-less devices for supported and allowed OS versions to keep enrolled devices secure and efficient. This includes devices enrolling without user affinity (user-less devices), such as shared iPads and devices enrolling through Automated Device Enrollment (ADE) without user affinity. We highly recommend updating your organization’s devices to the most recent Apple OS version publicly available to keep your devices secure and up to date. Supported OS versions means that user-less devices running the three most recent iOS/iPadOS versions are fully supported by Intune. Devices running iOS/iPadOS 26.x, 18.x, and 17.x can enroll and take advantage of all Intune MDM functionality that is applicable to user-less devices, and all new eligible features will work on these devices. Allowed OS versions let you enroll user-less devices running an unsupported iOS/iPadOS version within the three versions of the supported range. These devices can use eligible Intune features supported by the MDM protocol, but OS changes, bugs, or other issues might affect functionality. Devices enrolled with user affinity or apps that rely on user sign-in will continue to not be supported. User-less enrollment and feature support Capability Supported Allowed Applicable Versions Three most recent versions (N-2): iOS/iPadOS 18.x and later macOS 15.x and later Up to three versions below the supported version (N-5): iOS/iPadOS 16.x and later macOS 13.x and later Can Enroll Yes Yes User-less Eligible Intune MDM Features Yes Yes. May be impacted by breaking OS features, bugs, or issues. User Affinity Enrollment Yes No Apps That Require User Sign-In Yes No For more details, review our blog Support statement for supported versus allowed versions for user-less Apple devices to learn more. Intune MAM controls and updates As you plan for the new features and changes with the latest OS release, we wanted to highlight additions with the latest Intune App SDK. With Intune App SDK for iOS v21.8.0 or later, organizations can take advantage of the following Intune MAM updates. Apps must be integrated with SDK v21.8.0 or later to support the experiences described below. As always, we recommend keeping apps updated with the latest SDK. Refreshed app protection user experience We’ve modernized the Intune app protection experience on iOS to make policy interactions clearer and more intuitive. The refreshed experience includes updated prompts and full-screen messaging, clearer account context on conditional launch screens such as the MAM PIN screen, and a Remove Account option that lets users remove a blocked managed account and its organizational data from the app. This is a user experience update only, with no changes to app functionality or app protection policies. Control Siri onscreen awareness for organizational data The Screen capture app protection policy setting now controls whether Siri onscreen awareness can access work or school data. Set Screen capture to Block to prevent the Ask Siri option from appearing in the context menu for organizational data. If the setting remains Allow, which is the default value, users can share organizational data through Siri onscreen awareness. The updates require apps to use the Intune App SDK for iOS version 21.8.0 or later. Bookmark the Microsoft Intune Blog and follow us on LinkedIn or @MSIntune and @IntuneSuppTeam on X to continue the conversation. Stay tuned to What’s new in Intune for additional settings and capabilities that will soon be available.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.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.
Purview endpoint DLP cant block file upload to web.whatsapp on open in app mode chrome browser MacOS
we are using purview endpoint DLP to block file upload to web.whatsapp.com on browser for MacOS. its working fine on chrome browser when i try dirrectly upload file contain ssn pattern and its blocked by purview but if we upload using open in app mode (pwa) purview cant detect that activity and file is uploaded to web whatsapp susscessfully. try to upload senstive file to web.whatsapp.com from chrome browser and its blocked. but when i try to use "open in app" mode (pwa) dlp purview cant detect the sensitive upload to web.whatsapp.com how to detect and block file uploaded to unwanted url if user using pwa especially on chrome browser? try the same scenario on edge, purview able to detect pwa and can intercept the activity but why in chrome its not the same behaviour expected.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.
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.
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.
