Hi Team, Request your help with the below queries. Regarding target-local-date-time status item https://github.com/apple/device-management/blob/release/declarative/status/softwareupdate.pending-version.yaml#L59. The value reported is not the same sent to the device, looks like it is being converted into UTC and sent. Please confirm if this value sent here will be in UTC always, the github link mentions it will be local date time value and does not mention that i will be in UTC. In the softwareupdate.enforcement.specific schema it is clearly mentioned we should not use any timezone. Please find below a sample payload sent to the device and the status report from the device. Device time zone is IST ("Asia/Kolkata") Target local date time is property for iOS is not matching the schema. The property is "softwareupdate.target-local-date-time" instead of "target-local-date-time". Payload: {{"Identifier":"v1|CONFIGURATION|OS_UPDATE|26.5|8ba807e8-6a75-4c50-a379-b7363c4c82fc","ServerToken":"vH|86iQ8CT5QdgErs5ZNQXpUAX4YntAr5kMxkeRNHcXDKg=","Type":"com.apple.configuration.softwareupdate.enforcement.specific","Payload":{"TargetOSVersion":"26.5","TargetLocalDateTime":"2026-06-30T10:00:00"}} Status Report from device: "StatusItems" : { "softwareupdate" : { "install-state" : "downloading", "pending-version" : { "build-version" : "23F77", "os-version" : "26.5", "softwareupdate.target-local-date-time" : "2026-06-30 04:30:00 +0000" } } }, "Errors" : [ ] } For MacOS TimeZone value is not included in DeviceInformation command, even when the request Queries contains <string>TimeZone</string>. Please find below part of the request sent to the device. The device was on OS version 26.0, which is supported as per documentation. <plist Version="1.0"> <dict> <key>CommandUUID</key> <string>4a79dd95-e4bb-450b-96cc-82f61ae4c89e</string> <key>Command</key> <dict> <key>RequestType</key> <string>DeviceInformation</string> <key>Queries</key> <array> <string>DeviceName</string> <string>OSVersion</string> ... <string>TimeZone</string> .. </array> </dict> </dict> </plist>

Requesting com.apple.managed-keychain Entitlement for Enterprise S/MIME Cert Visibility Platform: iOS | Distribution: MDM (Microsoft Intune) | Not App Store We are developing an internal enterprise iOS app (EMS Assist, com.company.supportcompanion) for Company deployed exclusively to Intune-managed devices. Our requirement: Read S/MIME certificates pushed to the device via Intune SCEP profiles to: Confirm cert presence in the MDM-managed keychain Read expiry date (kSecAttrNotValidAfter) to warn users before expiry Distinguish between missing, expired, and valid cert states What we have tried: Standard SecItemCopyMatching query — returns only app-installed certs, not MDM-pushed certs Graph API (deviceConfigurationStates) — confirms profile compliance but does not expose actual cert expiry or keychain presence Our understanding: com.apple.managed-keychain is required for an app to access MDM-managed keychain items on supervised devices, combined with a matching keychain-access-groups entitlement and the cert profile configured as "always available" in MDM. Questions: Is com.apple.managed-keychain the correct entitlement for this use case? Does it apply to SCEP/PKCS-issued certificates specifically, or only other MDM keychain items? Has anyone successfully accessed Intune-pushed S/MIME certs from an iOS app using this entitlement? Any guidance from the community or Apple engineers would be appreciated.

Hello, I’m trying to clarify whether the new Age Range / Age Assurance Setup Assistant pane can be skipped on macOS when using a standard MDM Device Enrollment flow, not Automated Device Enrollment. Environment: Platform: macOS Tahoe 26.5.1 Enrollment type: MDM Device Enrollment, not ADE / DEP MDM: Microsoft Intune Profile deployment channel: Device profile Payload type: com.apple.SetupAssistant.managed Key used: SkipSetupItems Skip items tested: AgeAssurance AgeBasedSafetySettings The configuration profile installs successfully on the Mac as a device profile. I can confirm that the com.apple.SetupAssistant.managed payload is present on the device and includes the tested SkipSetupItems values. However, the Age Range / age-related Setup Assistant pane is still shown to the user. Example payload content: <dict> <key>PayloadType</key> <string>com.apple.SetupAssistant.managed</string> <key>PayloadIdentifier</key> <string>com.example.setupassistant.managed</string> <key>PayloadUUID</key> <string>REDACTED-UUID</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadDisplayName</key> <string>Managed Setup Assistant</string> <key>SkipSetupItems</key> <array> <string>AgeAssurance</string> <string>AgeBasedSafetySettings</string> </array> </dict> What I expected: When the com.apple.SetupAssistant.managed payload is installed as a device-level profile and includes the relevant age-related skip keys, the Age Range / Age Assurance pane should be skipped during Setup Assistant, or Apple documentation should state clearly that this pane can only be skipped in ADE. What actually happens: The profile installs, but the Age Range / age-related Setup Assistant pane still appears to the user on macOS 26.5.1. Documentation ambiguity: Apple’s Setup Assistant payload documentation says: The supported payload identifier is com.apple.SetupAssistant.managed Supported operating systems/channels include macOS device and macOS user Supported enrollment methods include User Enrollment, Device Enrollment, and Automated Device Enrollment SkipSetupItems is a list of Setup Assistant panes that can be skipped Apple’s macOS Tahoe 26 enterprise notes say: “The new Age Range setup pane is automatically skipped for devices using Automated Device Enrollment.” That wording clearly mentions ADE, but I have not found documentation that explicitly states whether the Age Range pane is intentionally unsupported for non-ADE macOS MDM enrollment, or whether there is a separate skip key required for macOS. Third-party MDM/tooling documentation appears to reference the following newer skip keys: AgeAssurance AgeBasedSafetySettings However, it is unclear whether those keys are supported on macOS, iOS/iPadOS only, ADE only, or all MDM enrollment methods. Questions: Are AgeAssurance and AgeBasedSafetySettings valid SkipSetupItems values on macOS 26.5.1? If yes, are they supported only during Automated Device Enrollment, or should they also work with standard MDM Device Enrollment? If these keys are iOS/iPadOS-only, what is the correct macOS skip item for the Age Range / age-related Setup Assistant pane? Is the Age Range pane intentionally only auto-skipped in ADE on macOS? Should Apple’s public Device Management / SkipKeys documentation be updated to list the correct key names, supported platforms, minimum OS versions, and enrollment requirements? This is important for Mac deployments where devices are enrolled into MDM but are not assigned through Apple Business Manager / Automated Device Enrollment. At the moment, it is difficult to determine whether the behavior is expected, unsupported, or a bug in macOS / Setup Assistant / MDM profile handling. Thanks.

Hello I am looking at taking advantage of managing some features via DDM in an app. I noticed in the ServicesConfigurationFiles link (https://developer.apple.com/documentation/devicemanagement/servicesconfigurationfiles) it says You can create an executable that uses service configuration files by calling the mcf_service_path_for_service_type method in the libmanagedconfigurationfiles.dylib system library. You pass in an identifier for your service type and the method returns the file system path for the directory that contains the corresponding service configuration files. Use those files to override the standard or default configuration the executable would otherwise use. See libmanagedconfigurationfiles.h in the macOS SDK for more detail. I can't find any more references or information on mcf_service_path_for_service_type, libmanagedconfigurationfiles.dylib or libmanagedconfigurationfiles.h anywhere. Is there any information somewhere about this? Or how to use it? Or a POC small example?

I am interested in managing some configuration files for an app using Declarative Device Management (DDM) and noticed a blurb on the ServicesConfigurationFiles developer page that makes it seem like 3rd party apps can take advantage of DDM service files. But I'm not exactly sure how https://developer.apple.com/documentation/devicemanagement/servicesconfigurationfiles You can create an executable that uses service configuration files by calling the mcf_service_path_for_service_type method in the libmanagedconfigurationfiles.dylib system library. You pass in an identifier for your service type and the method returns the file system path for the directory that contains the corresponding service configuration files. Use those files to override the standard or default configuration the executable would otherwise use. See libmanagedconfigurationfiles.h in the macOS SDK for more detail I can't find any more details in the developer documentation on this. How would this be used? Could someone give an example or small POC?

Is system_profiler the recommended approach for retrieving installed application data on macOS? If not, what is the preferred and reliable alternative to fetch a consistent and complete list of installed applications?

Hi, We're implementing a DDM-capable MDM server. A DEP-enrolled, supervised iPad (iOS 26.4.2) successfully completes manifest synchronization but never proceeds to fetch the individual declaration bodies. Looking for guidance on what we might be missing. Observed flow (from our server logs): We enqueue a DeclarativeManagement MDM command and APNs-wake the device. The command body is: RequestTypeDeclarativeManagement (no Data field) Device acknowledges the command on the Connect endpoint (Status=Acknowledged). Device calls CheckIn with: MessageType = DeclarativeManagement Endpoint = tokens We respond 200 with: { "SyncTokens": { "DeclarationsToken": "", "Timestamp": "2026-05-19T..." } } Device calls CheckIn with: MessageType = DeclarativeManagement Endpoint = declaration-items We respond 200 with: { "Declarations": { "Activations": [{"Identifier":"...","ServerToken":"v1-..."}], "Configurations": [{"Identifier":"...","ServerToken":"v1-..."}], "Assets": [], "Management": [] }, "DeclarationsToken": "" } ---- Nothing further. ---- No request for Endpoint = declaration/activation/ No request for Endpoint = declaration/configuration/ No status report on Endpoint = status The MDM channel is healthy. The same device responds normally to non-DDM commands (DeviceInformation, etc.) immediately before and after this flow. Questions: Is an empty "Management" array acceptable in the declaration-items response, or is at least one declaration (e.g. com.apple.management. organization-info) required before the device will proceed to fetch declaration bodies? The DeclarationsToken returned in step 3 (tokens) and step 4 (declaration-items) are byte-identical. Is that correct, or should they differ in some way? Are there any additional preconditions for the device to begin fetching declaration bodies after receiving the manifest -- e.g. a specific Activation->Configuration linkage we might be missing? Is there a server-side log signal Apple can suggest we look for, or a way to see why the device decided not to fetch? Activation payload sample we publish: { "Type": "com.apple.activation.simple", "Identifier": "...", "ServerToken": "v1-...", "Payload": { "StandardConfigurations": ["<configuration-identifier-from-step-4>"] } } Configuration payload sample we publish: { "Type": "com.apple.configuration.softwareupdate.settings", "Identifier": "...", "ServerToken": "v1-...", "Payload": { ... softwareupdate settings ... } } Any pointers appreciated. Happy to share full server-side logs / payloads if useful. Thanks.

Our organization is attempting to retrieve the External Version Identifier (EVID) history for all published versions. This data is required so that we can pass the exact externalVersionIdentifier integer to our deployment framework to pin specific app versions on our managed devices. We currently have an active App Store Connect account, but our attempts to fetch this data via standard publishing APIs return a 401 Unauthorized error. To help us resolve this technical blocker, please provide explicit engineering guidance on the following four points: API Endpoint Architecture: Is the enterprise Apps and Books for Organizations API (apple.com) the only platform that exposes the externalVersionId history for all versions? If so, what is the exact endpoint path we must call to return the full version-based EVID array? Account Requirements: Can these version-specific EVIDs be retrieved using our existing App Store Connect developer credentials, or is an Apple Business Manager (ABM) account strictly mandatory to bypass the 401 gate? ABM Portal Setup for EVIDs Only: If an ABM account is mandatory, what are the minimum technical steps required inside the ABM dashboard to fetch only the EVID data? Specifically, do we need to "purchase" a volume license for the target app to make its version history accessible via the API? Authentication Parameters: What is the correct token structure for this endpoint? Do we need to pass a specific location server token (sToken / itvt cookie) generated inside ABM alongside our signed developer JWT header? Thank you for your time and technical guidance. We look forward to your engineering team's response.

Buongiorno, In azienda abbiamo molti iPhone gestiti su ABM integrati con Intune, adesso il passaggio su nuovi dispositivi con ripristino dei dati non è possibile avvicinandoli perché la funzione “inizia subito“ non appare. Qualcuno conosce un sistema rapido per la migrazione dei dati da un iPhone a un altro che non sia il Finder? Grazie per l’aiuto

forum-post-v2-evidence.log MCRestrictionsPayload (allowListedAppBundleIDs) breaks Apple Watch app enumeration — nanotimekitcompaniond reports "Missing .app from directory: /Watch/" Summary Installing a Configuration Profile with com.apple.applicationaccess payload containing allowListedAppBundleIDs causes native Apple Watch apps to disappear from the paired Watch — even when their bundle IDs are explicitly in the whitelist. Log analysis shows this is not a bundle ID matching problem: nanotimekitcompaniond on the iPhone fails to enumerate the <companion>.app/Watch/ subdirectories where native watchOS app stubs live. Follow-up to https://developer.apple.com/forums/thread/745585 — community-confirmed but received no official response. Environment iPhone 16 (iPhone17,3), iOS 26.4.2 (23E261), supervised Apple Watch paired via Bridge.app Profile installed locally via Apple Configurator (no MDM server required) Smoking gun Within ~5 seconds of profile install, two processes (nanotimekitcompaniond and NTKFaceSnapshotService) log identical errors for eight companion-app paths: nanotimekitcompaniond[1498] <Error>: Missing .app from directory: file:///Applications/MobilePhone.app/Watch/ nanotimekitcompaniond[1498] <Error>: Missing .app from directory: .../Calculator.app/Watch/ nanotimekitcompaniond[1498] <Error>: Missing .app from directory: .../Bridge.app/Watch/ nanotimekitcompaniond[1498] <Error>: Missing .app from directory: .../MobileTimer.app/Watch/ nanotimekitcompaniond[1498] <Error>: Missing .app from directory: .../Camera.app/Watch/ nanotimekitcompaniond[1498] <Error>: Missing .app from directory: .../VoiceMemos.app/Watch/ nanotimekitcompaniond[1498] <Error>: Missing .app from directory: .../MobileMail.app/Watch/ nanotimekitcompaniond[1498] <Error>: Missing .app from directory: .../FindMy.app/Watch/ NTKFaceSnapshotService[3758] <Error>: Missing .app from directory: <same 8 paths> The Watch's app icons and face complications both go through these processes, which explains the symptoms users see. iOS itself flags the payload as Watch-incompatible — but applies it anyway profiled[179] <Notice>: Payload class MCRestrictionsPayload (com.apple.applicationaccess) is not supported on any Watch version profiled[179] <Notice>: Payload class MCRestrictionsPayload (com.apple.applicationaccess) is not available on HomePod profiled[179] <Notice>: Beginning profile installation... profiled[179] <Notice>: Profile "...v2..." installed. So profiled knows the payload doesn't target watchOS — yet its side effects clearly manifest there. Tests performed Test Bundle IDs in whitelist Result v1 249 (every installed iOS app: Apple + 3rd party) Walkie-Talkie, Messages, Find My + more disappear from Watch v2 295 (v1 + every Apple extension/Nano* daemon seen in syslog: *.MessagesActionExtension, *.FindMyNotifications*Extension, *.FindMyWidget*, com.apple.NanoBackup, com.apple.NanoMusicSync, com.apple.NanoPreferencesSync, com.apple.NanoTimeKit.face, com.apple.NanoUniverse.AegirProxyApp, com.apple.tursd, com.apple.FaceTime.FTConversationService, com.apple.Bridge.GreenfieldThumbnailExtension, etc.) Identical Missing-.app errors. Same apps disappear. Conclusion: this is not a bundle ID matching issue — adding more IDs doesn't help. The system fails to enumerate <companion-iOS-app>.app/Watch/ regardless of whitelist contents. Many users in my prior thread reported trying 100+ bundle ID combinations without success; this evidence explains why. Reproduction (no MDM required) Pair Apple Watch with iPhone normally. Generate a Configuration Profile with com.apple.applicationaccess + any non-empty allowListedAppBundleIDs array. Install via Apple Configurator's cfgutil install-profile, or AirDrop + Settings → Install. Within ~5 s, nanotimekitcompaniond errors appear (visible via idevicesyslog). Native Watch apps backed by an iOS companion stub disappear from the Watch's app grid and from face complications. Hypothesis MCRestrictionsPayload applies an enumeration filter that does not descend into .app/Watch/ subdirectories when computing visible apps. nanotimekitcompaniond consequently sees those directories as missing, the Watch's Carousel (SpringBoard equivalent) hides the apps, and NTKFaceSnapshotService can't load corresponding complications. Because profiled itself logs the payload as "not supported on any Watch version", this appears to be unintended bleed-through. Questions for Apple Is MCRestrictionsPayload / allowListedAppBundleIDs officially supposed to affect Apple Watch apps? profiled says no. Is there an undocumented bundle ID pattern (e.g. <companion>.watchapp, or a Bridge.app/Watch/ prefix) that needs whitelisting to keep native Watch apps visible? Is the recommended workaround to use blacklistedAppBundleIDs instead? Should the enumeration error (Missing .app from directory: .../Watch/) be tracked as a separate watchOS framework bug? Artifacts Curated evidence log with timestamps, profile installer events, and the eight Missing-.app errors is attached as forum-post-v2-evidence.log. Full idevicesyslog captures (multiple install/remove cycles, ~2M log lines) and the .mobileconfig files are available on request. Thanks — looking forward to guidance.

Summary: When applying a configuration profile that uses allowListedAppBundleIDs to permit a defined set of apps, essential Apple Watch apps are unexpectedly removed from the paired Watch — even though their associated iPhone bundle IDs are explicitly included. This issue occurs with a minimal profile, and has been consistently reproducible on the latest versions of iOS and watchOS. Impact: This behavior severely limits the use of Apple Watch in managed environments (e.g., education, family management, accessibility contexts), where allowlisting is a key control mechanism. It also suggests either: Undocumented internal dependencies between iOS and watchOS apps, or A possible regression in how allowlists interact with Watch integration. Steps to Reproduce: Create a configuration profile with a Restrictions payload containing only the allowListedAppBundleIDs key. Allow a broad list of essential system apps, including all known Apple Watch-related bundle IDs: com.apple.NanoAlarm com.apple.NanoNowPlaying com.apple.NanoOxygenSaturation com.apple.NanoRegistry com.apple.NanoRemote com.apple.NanoSleep com.apple.NanoStopwatch com.apple.NanoWorldClock (All the bundles can be seen in the Attached profile) Install the profile on a supervised or non-supervised iPhone paired with an Apple Watch. Restart both devices. Observe that several core Watch apps (e.g. Heart Rate, Activity, Workout) are missing from the Watch. Expected Behavior: All apps explicitly included in the allowlist should function normally. System apps — especially those tied to hardware like Apple Watch — should remain accessible unless explicitly excluded. Actual Behavior: Multiple Apple Watch system apps are removed or hidden, despite their iPhone bundle IDs being listed in the allowlist. Test Environment: iPhone running iOS 18 Apple Watch running watchOS 11 Profile includes only the allowListedAppBundleIDs key Issue confirmed on fresh devices with no third-party apps Request for Apple Engineering: Please confirm whether additional internal or undocumented bundle IDs are required to preserve Apple Watch functionality when allowlisting apps. If this behavior is unintended, please treat this as a regression or bug affecting key system components. If intentional, please provide formal documentation listing all required bundle IDs for preserving Watch support with allowlisting enabled. Attachment: .mobileconfig profile demonstrating the issue (clean, minimal, reproducible) Attached test profile = https://drive.google.com/file/d/12YknGWuo1bDG-bmzPi0T41H6uHrhDmdR/view?usp=sharing

We've put in a feedback assistant request, but not sure if we will get feedback in that channel or not and also want to highlight for others. When replacing a basic passcode profile on a macOS device with a passcode declaration, the user is required to change the password after logging out and back in. Explicitly including the "ChangeAtNextAuth" key set equal to false, set required a password change after logging out and back in. Once the declaration is active and the password has been changed, future updates to the passcode declaration do not require a password change unless the existing password is not compliant. Steps to reproduce: Install a basic passcode profile on a macOS device Ensure the existing password matches the requirements specified in the profile Install a passcode declaration with the same settings as the passcode profile currently installed Remove the traditional passcode profile from the device After the passcode declaration is installed, check the local pwpolicy with the command pwpolicy getaccountpolicies and look for the key policyAttributePasswordRequiredTime Log out of the macOS device Log back into the macOS device and you are presented with a change password prompt Expected result: Simply replacing an existing passcode profile with the exact same settings in a passcode declaration should not require a password change if the existing password is compliant. Actual results: After replacing the passcode profile with a passcode declaration, a password change was required even though the existing password was compliant. Initial testing was done with a macOS VM running 15.5. Additional testing has now been done with a macOS VM running 26.4.1 and the same behavior was observed.

Hi, We have a macOS app that uses NETransparentProxyManager (Transparent App Proxy) with a NETunnelProviderExtension. The Network Extension is configured and deployed via an MDM configuration profile. The profile is pushed through Intune MDM as a user-enrolled device (Company Portal enrollment, not ADE/supervised). The MDM profile sets up the Transparent Proxy extension as follows (sanitized snippet): <key>VPNType</key> <string>TransparentProxy</string> <key>TransparentProxy</key> <dict> <key>ProviderType</key> <string>app-proxy</string> <key>ProviderBundleIdentifier</key> <string>com.example.app.tunnel</string> <key>ProviderDesignatedRequirement</key> <string>identifier "com.example.app.tunnel" and anchor apple generic and certificate leaf[subject.OU] = TEAMID</string> <key>RemoteAddress</key> <string>100.64.0.0</string> </dict> <key>PayloadScope</key> <string>System</string> What we do in code: Call NETransparentProxyManager.loadAllFromPreferences — this correctly returns the MDM-managed profile (1 profile found) We do not call saveToPreferences — the profile already exists We call NEVPNConnection.startVPNTunnel() to connect and NEVPNConnection.stopVPNTunnel() to disconnect Problem: On a user-enrolled MDM device, when the app is running as a standard user (non-admin), every call to startVPNTunnel() or stopVPNTunnel() triggers the macOS VPN consent dialog: "VPN is trying to modify your system settings. Enter your password to allow this." Console log evidence: Failed to authorize 'system.preferences' by client '/System/Library/ExtensionKit/Extensions/VPN.appex' for authorization created by '/System/Library/ExtensionKit/Extensions/VPN.appex' (-60006) (engine 881) Key observations: Even if the user does not provide the admin credentials in the popup and cancel the window, still things work properly in the background i.e start/stop works. This does not happen for admin users on user-enrolled devices saveToPreferences is NOT called — the profile is MDM-managed and already present The prompt is triggered purely by startVPNTunnel() / stopVPNTunnel() from a standard user process Question: Is there a supported API, entitlement, or MDM configuration key that allows NETransparentProxyManager.startVPNTunnel() / stopVPNTunnel() to be invoked by a standard user process on a user-enrolled (non-supervised) device without triggering the system.preferences authorization dialog — given that the VPN profile is already deployed and managed by MDM?

Hi, Is there any possible way we can install enrolment provisioning profile using iOS app using User/Account Authentication Enrolment such as described in this thread: https://developer.apple.com/documentation/devicemanagement/implementing-the-oauth2-authentication-user-enrollment-flow

Hi, Is there any possible Apple approved way or workaround if we can bypass the stolen device protection delay of 1 hour when a user try to install our MDM server's enrolment profile on unknown location? I do not want managed apple account solution. I need solution for BYOD devices not for company owned. Thank you, Software Engineer - iOS

If I have a macOS devices enrolled in MDM, with a DDM policy defined to deliver passcode settings to the device I can run: sudo pwpolicy -getaccountpolicies to see the configuration on the device. I can subsequently run: sudo pwpolicy -clearaccountpolicies Then all passcode policies applied in my declarations are cleared from the device allowing the user to set and use any password they want with no bearing on the delivered passcode settings. I have left my macOS devices for days on and off network and the pwpolicy data never returns. The passcode settings do not restore on the device until I do one of the following: manually re-push all declarations from MDM log off and log back on reboot the computer It was my understanding that DDM was meant to assess device state and self heal on its own without requiring an MDM service to re-push any commands. Based on this finding this seems broken or I may misunderstand how DDM is supposed to work. macOS version: 26.4.1

Hi Dear Apple experts, I am hitting a problem (observed from Apr-15, maybe earlier) for renewing ABM/DEP token from my MDM server. My renewal steps: Download public key from my MDM server Upload the public key to the ABM Device Management server instance in ABM portal, and download a new token Upload the new token to my MDM server The problem here is at step-2: If upload the public key to an existing ABM Device Management server instance in ABM portal, then the generated token will be rejected by my MDM server with error "Could not find recipient info"; However, if upload the public key to a newly created ABM Device Management server instance, then everything is good. So, looks to me, it is the token issue when renewing an existing ABM MDM instance. Could you please help take a look? Thanks, Wei

Issue - Falcon application is intermittently not detected using system_profiler command Use case - We are trying to fetch the list of installed applications on macOS using the system_profiler command. While this works for most applications, we are observing inconsistent behavior with the Falcon application — it is sometimes detected as installed and sometimes missing from the results, even though it is present on the system. This inconsistency is causing issues in reliably tracking installed security software. Command used - /usr/sbin/system_profiler SPApplicationsDataType

Hi everyone, I'm running an Apple MDM service and encountering an issue where a number of devices stop receiving MDM push commands within 10 days of profile installation, even though everything appears to be set up correctly. Environment: MDM profile is installed and verified (status: OK, result: SUCCESS) Devices are cellular-enabled with no connectivity issues APNs certificate is valid (thousands of other devices are communicating normally) The command being sent to devices is DeviceInformationCommand No "NotNow" response or any check-in received from the affected devices for over a week Issue: We send DeviceInformationCommand to devices to retrieve device information and update the last communication timestamp. However, a subset of devices simply stop responding to this command within 10 days of profile installation. The last communication date is not being updated, and no response — not even a "NotNow" — is coming back from these devices. Since other devices on the same MDM setup are working fine, I've ruled out APNs certificate expiration and general server-side issues. Questions: Are there any known management points or configuration settings that could cause a device to silently stop receiving DeviceInformationCommand shortly after enrollment? What diagnostic steps would you recommend to identify the root cause on the device or server side? Are there any known bugs or reported issues related to this behavior in recent iOS versions? Is there any way to recover the MDM communication without requiring the user to re-enroll? Any insights or suggestions would be greatly appreciated. Thank you!

Hi Apple Community, We are using Automted Device Enrollment to Enroll macOS Devices and we used to Create AutoAdmin, PrimaryAccount using the Command Account Configuration . As a Part of Primary Account Creation while testing we see that BootStrap Token is Escrowed to MDM, and SecureToken is Created to Primary Account. The Primary Account user will enable FileVault as part of our process. As Tested internally, we seen that SecureToken is escrowed to AutoAdmin only when BootStrapToken is escrowed to MDM By device and AutoAdmin logs in then. That too After FileVault Unlock Since we Sendout the Laptop to users to setup themselves there are no chances of AutoAdmin Login to occur. And it defeats the purpose of having the AutoAdmin Account in emergency situation to login into it from Login Window. Can someone confirm if this behavior is expected and what are the expectation and recommendations from Apple on when to use AutoAdmin Account. Is there any other ways to use AutoAdmin directly from LoginWindow Before To FileVault Disk Unlock