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

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, 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?

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.

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

Hi, I have a question regarding the relationship between the Apple Developer Enterprise Program membership and an existing APNs certificate used for MDM. Current Situation We are operating an MDM server. We have already obtained a valid APNs certificate via the Apple Push Certificates Portal. Our Apple Developer Enterprise Program membership is about to expire. The only asset we have in the Enterprise account is the MDM CSR used during the APNs certificate issuance process. Question If the Apple Developer Enterprise Program Membership expires: Will the existing APNs certificate remain valid until its expiration date? Or will it become invalid immediately due to the account expiration? Thank you.