Hello, I have an Apple Developer Enterprise account, and Apple Support has already enabled MDM for my account. I successfully downloaded and installed my MDM Vendor Certificate (it shows up in Keychain as MDM Vendor: [My Company Name] with its private key). Here’s what I’ve done so far: Exported the Vendor Certificate + private key as a .p12, then converted to .pem and .key using OpenSSL. Generated an unsigned CSR with CN=com.apple.mgmt.External. using OpenSSL. Attempted to sign the CSR using: my Vendor certificate the Vendor private key Apple Worldwide Developer Relations (WWDR) intermediate certificate OpenSSL smime -sign command with DER output Problem: Every time I try to upload the vendor-signed CSR to the Apple Push Certificates Portal, I get an error (CSR rejected). Sometimes OpenSSL even fails with “unable to load certificates” depending on how the WWDR certificate is included. My Questions: What is the correct OpenSSL command and certificate chain Apple expects for signing the CSR? Do I need to include any additional intermediates besides WWDR? Is there an official Apple reference example for generating the vendor-signed CSR that the Push Certificates Portal will accept? Any guidance from the community (or someone who has successfully done this end-to-end) would be greatly appreciated. Thank you, Sergio Sanchez

Hello, We are working with an iOS app that is distributed as a Public Unlisted App Store app. Our MDM allows us to import the app by URL, but when added this way, the app is marked as unmanaged in the inventory. Because of that, we cannot assign a Managed App Configuration payload to it in the normal way. What we are trying to achieve: Deliver a configuration profile to all enrolled devices before the app is installed. When the user installs the app from the MDM catalog, the app should immediately see the configuration values. Questions we’re hoping to clarify: Is it technically feasible to pre-provision a Managed App Configuration for an app in this scenario, by pushing a .mobileconfig profile to all devices? If yes, what would be the correct payload format and content of such a .mobileconfig file? We’ve tested a profile format we found here that uses com.apple.managed-app-config PayloadType and a ManagedAppConfiguration key with the bundle ID nested inside, but iOS reports this as “payload not recognized.” From what we understand, that may not be part of Apple’s schema. Any guidance from Apple or the community on whether this use case is possible (and, if so, what the valid profile format should look like) would be very helpful. Note: For a complicated company policy, at the moment we are not able to participate in ABM. Thanks in advance!

Environment Devices: e.g., iPhone 12 mini, iPhone 16 (multiple units) OS: iOS 26 beta 2 and beta 4 (23A5297m) Distribution: Apple Enterprise Program (In-House), deployed via MDM InstallApplication Tooling: Xcode (latest available for iOS 26 betas) Summary Apps signed for Enterprise (In-House) distribution install successfully on iOS 26 betas via MDM, but terminate immediately on launch. The same builds run if installed from Xcode on the same devices. This is a regression from pre-iOS 26 versions where Enterprise builds installed via MDM launched normally. Steps to Reproduce Archive an iOS app and export for Enterprise (In-House) distribution. Deploy the .ipa via MDM using InstallApplication to a device on iOS 26 beta (e.g., 23A5297m). Tap the app icon to launch. Actual Result The app quits instantly on launch. System logs show launchd/runningboard errors, including NSPOSIXErrorDomain Code=85 (“Bad executable (or shared library)”): runningboardd(RunningBoard)[34]: Process start failed with Error Domain=NSPOSIXErrorDomain Code=85 "Bad executable (or shared library)" UserInfo={NSLocalizedDescription=Launchd job spawn failed} runningboardd(RunningBoard)[34]: Launch failed with Error Domain=NSPOSIXErrorDomain Code=85 "Bad executable (or shared library)" SpringBoard(FrontBoard)[35]: Bootstrapping failed ... NSUnderlyingError = { NSLocalizedDescription = Launchd job spawn failed; } Expected Result Enterprise-signed builds installed via MDM should launch as they did on iOS 25.x and earlier. Regression? Works on iOS versions prior to 26. Works on iOS 26 betas when installed from Xcode (developer-signed run). Fails only for Enterprise (In-House) builds delivered via MDM. Additional Notes / Possibly Related We also reproduced a similar failure mode with a minimal Safari Web Extension project: it installs and appears under Settings → Safari → Extensions, but enabling it and opening Safari produces: “ is no longer available.” Building a fresh project with a new bundle ID shows the same behavior on iOS 26 beta (23A5297m). Logs contain: Error occurred during transaction: The provided identifier "" is invalid. Running from Xcode (debug build) works. Workarounds None identified for Enterprise/MDM distribution. Only Xcode-installed builds run. Impact Blocks Enterprise deployment to our fleet on iOS 26 betas. Feedback / Attachments Included: sysdiagnose from an affected device, minimal Xcode project demonstrating the issue, Enterprise-exported app, and reproduction notes. Happy to share additional logs or perform targeted tests if needed. Request Can Apple confirm whether this is a known regression vs. a policy/validation change in iOS 26 for Enterprise/MDM installs? Any guidance on a short-term mitigation or build/signing change we can apply would be appreciated.

Nuestra cuenta está aprobada como MDM Vendor y necesitamos emitir por primera vez el certificado APNs para MDM en el portal de Push Certificates. Procedimiento seguido Primero hemos descargado desde nuestra cuenta de Apple Developer el certificado de MDM Vendor y lo hemos instalado en el ordenador. Esto lo hemos hecho para que, al lanzar la instrucción de OpenSSL, se pueda utilizar el UUID gestionado por Apple y así generar el CSR de forma correcta. La instrucción que estamos ejecutando es la siguiente: openssl req -new -newkey rsa:2048 -nodes -keyout mdm_private.key -out mdm.csr -subj "/O=Numbux/OU=MDM/CN=com.apple.mgmt.External." El CSR resultante es puro (no está firmado ni empaquetado) y está generado con RSA 2048 y SHA256. Sin embargo, al subirlo al portal de Push Certificates, seguimos recibiendo el error “invalid signing request”. Solicitud Dado que es nuestra primera emisión, entendemos que necesitamos el External UUID asignado por Apple a nuestra organización, porque veo que el problema se deriva de una incorrecto UUID que se está generando en el comando OpenSSL. ¿Podríais confirmarnos cuál es ese valor para poder completar el CSR y así emitir correctamente el certificado APNs MDM? He llamado a los números 900 812 703 y al 900 812 468 y he escrito al soporte de developer. NADIE ES CAPAZ DE DARMELO. Sin el external UUID no puedo crear el APN para mi MDM. Alguien me puede ayudar? No me mandeis links ni posibles números que llamar porque ya lo he hecho.

We've disabled FUS through a config profile, but users can still access FUS by enabling the MenuBar/Control Center icons. My org would like to prevent access to FUS so I've created a config profile. But the profile doesn't seem to work. Anyone have any ideas what I'm missing, or is this an OS bug? <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadDisplayName</key> <string>macOS - Tahoe - Disable Fast User Switching Control Center</string> <key>PayloadIdentifier</key> <string>com.myorg.fast-user-switching</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadScope</key> <string>System</string> <key>PayloadUUID</key> <string>f1a2b3c4-d5e6-7890-abcd-ef1234567890</string> <key>PayloadVersion</key> <integer>1</integer> <key>TargetDevmyorgType</key> <integer>5</integer> <key>PayloadContent</key> <array> <dict> <key>PayloadType</key> <string>com.apple.controlcenter</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadIdentifier</key> <string>com.apple.controlcenter.57EBEF9E-E568-411E-AE27-500AD98C94F4</string> <key>PayloadUUID</key> <string>f1a2b3c4-d5e6-7890-abcd-ef1234567890</string> <key>UserSwitcher</key> <integer>8</integer> </dict> <dict> <key>PayloadType</key> <string>.GlobalPreferences</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadIdentifier</key> <string>.GlobalPreferences.71DE1486-60BC-4CB9-890D-AD50A772890D</string> <key>PayloadUUID</key> <string>c5234012-e0sw-2066-6fl8-3bd5p8125op7</string> <key>MultipleSessionEnabled</key> false/> </dict> </array> </dict> </plist>

Hello, this may not be the correct place to ask this question so I apologize in advance if this is the case. I am currently running into two specifc issues while continuing to implement the app.managed configuration which are quite frustrating and I will detail them below Unlike MDM where an application could be "reinstalled", by sending an install application command down for the same app DM does not have a similar mechanism which causes some issues as (while inconsistent) devices do not always respect the configuration sent down, and will not begin downloading VPP applications. They can be seen in the configuration when checking under VPN & Device Management but they do not return on a status report, alternatively and app will "install" but will have a cloud symbol next to it requiring a download (which I believe would be impossible on supervised devices without apple accounts/have restricted apple accounts associated to them). These apps are also reported incorrectly, as they return a managed response while being inaccessible. Both of these issues are solved by removing and reinstall applications (occasionally). Is there any easier way to trigger a re-install or is this the only way to trigger this? The Version element that can be optionally sent down does not seem to work (or if it does, does so inconsistently). A device will very happily download the application initially with the version element present, though when we detect an updated external ID from the VPP program and send down an updated configuration devices behave unexpectedly. Some have ignored it, some have responded back that a download has begun (with no download taking place and the application clearly still being the initial installed version as can be see in the apps page) or it just works, but there is not consistency. I realize a new UpdateBehavior object has been added to possibly handle this, but it is only supported in iOS 26 and above and there are plenty of people who do not have phones that can upgrade that far. Are there alternative ways to enforce an application update other than uninstalling and reinstalling the application without the version (or will sending down a config without a version after one was originally pinned force it to update to latest?) Kind Regards

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.

Hello, I’m facing an issue while trying to add iOS devices to Apple Business Manager (ABM) using Apple Configurator during enrollment. When going through the setup process, the device fails to complete enrollment and times out. I’ve tried it multiple times. The device does appear in ABM during the process and I am able to assign it to different MDM servers but since the setup times out and fails, the device is automatically released. I have tried this with multiple iOS devices and it times out on every single one of them. Steps attempted: Factory reset and re-enrollment of the device Ensured network connectivity is stable and tested on multiple Wi-Fi networks Tried the following process using Apple Configurator on Mac (wired): Created a Wi-Fi profile in Configurator Connected the iPhone via cable and used Prepare (manual configuration) Used the “MDM server” placeholder and trusted anchors (as recommended) Linked the device to the ABM organization Skipped Setup Assistant steps Attached the Wi-Fi profile, then prepared and wiped the device Verified that the device should appear in ABM Attempted to assign the device to my MDM in ABM Despite these checks, the enrollment process times out. I’m attaching a screenshot of the error for reference. Could someone advise what might be causing this timeout or how I can further troubleshoot this? Any guidance would be greatly appreciated. Thanks in advance.

Issue Description: We are experiencing MDM profile installation failures specifically on iPhone 17 devices. After extensive testing and comparison between affected and working devices, we suspect this appears to be a parameter transmission error rather than device settings. Technical Analysis: Device Settings Comparison: No differences found between problematic and working devices in system settings, indicating this is not a configuration issue. Suspected Parameter Transmission Error: • Device model information appears to be restricted or blocked during profile download • User ID and phone number parameters are not being transmitted to the server • Installation logs show missing login ID and phone number entries Symptoms: • During MDM profile installation, the "Apps & Restrictions" section that should appear is missing • Profile download parameters are suspected to not be properly transmitted to the server • Installation process fails at the profile configuration stage Critical Finding: When we cloned a previously working device to create a problematic device configuration, the cloned device also began experiencing the same installation failures. This strongly suggests the issue is related to device-specific parameters or identifiers. Additional Information: We continue to receive reports of this issue from our iPhone 17 users, and these reports are occurring across various iOS versions. Request for Assistance: Has anyone encountered similar MDM profile installation issues on iPhone 17? Are there known limitations or changes in how device parameters are transmitted during MDM enrollment on this model? Any guidance on debugging parameter transmission or known workarounds would be greatly appreciated.