Since the release of macOS 14.0, we have encountered issues with the Content Filtering MDM Payload. This problem is unusual but can be resolved by restarting the system. Prerequisites: macOS 14 or higher Any Mac with a Silicon (ARM) processor Restrictions Payload and Parental Content Filtering Payload must be installed on the device, either manually or through any MDM service Issue Details: When the Parental Content Filtering Payload is removed after installation, it causes internet issues, and browsers display "The site can't be reached". This affects applications as well, with Safari being the only application that continues to work. The issue can be resolved by either re-adding the Content Filtering Payload or restarting the Mac. Links: Restriction Payload: https://drive.google.com/file/d/1buwLFgbjTRXij9ZSv1QrDeRnWbFfKNtq/view?usp=drive_link Content Filtering Payload: https://drive.google.com/file/d/1eAJiBg4N__dML65MRDH7hYCocuTqOCcu/view?usp=drive_link System Logs: https://drive.google.com/drive/folders/1hKKNAoMn_4x1CqMTxz1bPrUucCbftjO9?usp=drive_link Screen Recording: https://drive.google.com/file/d/1uS8CJqe9p9DG9XzhUnIsY35eme4Dxs60/view?usp=drive_link

We noticed that Apple Login fails if we try to login with Managed Apple ID on iOS 17.2 & 17.3 This issue could have been introduced in iOS 17 but we did not have iOS 17.0 or 17.1 to validate this. There are few prerequisites to this: Should be a supervised device. It can be enrolled in ABM or ASM. Apple ID should be Managed Apple ID Device should have a passcode policy Device should have “allowListedAppBundleIDs” added in the “com.apple.applicationaccess” payload If either of the above conditions are not met, then the issue does not happen. If the device is set up in the above way and we try to login with Managed Apple ID, then the login fails. Please refer the recording at this link: https://drive.google.com/file/d/1XG17loAuH_GB1IyGdwD8txjkHZWqGeD1/view?usp=drive_link We reproduced the issue three times and got the log files: Issue occurred at: 21st March 2024 at 19:54:58 IST a. Log file name: sysdiagnose_2024.03.21_19-55-26+0530_iPhone-OS_iPhone_21D50(07.54.58 pm).tar.gz b. Link: https://drive.google.com/file/d/1nk-cQPrVEZrAUgVmrxPCsSRDd4aNF8eK/view?usp=drive_link Issue occurred at: 21st March 2024 at 19:59:44 IST a. Log file name: sysdiagnose_2024.03.21_20-00-02+0530_iPhone-OS_iPhone_21D50(07.59.44 pm).tar.gz b. Link: https://drive.google.com/file/d/1VPcF77G2SK2c1rBK4S2GbLCAiQEeYPOB/view?usp=drive_link Issue occurred at: 21st March 2024 at 20:03:27 IST a. Log file name: sysdiagnose_2024.03.21_20-03-39+0530_iPhone-OS_iPhone_21D50(08.03.27 pm).tar.gz b. Link: https://drive.google.com/file/d/1zlLLMd0ugJoiZtmpWlarREFDl1vjZoWP/view?usp=drive_link During the above tests, this was the setup Passcode Policy: a. requireAlphanumeric: true b. minLength: 13 c. allowSimple: false allowListedAppBundleIDs: This can be anything but atleast one of them should be enabled. For example a. com.apple.AppStore b. com.apple.MobileAddressBook c. com.apple.calculator d. com.apple.camera e. com.apple.DocumentsApp f. com.apple.facetime What results I expected: The user should be able to login without an issue What results I actually saw: The user does not login We also created a ticket in Feedback assistant in March but haven't received any response: FB13694721

When a package is published via MDM using the Install Enterprise app command provided by Apple On one of the devices, this command is failing with com.apple.appstored.xpc exception but works fine on other macOS devices having the same restrictions and OS version. We tried restarting the device and also the appstored process via Activity Monitor but it was in vain. I am attaching system logs that contain the exception and stack trace when the command failed. ExceptionLogs

We are configuring a passcode policy through MDM where the password expiration is set to 2 months for local accounts (not domain joined). Occasionally, we receive prompts to change the password a few days before it expires. Please refer to the image below. We would like to clarify the following: What is the default timing for these reminders? Specifically, how many days before the password expiration do these prompts typically start appearing? Can we adjust the number of days before these reminders appear? If yes, can this adjustment be made through MDM settings or via a script?

Hi, I'm exploring ways to control wide range of peripherals such as Keyboard, Mouse, Monitor, Router etc form connecting to mac device. I was able to easily achieve the external storage mount and unmount but having trouble understanding on how can I control which peripheral is allowed to connect to mac. Can you help me understand what events and processes in ES can be used to control them? Is ES app the correct approach for this or something else like IOKit framework?

In MDM Software Update settings(https://developer.apple.com/documentation/devicemanagement/softwareupdate), there is a key "restrict-software-update-require-admin-to-install" which apparently controls if the standard users are allowed to install apps and software updates. But so far, even if this is set to true, a standard user is able to download apps from Appstore. We noticed that when we publish a pkg to be installed via MDM, then that does not get installed if the above setting is set to true. Please provide clarity on what this setting controls.

My application supports Custom URL Schema which is used to perform an open operation. My application is used as a helper app for MDM, hence it will be installed as a Managed Application. I want only the other Managed Applications to be able to invoke the Custom URL Schema and not allow it for unmanaged applications. Is there any such provision provided by Apple MDM protocol?

We have noticed that if we apply forceDelayedSoftwareUpdates in Restrictions profile, it causes ScheduleOSUpdates to fail or go into an invalid state. For example: On my iOS device, we have set the forceDelayedSoftwareUpdates to 90 days which removed the latest iOS update iOS 18.2 from the Software Updates section on the device. Post this, if I schedule an update for iOS 18.2 using ScheduleOSUpdateCommand, it fails to download. If I schedule the same without forceDelayedSoftwareUpdates, the update works as expected. Please help what could be the reason for this behavior as forceDelayedSoftwareUpdates should not block ScheduleOSUpdates.

We’ve run into what looks like a gap in how forceAirDropUnmanaged is enforced on iOS devices. Setup: Device: iOS 17.x (unsupervised, enrolled in MDM) MDM Restriction: forceAirDropUnmanaged = true Managed Open-In restriction also applied (block unmanaged destinations). Verified: from a managed app, the AirDrop icon is hidden in the share sheet. This part works as expected. Issue: When two iOS devices are brought close together, the proximity-initiated AirDrop / NameDrop flow still allows transfer of photos, videos, or files between devices. In this path, forceAirDropUnmanaged does not appear to apply, even though the same restriction works correctly in the standard sharing pane. What I’d expect: If forceAirDropUnmanaged is enabled, all AirDrop transfer paths (including proximity/NameDrop) should be treated as unmanaged, and thus blocked when “Managed Open-In to unmanaged destinations” is restricted. What I observe instead: Share sheet → AirDrop hidden ✅ Proximity/NameDrop → transfer still possible ❌ Questions for Apple / Community: Is this a known limitation or expected behavior? Is there a different restriction key (or combination) that also covers proximity-based AirDrop? If not currently supported, should this be filed as Feedback (FB) to request alignment between share sheet AirDrop and NameDrop enforcement? This behaviour introduces a compliance gap for organisations relying on MDM to control data exfiltration on unsupervised or user-enrolled devices. Any clarification or guidance would be greatly appreciated.

We’re running into a problem when deploying certain .pkg installers via MDM on macOS 15 and above. The installation fails with the following error message: “The app is running and we don’t have the context to quit it, failing install.” Context: The .pkg is being pushed through an MDM solution (not installed manually). This happens consistently across multiple macOS 15+ devices. The target app is often already running when the MDM tries to install the update. Unlike a manual installation, the MDM does not appear to have the ability to quit the running app before proceeding. Questions: Is this a known change in macOS 15 where MDM-delivered installs no longer have permission to terminate apps during package installation? Are there recommended best practices for handling app updates via .pkg through MDM in this scenario? Has anyone implemented a workaround—such as pre-install scripts, user notifications, or policies to quit the app before running the installer—that works reliably on macOS 15? Is Apple planning to update MDM behavior or installer APIs to address this, or should admins expect to handle quitting apps entirely outside of the MDM installation process? Any insights from Apple engineers or other developers/admins who have encountered this would be really helpful.

We are implementing the Return to Service (RTS) with App Preservation flow. During testing, we were able to successfully fetch the Bootstrap Token as part of the ADE enrollment process. However, when attempting to initiate the Return to Service command with App Preservation enabled, the following error was returned: [ { "ErrorCode": 12089, "ErrorDomain": "MDMErrorDomain", "LocalizedDescription": "Could not erase device.", "USEnglishDescription": "Could not erase device." }, { "ErrorCode": 66002, "ErrorDomain": "MDMBootstrapTokenErrorDomain", "LocalizedDescription": "Failed to generate LAContext for bootstrap token", "USEnglishDescription": "Failed to generate LAContext for bootstrap token" } ] Below is the sample request (with dummy data). The actual request contained valid values in all fields: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Command</key> <dict> <key>RequestType</key> <string>EraseDevice</string> <key>ReturnToService</key> <dict> <key>Enabled</key> <true /> <key>WiFiProfileData</key> <data>WiFiProfileData</data> <key>BootstrapToken</key> <data>BootstrapTokenValue</data> <key>MDMProfileData</key> <data>MDM Profile Data</data> </dict> </dict> <key>CommandUUID</key> <string>3670</string> </dict> </plist>