Hi Community, The Leverage macOS has with Bootstrap token is immense using the same for Software Updates, Erase Device and new Local Account Creation in System Settings While I refer From IT Deployment Guide Which States the below For a Mac with macOS 10.15.4 or later, when a secure token-enabled user logs in for the first time, macOS generates a bootstrap token and escrows it to a device management service. I even tested out the Statement using Automated Device Enrollment Workflow ( With AutoAdmin Account Only, With Both AutoAdmin Account , Primary Account ) and it Granted BootStrap Token Immediately upon login How ever with User-Initiated Enrollments it differs like below Sometimes upon installation of MDM Profile in macOS Immediately the BootstrapToken is sent to MDM Sometimes the BootStrapToken is not immediately sent, so I need to logout , login with the Secure Token enabled user for macOS to escrow BootStrapToken to MDM Sometimes Even when I followed the pointer as in 2) like logout / login from a SecureToken Enabled user the BootStrapToken is not escrowed to MDM , Which Affects the OSUpdates, Erasing Capabilities to be used precisely with MDM Protocol Can someone Please Help with the Flow for BootStrapToken Generation / issuance to MDM incase for User-Initiated Enrollment

We are experiencing an issue with ADCertificate auto-renewal on macOS devices enrolled via MDM. Platform: macOS CA: Microsoft AD CS Payload Type: com.apple.ADCertificate.managed Initial certificate enrollment works correctly EnableAutoRenewal is set to true Certificate does not renew automatically as it approaches expiry We would like to confirm: Are there any known issues with macOS ADCertificate managed payload auto-renewal, particularly with Microsoft AD CS environments? Below is the exact payload configuration in use: Thank you.

We are currently working on a SCEP server implementation that operates in FIPS-approved mode. In this mode, RSA PKCS#1 v1.5 encryption is disallowed due to compliance requirements, and only FIPS-approved padding schemes such as RSA-OAEP are permitted. However, we have observed that the SCEP client functionality on Apple devices currently does not support RSA-OAEP for CMS EnvelopedData decryption. This creates a challenge for us in ensuring FIPS compliance while maintaining compatibility with Apple devices during certificate enrollment through SCEP. We would appreciate your guidance on the following: Are there any alternative FIPS-approved encryption algorithms or configurations supported by Apple devices for SCEP CMS EnvelopedData decryption? Is there any plan or timeline for future support of RSA-OAEP on Apple platforms for this use case? Feedback raised along with sysdiagnose logs as well : FB17655410

Issue Description: Apps that support both iOS and tvOS can have different versions in App Store for each type(iOS and tvOS) but same Bundle Identifier and iTunesStoreID/trackID. For example, the iOS version of YouTube has the latest version in App Store as 17.30.3 the tvOS version of YouTube has the latest version in App Store as 2.07.01 This can be verified from two by two specific iTunes look Up API as shown below https://itunes.apple.com/lookup?id=544007664 https://itunes.apple.com/lookup?id=544007664&entity=tvSoftware Sample contentMetadataLookup URL: https://uclient-api.itunes.apple.com/WebObjects/MZStorePlatform.woa/wa/lookup?version=2&id=544007664&p=mdm-lockup&caller=MDM&platform=enterprisestore&cc=us&l=en Queries: What should we do to get the tvOS specific version of an app in contentMetadataLookup URL? The trackViewURL doesn't show tvOS specific version history of the app - https://apps.apple.com/us/app/youtube-watch-listen-stream/id544007664?platform=appleTV . How should we view this the apps' tvOS specific version history? Kindly help us with the queries.

We are experiencing an issue with Apple Business Manager (ABM) synchronization that is blocking our device management workflow. Issue Description: During the ABM sync process in our MDM, we receive the error: "ABM Terms and Conditions not signed." What We’ve Checked: Logged into the ABM portal as the Administrator and confirmed that the latest Terms and Conditions. Attempted to renew the ABM token on our existing server, but the same error message continues to appear in MDM. Tried creating a brand new ABM server integration, which also fails with the same error. We checked with our MDM provider and they shared the logs, response received from ABM. It says T_C_NOT_SIGNED. But we have already accepted all the new Terms in ABM. We would appreciate any help in resolving this issue or guidance on what steps to take next.

On a supervised device running iOS 18 without any AirDrop restrictions applied, when a profile with allowListedAppBundleIDs restriction key is installed, the AirDrop sound plays. But still the accept prompt does not appear, making it impossible to accept files. The prompt works as expected on iOS 18 devices to which the allowListedAppBundleIDs restriction is not installed. This issue occurs only on supervised iOS 18 devices to which the allowListedAppBundleIDs restriction is being applied. Device must be in iOS 18 version > Install the (allowListedAppBundleIDs restriction) profile with the device > Try to AirDrop files to the managed device. The expected result is that the accept prompt must pop up but it does not appear. This issue is occurring irrespective of any Whitelisted bundle ID being added to the allowListedAppBundleIDs restriction profile. Have attached a few Whitelisted bundle ID here com.talentlms.talentlms.ios.beta, com.maxaccel.safetrack, com.manageengine.mdm.iosagent, com.apple.weather, com.apple.mobilenotes, gov.dot.phmsa.erg2, com.apple.calculator, com.manageengine.mdm.iosagent, com.apple.webapp, com.apple.CoreCDPUI.localSecretPrompt etc. Have raised a Feedback request (FB15709399) with sysdiagnose logs and a short video on the issue.

Hi Apple Community, At WWDC25, introduced a native device migration feature with iOS/macOS 26 and Apple Business Manager that promises seamless migration from one MDM to another without wiping devices or manual re-enrollment. That said, while testing this in iOS/macOS 26 beta, we ran into an issue: the Wi-Fi settings deployed by the old MDM aren’t retained during the migration. This means devices lose Wi-Fi connectivity partway through, and users have to manually reconnect before the migration to the new MDM can continue. This interrupts what should be a smooth, hands-off process. We wanted to ask if this is a known issue or limitation with the current beta? Are there any recommended ways to avoid losing Wi-Fi profiles during this migration window? Will this improve in future updates so that the Wi-Fi connection is preserved or seamlessly handed off to the new MDM? Any tips, workarounds, or official guidance Apple can share on best practices for handling Wi-Fi profiles during ABM-native device migrations would be hugely appreciated. Added Feedback with FeedBackAssistant ID : FB20150763 Thanks in advance.

When I try to sign in Managed Apple ID in supervised device there appears a prompt stating that "Apple ID" is a work account.This account must be signed in as a work account on this device.When I click continue it takes to VPN and device management tab where MDM profile already exists. Note:The managed Apple ID has a ICloud subscription for it. When I remove the subscription for the Apple ID and try to sign in, it works. Kindly help on this or advise on any additional steps required to enable sign in for managed Apple ID in this scenario

Hi Apple team and community, We’re currently integrating with the Apps and Books for Organizations API as part of our device management solution and would like to highlight a few critical points we've encountered — including a reliability issue, an enhancement suggestion, and a request for clarification on API rate limits. 1. Issue: Intermittent 403 Errors with stoken-authenticated-apps Endpoint We are encountering intermittent 403 Forbidden responses from the stoken-authenticated-apps endpoint. Approximately 30–35% of the requests fail with a 403 status code. These failures are inconsistent — the same request (using the same Content Token and Storefront) may succeed upon retry. All requests are properly authenticated and include the required Cookie and other headers as specified in the API documentation. This issue is impacting our ability to reliably fetch app metadata at scale, particularly in workflows. We’d like to know: Is this a known issue? Could it be due to a rate limit or token misconfiguration? Are any changes required on our end to avoid these failures? 2. Enhancement Request: Include externalVersionId in versionHistory Response The versionHistory extension currently returns: versionString releaseNotes releaseDate However, for Declarative Device Management (DDM) workflows such as App Pinning, we need the externalVersionId as well. Without it, we can't reliably correlate version metadata with the specific version ID required for pinning. Adding externalVersionId would: Enable precise version targeting during App Pinning Improve reliability and automation in managed deployments We request that Apple consider including externalVersionId in the versionHistory response to better support DDM-based app lifecycle management. 3. Rate Limit Clarification We found the following note in the Apps and Books for Organizations API documentation: "The Apps and Books for Organizations API limits the number of requests your app can make using a developer token within a specific period of time. If you exceed this limit, you’ll temporarily receive 429 Too Many Requests error responses for requests that use the token. This error resolves itself shortly after the request rate has reduced." While this confirms that a rate limit is enforced, there is no detailed information about the thresholds — such as the number of allowed requests per minute, hour, or day per developer token. To help us implement proper throttling and retry strategies, we request clarification on the following: What is the exact rate limit threshold per developer token? Are there per-endpoint limits, or is it a global cap for all requests using the token? Does the API return a Retry-After header when the limit is exceeded? What is the recommended backoff strategy for clients to follow when receiving 429 errors? This information would help us implement efficient throttling and error handling logic. Any insights from the Apple team or other developers who’ve encountered these issues would be greatly appreciated!

Hi Apple Team & Community, The new Introduction of Platform SSO during ADE Enrollment is Great And we tried implementing this. As a Rule mentioned in the Documentation Initially MDM Server should send 403 response with Response Body adhering to ErrorCodePlatformSSORequired when HTTP Header for MachineInfo request contains MDM_CAN_REQUEST_PSSO_CONFIG and set to true There are contradictory claims mentioned in Document, In Process Platform SSO Required Response it is mentioned that MDM Server should send body as JSON Object for ErrorCodePlatformSSORequired Example below >>>>> Response HTTP/1.1 403 Forbidden Content-Type: application/json Content-Length: 558 { "code": "com.apple.psso.required", "description": "MDM Server requires the user to authenticate with Identity Provider - BY MEMDM", "message": "The MDM server requires you to authenticate with your Identity Provider. Please follow the instructions provided by your organization to complete the authentication process - BY MEMDM", "details": { "Package": { "ManifestURL": "https://platform-sso-node-server.vercel.app:443/manifest" }, "ProfileURL": "https://platform-sso-node-server.vercel.app:443/profile", "AuthURL": "https://platform-sso-node-server.vercel.app:443/auth" } } But in the same Document a Sample HTTP Response was Provided but seems to be XML format as below >>>>> Response HTTP/1.1 403 Forbidden Content-Type: application/xml Content-Length: 601 <?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>Code</key> <string>com.apple.psso.required</string> <key>Details</key> <dict> <key>ProfileURL</key> <string>https://mdmserver.example.com/psso.mobileconfig</string> <key>Package</key> <dict> <key>ManifestURL</key> <string>https://mdmserver.example.com/psso-app.plist</string> </dict> <key>AuthURL</key> <string>https://idp.example.com/authenticate</string> </dict> </dict> </plist> From Github I assume that both Response Types are welcomed hence I tried with Both Followed in JSON Mode, I redirected the HTTP request if MachineInfo contains MDM_CAN_REQUEST_PSSO_CONFIG and set to true to https://platform-sso-node-server.vercel.app/redirectedDEPJSON Followed in XML Mode, I redirected the HTTP request if MachineInfo contains MDM_CAN_REQUEST_PSSO_CONFIG and set to true to https://platform-sso-node-server.vercel.app/redirectedDEPXML In both Response Modes OS is not proceeding after and a error Stating Enrollment with Management Server Failed , Forbidden request (403) appears Can someone kindly guide on where I missed, or is this any OS Bug in Tahoe 26?

Apple iPad Air device failing to enroll through ABM with "failed to retrieve configuration" error. This error occurs while reaching Apple ABM for fetching MDM server enrollment details. When we checked console logs when enrolling the device we found following error: ​default 13:54:07.229022+1000 teslad Error: Error Domain=MCCloudConfigurationErrorDomain Code=34004 "The cloud configuration server is unavailable or busy." UserInfo={NSLocalizedDescription=The cloud configuration server is unavailable or busy., CloudConfigurationErrorType=CloudConfigurationFatalError} default 13:54:07.229120+1000 Setup Service completed default 13:54:07.230096+1000 Setup Could not retrieve cloud configuration. Error: <Error domain: MCCloudConfigErrorDomain, code 33001>\ Feedback raised along with screenshot and console logs as well : FB17785513. Please analyse this issue and reply back to us.

During MDM Automated Device Enrollment of Apple TV, the web view defined by configuration_web_url is not working. We are using the web view to display the usage policy for all devices. While the web view functions correctly for other devices, it is resulting in an error specifically for Apple TV. Could you please clarify whether Apple plans to implement support for this feature on Apple TV in the future or if it will not be supported? Referring to configuration_web_url in: https://developer.apple.com/documentation/devicemanagement/profile

I am using system_profiler command to check on the installed application list from mac device. **Terminal command to check installed java version - ** But while running /usr/sbin/system_profiler SPApplicationsDataType -xml , I cant able to find Java as an installed application. Is this a known issue or do we have any alternative workaround to fetch the same?

Issue - Safari application not fetched from system_profile command Use case - We are trying to get list of installed applications in the mac. For this we use System_profiler command to fetch the details list. It is working good, but the thing is , It doesnt fetch Safari app as an installed Application. Command used - **/usr/sbin/system_profiler SPApplicationsDataType** Can anyone suggest any other way to fetch the installed applications list from the mac , which includes all the apps (including safari app) and remains effective ?

Managed iOS/iPad devices are struck with no network under below conditions Enrolling a Supervised iOS device Send InstallProfile command with AppLock payload (https://developer.apple.com/documentation/devicemanagement/applock) Now when the above managed device loses network connection with MDM server due to unknown network issues - the device is out of contact with MDM server and device is locked. Since such AppLock payload installed devices are placed in remote locations, it becomes difficult for Admins to recover such devices with no network connectivity. The devices have to be brought in from remote location and recover them. Under such conditions, it would be better to allow the end user to change the Network configuration manually to reconnect the device with MDM server. This option can also be allowed only when the device can’t ping MDM server.