Establish a macOS security baseline with mSCP and Microsoft Intune custom compliance
By: Iris Yuning Ye, Product Manager | Microsoft Intune Organizations that manage Mac devices need a reliable way to evaluate their security posture against a recognized baseline. Microsoft Intune custom compliance provides the device compliance evaluation policy, and the National Institute of Standards and Technology’s (NIST) macOS Security Compliance Project (mSCP) provides macOS security rules and checks mapped to compliance requirements. Earlier this year we released Intune custom compliance for macOS devices. The feature uses a discovery script and JSON file to define compliance settings. With the mSCP command-line tool, you can select and tailor a security baseline, generate a macOS discovery script, and pair the discovered identifiers with an Intune rules JSON file. Intune then evaluates each device against the chosen baseline and uses the result in compliance reporting and Conditional Access decisions. In this blog, we’re introducing a JSON conversion script (mscp_to_intune_json_conversion.sh). The script converts the mSCP’s generated vendor manifest into the JSON format required for Intune custom compliance. Prerequisite Before you begin, set up the mSCP locally by following the NIST guidance: Getting started with the macOS Security Compliance Project. Create a security baseline Next, we’ll establish and configure the security baseline on the device. Select your security baseline: Choose a security baseline your organization intends to evaluate devices against by looking through frameworks supported by mSCP (for the example in this blog we’ll use CIS Level 1) Configure your baseline: When creating the baseline for the first time, you'll follow a guided process to specify the name of the custom baseline, your name and organization, choose what specific rules to include or exclude. Once the customization process is completed, a new baseline file containing all the rules you specified is generated under the custom/baselines/ directory as a YAML file. ./mscp.py baseline –k cis_lvl1 –t Note: The command uses the following flags: -k Specifies the keyword. In this example, we're using cis_lvl1 . -t Enables tailoring, allowing you to select specific rules to include and define organization-specific values. Once the baseline YAML file is generated, run the command below to generate mSCP documents. These files will be saved into a build/[your specified project name] directory. ./mscp.py guidance –s –M [yaml file location] The yaml file location should be the relative location on top of your mSCP folder. Note: The command uses the following flags: -s Generates the compliance script. -M Generates the JSON vendor manifest file. Once the JSON Vendor Manifest and compliance script are successfully generated, we highly recommend running a test check to verify that all rules and values are defined as expected. Note: If you're using the container method, exit the container to proceed to run the check. (Exit container: NIST macOS Security Getting Started) The key is to locate where you build folder is and where the .sh file was saved in: sudo ./[base folder]/cis_lvl1_macos_27.0/cis_lvl1_macos_27.0_compliance.sh --check Create mobileconfig file Create a mobileconfig file by creating a plain text file, then copy and paste the example in GitHub into it. Configure the .mobileconfig profile Update the PayloadType key to match the audit file name. This ensures the compliance script uses the correct managed arguments when running. Example: In our demo, the value is updated to: org.intune_compliance_lv1_macOS_26.0.audit Customize the following keys based on your organization's requirements and preferences: PayloadDescription PayloadOrganization PayloadDisplayName Test the .mobileconfig profile To verify the configuration, install the .mobileconfig profile locally on a test MacOS device. Open System Settings > General > Device Management. Select the + button to add a configuration profile. Navigate to the saved .mobileconfig file, select it, and click Open. Follow the prompts to Continue and Install the profile. Note: Administrator privileges are required to install the device profile. Validating the Results: Once the profile is installed, run the generated compliance script. If the script runs successfully and outputs JSON, the managed arguments are correctly set. Run the generated compliance script with no arguments specified to make sure it uses the managed arguments from the installed mobileconfig file. sudo ./[base folder]/cis_lvl1_macos_27.0/cis_lvl1_macos_27.0_compliance.sh Once testing is complete, remove the test profile for your local Mac. It’s critical to ensure all testing profiles are removed from target devices before deploying from Intune to avoid conflicts. You can deploy the custom mobileconfig profile for the managed arguments using Intune to the desired set of macOS devices. Important: Deploy the .mobileconfig file to target devices before deploying the custom compliance policy. Otherwise, the custom compliance policy may not run correctly. Use JSON conversion script Next, use the mscp_to_intune_json_conversion.sh script from GitHub to convert the mSCP JSON Vendor Manifest file into the specific JSON format required for Intune’s custom compliance policy. The command line is comprised of three parts: Locate where you saved the conversion script. Specify the JSON file from security baseline you intend to convert from. Specify the name of the custom compliance JSON file you intend to convert to. ~/ mscp_to_intune_json_conversion.sh [base folder]/cis_lvl1_macos_27.0/cis_lvl1_macos_27.0_compliance.json > intune_custom_compliance.json You can now upload the compliance script built by the mSCP that can be found in the build directory as your Discovery Script within Intune’s custom compliance policy. You can also upload the converted JSON file as the JSON for custom settings. Devices with the mobileconfig profile installed will run the compliance script using the managed arguments and output the JSON required for the custom discovery script. Keep in mind Start with a small pilot group and a focused baseline of your choice. Validate every identifier, returned data type, and expected value before broad deployment. Deploy mobileconfig file and make sure the file is already successfully deployed on target devices before custom compliance policy. Review the per-setting results in the Intune admin center > Reports > Device compliance -> Noncompliant devices and settings. Make sure the JSON file generated is aligned with other discovery scripts’ output to avoid misalignment errors. The recommended first step is to pilot one baseline on a small Mac device group, document the source version and rule mapping, and expand only after the discovery script output and Intune results have been validated. Conclusion The steps and scripts provided simplifies the flow to connect the mSCP with Intune’s custom compliance feature. By leveraging mSCP, organizations can efficiently translate recognized macOS security guidance into actionable, measurable compliance signals. While Intune provides the mechanism to capture identifiers and current device values, the rules JSON define the precise evaluation criteria. Together, these tools create a transparent, automated path from a high-level security baseline to detailed, device-level compliance reporting. A special thank you to Robert Gendler from NIST for authoring the mscp_to_intune_json_conversion.sh script and collaborating on this project. Disclaimer Collaboration on this post does not imply NIST endorsement of the products or services offered by Microsoft. Any mention of specific tools or software is for informational purposes and does not constitute a recommendation by NIST.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.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.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.
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.
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.
