Hi Apple Community, I have been Developing Platform SSO With OpenID as Authentication Method, This is Great as it will allow clients to Configure their own Identity Provider Authentication Policy Enforced at Login Screen I have used Platform SSO with dynamicOpenID method with this , macOS sends redirect_uri=com.apple.PlatformSSO://callback (Camel Case "com.apple.PlatformSSO") to the Identity Provider during OIDC Authentication to Authorization URL . After During Platform SSO Login Request The subject_token in the Login Request then contains com.apple.platformsso://callback (lowercase). RFC 6749 Section 4.1.3 requires these values to be identical, so my Identity Provider rejects the token request. Is this expected, or a macOS bug? Environment macOS version: Golden Gate ( 27.0.1 ) Platform SSO Authentication method: OpenID ( dynamicOpenID ) Document Followed : https://developer.apple.com/documentation/authenticationservices/implementing-web-based-authentication Configuration federationType = .dynamicOpenID fallbackFederationType = .dynamicOpenID authorizationURLKeypath = "authorizationURL" Reference Steps to reproduce macOS makes the pre-authentication request, and my server responds: HTTP/1.1 200 OK Content-Type: application/json { "account_type": "Federated", "federation_protocol": "OIDC", "authorizationURL": "https://idp.example.com/authorize?state=random" }Platform SSO opens a WebView, loads the authorization URL, and appends redirect_uri with a capital "PSSO": GET https://idp.example.com/authorize?state=random&redirect_uri=com.apple.PlatformSSO://callbackAuthentication completes. Platform SSO then sends the Login Request. The decoded JWT claims contain a subject_token with a lowercase "platformsso": { "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange", "subject_token": "com.apple.platformsso://callback?code=gAJZwNpLDPardp8NKwvyyJLYefxLqMQH&state=ABCD1234", "subject_token_type": "urn:apple:platformsso:authorization-code-response", "scope": "openid offline_access urn:apple:platformsso urn:apple:platformsso:auth:auth-prompt", "aud": "https://auth.example.com/auth/token", "...": "other claims omitted for brevity" }The mismatch Authorization request (WebView): com.apple.PlatformSSO://callback Login Request subject_token: com.apple.platformsso://callback Why it matters RFC 6749 Section 4.1.3 says redirect_uri is REQUIRED in the token request if it was included in the authorization request, and the values MUST be identical. Because the two differ, a spec-compliant IdP rejects the code exchange. Expected behavior Both stages use the same redirect_uri string. Actual behavior The scheme differs in case, and the IdP rejects the request. Questions Is this intentional? If so, how should an IdP handle it without breaking RFC compliance? Is there a configuration option to control or normalize the redirect_uri that Platform SSO sends? Can someone from the Community help with how to overcome this if faced Thanks!!!

Hello everyone! I'm a software engineer currently working on the development of a Mobile Device Management (MDM) system. I'm trying to implement a restriction that prevents users from manually removing the MDM enrollment profile from their iOS devices. While researching Apple's Device Management documentation, I came across two configurations that seem related to this functionality: PayloadRemovalDisallowed: A Boolean key that appears to control whether users can remove a configuration profile. com.apple.profileRemovalPassword: A payload that allows a removal password to be configured using the RemovalPassword key. However, after attempting to implement these configurations in our .mobileconfig files, I haven't been able to achieve the expected behavior. In some cases, these changes also interfere with our device enrollment process, preventing devices from successfully enrolling in our MDM system. Questions What is the correct way to use PayloadRemovalDisallowed and com.apple.profileRemovalPassword within a .mobileconfig file? Should they be used together, or are they intended for different scenarios? Where exactly should these configurations be placed? Should PayloadRemovalDisallowed be defined at the root level of the configuration profile, while com.apple.profileRemovalPassword is included as a separate payload inside PayloadContent? Can these configurations be included directly in the MDM enrollment profile? Or should they be delivered through a separate configuration profile after successful enrollment? Do these configurations require the device to be supervised? Is it possible to prevent profile removal on manually enrolled devices, or is Automated Device Enrollment (ADE) required? Why might these configurations interfere with device enrollment? Are there any restrictions on combining an MDM payload (com.apple.mdm) with a profile removal password payload? Does setting PayloadRemovalDisallowed to true actually prevent removal of the MDM enrollment profile itself, or does it only apply to regular configuration profiles? Is there any supported way to make an existing MDM enrollment profile non-removable after enrollment? Could someone provide a working .mobileconfig example demonstrating the correct implementation of these configurations? Expected Behavior Once a device has been successfully enrolled in our MDM system, the user should not be able to remove the MDM enrollment profile manually through the device settings. Ideally, this restriction should not interfere with the initial enrollment process or subsequent communication between the device and our MDM server. Current Behavior When attempting to configure PayloadRemovalDisallowed and com.apple.profileRemovalPassword, the expected removal restriction does not work correctly, and the enrollment process may fail. I'm trying to understand whether this is caused by incorrect placement of the configuration keys, limitations imposed by the enrollment method, or specific Apple device management requirements. Any guidance, official documentation, or working implementation examples would be greatly appreciated. Thank you in advance for your help!

I have so far been unable to enrol a macOS 27 beta VM in to Jamf since initial beta release. Is this by design? I can’t find any documentation or posts on apple developer forums about this anywhere. My agentic coding session has done some probing around in the VM and it thinks something is going wrong with Secure Keychain within the VM. Everybody on my team is observing the same behaviour as this, and I’ve had it happening across two different laptops (one of them which is, itself, running the latest macOS 27 Beta, and the other which I created a Beta VM by installing Tahoe in the VM, logging in to iCloud, and enabling Beta channel updates) The only thing we’ve found we can do so far is to join to Jamf in Tahoe first, but the problem I have there is, often times the option for Beta channel updates just doesn’t present itself in System Settings -> Software Update after signing in to iCloud, and I don’t know why it sometimes does but often doesn’t. Logs from agentic coding session below: The core log evidence This is the whole causal chain, from the 27 guest's unified log, inside 370 microseconds. Innermost failure first: 05:24:04.967316 apsd: (CryptoTokenKit) [com.apple.CryptoTokenKit:sepkey] <sepk:* kid=0000000000000000>: (apsd) unable to generate key: error e00002e2(-536870174) ACL=<SecAccessControlRef: dk;ock(true);odel(true);osgn(true);oa(true);okd(true)> 05:24:04.967433 apsd: (Security) [com.apple.security:seckey] SecKeyCreateRandomKey_ios failed: NSOSStatusErrorDomain Code=-25308 "Failed to generate keypair" (errSecInteractionNotAllowed / Interaction is not allowed with the Security Server.) 05:24:04.967574 apsd: (DeviceIdentity) com.apple.MobileActivation.ErrorDomain Code=-1 "Failed to create reference key." 05:24:04.967600 apsd: [com.apple.apsd:courier] APSBAAClientIdentityProvider failed to obtain a BAA cert, error: com.apple.MobileActivation.ErrorDomain Code=-1 "Failed to create reference key." 05:24:04.967686 apsd: [com.apple.apsd:courier] <APSCourierConnectionManager; production>: Stream error occurred for : APSErrorDomain Code=1 "Told not to connect after fetching server bag: (null) - closing stream" Read bottom-up: Secure Enclave key generation fails, so MobileActivation cannot create the reference key, so apsd cannot obtain its BAA device-identity certificate, so APNs tells it not to connect. kid=0000000000000000 means there is no key id at all. Then every courier line reports Connected on 0 interfaces, and mdmclient sets its PushWakeTopics only to get Connection Invalid for service com.apple.apsd and tear down. The command to regenerate it: log show --predicate 'process == "apsd"' --last 60m --info | grep -iE 'BAA|unable to generate key|server bag'. New control, collected just now mac26 happened to be running, so I got the comparison. macOS 26.6 (25G72) guest, same host, same network, 3 days uptime: BAA_FAILURES: 0 SEPKEY_FAILURES: 0 APNS_SOCKETS: 192.168.64.8.52286 -> 17.57.146.7.443 ESTABLISHED 192.168.64.8.52285 -> 17.253.77.203.443 ESTABLISHED (+ 3 more into 17.0.0.0/8) No BAA or courier complaints at all over 6 hours, and live connections into Apple's network. So a virtualised guest per se is fine; the 27 guest specifically cannot mint the key. The physical host, also on macOS 27.0, likewise logged zero of both failures over 3 hours.

We use MDM protocol and configuration profile to enable/disable camera. When we disable camera, the Camera icon and FaceTime icon on the Home Screen diseppear. Then we enable camera again, both icons are restored, but they are moved to the last on the Home Screen. It's very inconvenient for end users. How to restore both icons to the previous position? Any help would be greatly appreciated.

We use MDM protocol and configuration profile to enable/disable camera. When we disable camera, the Camera icon on the Home Screen diseppears. Then we enable camera again, sometimes, the Camera icon isn't restored on the Home Screen, and we can't find it in the App Library either. The Camera icon can be restored only after the iPhone is restarted. This issue occurs more frequently on iOS 27+. Is there anything we can do to ensure the Camera icon is restored? Any help would be greatly appreciated.

Hello, I'm a developer of an MDM solution that we provide to multiple companies. Issue On iOS 27.0.1, the camera is not re-enabled after the camera restriction is lifted. We use a configuration profile to disable the camera (allowCamera = false). After the profile is removed, the Camera app should become available again, but it stays disabled. What we've confirmed The issue was first reported by a customer. I was then able to reproduce it on my own test device running the same iOS version (27.0.1). The restriction profile is no longer installed on the device. No profile remains under Settings > General > VPN & Device Management. The customer has Screen Time enabled. On my test device, restarting the device resolved the issue. On the customer's device, the issue persists even after restarting. Questions Is this a known issue in iOS 27.0.1? Could Screen Time (Content & Privacy Restrictions) keep the camera disabled after the MDM restriction is removed? Is there a recommended way to fully restore the camera, either on the device or from the MDM side? Any guidance or workaround would be greatly appreciated. Thank you.

My Apple MDM Vendor Certificate request (Case ID: 103003418539) has been pending since October 21, 2026, with no response or status update. Has anyone experienced similar delays? Is there any way to escalate the request or get an update from Apple? Any guidance would be appreciated. Thank you!

Is anyone else seeing this? Apple's documentation says "Your distribution certificate is valid for three years from when it was issued" (https://support.apple.com/guide/deployment/distribute-proprietary-in-house-apps-depce7cefc4d/web). On 2026-10-13 our automation created a new iOS Distribution certificate on our Apple Developer Enterprise Program account through the App Store Connect API (POST /v1/certificates, type IOS_DISTRIBUTION, with a CSR). The certificate expires 2027-11-12, which is about 395 days. Our previous enterprise iOS Distribution certificate, created in April 2025, got the full 3 years (expires 2028-04-28). To rule out our automation, I created another iOS Distribution certificate manually in the Developer portal on 2026-10-16. It also had a validity of about 396 days. We have revoked both so they can't be used. Questions: Has the validity period for Enterprise Program iOS Distribution certificates changed? If so, where is it documented? Is anyone else seeing ~395-day certificates on Enterprise accounts, from the portal or the API? Is there a supported way to request a specific validity period? I have also opened a case with Apple Developer Support (case ID 102999420277).

I'm a tax resident of the Netherlands and have a Ukrainian citizenship. The field "Country or Region of Citizenship" is locked and prefilled with "Netherlands". I don't want to provide incorrect information and still waiting for the support answer. This is obviously a bug. How can I change it? I've seen some similar posts, but there is no useful answers.

Hi everyone, We are testing Apple's native MDM migration flow. When we accidentally push an expired/past timestamp for the mdm_migration_deadline, identical test devices behave inconsistently: • Device 1: Immediately triggers the migration flow. • Device 2: Automatically shifts the on-screen countdown timer to exactly 30 minutes in the future. • Device 3 (Flight Mode): Bypasses the lockout while offline, but acts erratically once reconnected. What is the hardcoded framework fallback when a device parses an already-expired deadline? Has anyone else seen the OS dynamically generate this 30-minute grace window? Thanks!

My country is not supportet in the business manager. Is there a way to register an account without the DUNS number. because my company is tied to the country with the DUNS number. that's why the registration doesn't work

Background We need to sync corporate contacts to native iOS Apple Contacts via CardDAV, restricted strictly to company-managed devices using mTLS (deployed via .mobileconfig). Problem The backend sits behind an AWS ALB with native mTLS enabled (Verify with trust store). However, ALB logs show that the iOS client fails to present the client certificate during the TLS handshake, causing the ALB to reject the connection (leaf_client_cert_subject: - (empty client cert offered during handshake). What I Have Verified & Tried In .mobileconfig, I declared both com.apple.security.pkcs12 and com.apple.carddav.account. However, there seems to be no fields to link the pkcs12 to the carddav account. Installed Root CA on iOS -> Settings > General > About > Certificate Trust Settings > Enabled "Full Trust For Root Certificates". I check the CardDAV UI but there is nowhere to add client certificate. Questions How to implement mTLS on native iOS Apple Contacts via CardDAV?

We're working on an iOS app distributed through the App Store and installed on an MDM-enrolled device. Our MDM server uses InstallApplication to take management of the already-installed and running app. On iOS 27 betas 3 and 4, processing this command causes iOS to terminate the app and its extensions with SIGKILL. The same flow and MDM payload work without terminating the app on earlier iOS versions (iOS <=26). Environment OS: iOS 27 betas 3 and 4 Does not happen: iOS 26 or iOS 16.7.15 Device: iPhone SE 2nd Gen Enrollment: MDM-enrolled device Distribution: App Store app App state: Already installed and running when management is requested MDM command: InstallApplication Minimal MDM command The MDM server sends an InstallApplication command for the already-installed app: Attributes = { Removable = false; }; ChangeManagementState = Managed; Identifier = "APP_BUNDLE_ID"; InstallAsManaged = true; ManagementFlags = 1; RequestType = InstallApplication; We also tested the equivalent command using iTunesStoreID = APP_STORE_ID instead of Identifier, and removing InstallAsManaged. The targeted running app was terminated in the same way. Steps to reproduce Install and launch the App Store app as an unmanaged app. Enroll the iPhone in MDM. While the app is running, send the MDM InstallApplication command to take management of the existing installation. Observe the unified logs for mdmd, appstored, manageddeviced, installcoordinationd, and runningboardd. The issue can also be reproduced by initiating the same server-side flow while the app is already in the background. iOS 27 log sequence The command is accepted and appstored starts the managed-app tasks. manageddeviced then attempts to mark the app as managed using a null persona (this differs from iOS <26): The running app has a valid persona. After the failed mapping, installcoordinationd explicitly asks RunningBoard to terminate the app to disassociate that persona: After termination, removing the valid persona also fails. The managed-app task later reports success despite the mapping failures and termination. Earlier iOS comparison As an example, on iOS 16.7.15, using the same MDM command, **iOS routes the request through dmd with persona: default. The app remains alive and receives managed-app change notifications. Expected The existing installation becomes managed without terminating the running app, consistent with the behavior on earlier iOS versions. Actual manageddeviced tries to associate the app with persona (null) and fails with MIInstallerErrorDomain Code 191. That failure causes installcoordinationd to request termination of the app and its extensions to disassociate their valid persona. runningboardd terminates them with SIGKILL (isUserKill=0). The subsequent removal of the only valid persona fails with Code 242, although the managed-app task later reports success. Documentation checked The payload follows the documented InstallApplication flow for taking management of an existing app: Apple Docs WWDC26 app MDM updates We have not found a malformed field that explains the iOS 27-only failure. More info Detailed logs and additional info can be found on the Feedback report.

Could you please advise us on how to obtain the Apple Account ID in the following cases? The Apple Account ID currently signed in on an iOS device. The Managed Apple Account ID associated with the Apple Business Manager (ABM) or Apple School Manager (ASM) account that manages the Apps and Books token. We would appreciate it if you could let us know whether there is an API, MDM command, or other supported method to retrieve these IDs.

We are migrating our macOS applications from the legacy PPPC Accessibility service to the macOS 27 declarative App Settings configuration, as recommended by Apple. The applications require Accessibility permission to provide managed data-protection functionality and create the required event taps. Our configuration contains: A declarative com.apple.configuration.app.settings configuration that sets the Accessibility privacy permission to Allow. A legacy PPPC payload that grants PostEvent, because this service is not available through App Settings. The declaration and PPPC payload are delivered and applied successfully. After the user accepts the macOS Allow / Not Now prompt, the application’s Accessibility slider is enabled under: System Settings → Privacy & Security → Device Control and Data Access The user can turn it off even while the management declaration remains installed and active. When the user disables the setting: The application loses Accessibility access. Required event-tap functionality stops working. The application may display the legacy Open System Settings / Deny Accessibility prompt when the protected feature is subsequently activated. Manual user intervention is required to restore the application’s functionality. Expected behavior: We expected an Accessibility permission managed by MDM/DDM to remain enforced while its declaration is active, similar to the behavior of an Accessibility permission granted through the legacy PPPC payload. Apple’s AppSettings documentation states: “The user can change the app permission privacy settings in Settings.app if they choose.” This appears to describe the behavior we are observing. However, it is unclear how an organization can enforce a required Accessibility permission after the legacy PPPC Accessibility grant is deprecated on macOS 27.

We develop an endpoint security agent that customer IT deploys and manages via MDM on supervised, ADE-enrolled Macs. The agent requires Accessibility permissions to perform core security functions. Historically, IT provisioned this via the PPPC payload which granted Accessibility as a managed control without end-user interaction. In macOS 27 this path for Accessibility has been removed. The documented replacement — the Privacy key in com.apple.configuration.app.settings — is consent-based: on a supervised device it presents the user a consolidated prompt with "Allow" preselected, which the user may decline. We are seeking guidance on the supported approach for macOS 27 GA: On a supervised macOS 27 device, is there a supported mechanism for an MDM-managed, code-signature-verified application to be provisioned with Accessibility as a managed security control, without depending on individual end-user consent? (i.e. an equivalent to what PPPC provided for enterprise-managed endpoints.) If the consent-based com.apple.configuration.app.settings Privacy declaration is the only path, what is Apple's recommended approach for enterprise-mandated security agents that must have Accessibility to function — including handling the case where a user declines or dismisses the prompt? We have also filed this as an enhancement request via Feedback Assistant (FB23531820). Environment for context: macOS 27 supervised via Automated Device Enrollment, managed by Jamf Pro.

We are experiencing an issue with Privacy Preferences Policy Control (PPPC) profiles deployed through Jamf Pro on the Golden Gate beta. We use the following Jamf configuration profiles to pre-approve Digital Guardian Accessibility permissions: DG – Grant Accessibility Access to DgSessionSvc.app DG – RME These profiles are intended to grant Accessibility permissions automatically for Digital Guardian under: System Settings → Privacy & Security → Accessibility On macOS Tahoe and macOS Sequoia, these PPPC profiles work as expected. After deployment, the required Accessibility permissions are granted automatically and users are not prompted. However, on the Golden Gate beta, the same configuration profiles are installed successfully, but the required Accessibility permissions are not granted. As a result, users continue to receive the Accessibility permission prompts. We also observed a difference when inspecting the installed profile under: System Settings → General → Device Management → Profile On macOS Tahoe, the installed profile contains the following entry: Control the Computer — com.verdasys.DgSessionSvc — Allowed On the Golden Gate beta, this entry is missing, even though the identical Jamf PPPC profile has been installed successfully. For reference, we have attached: The Jamf PPPC configuration profiles (.mobileconfig) DGSessionSvc MobileConfig RME MobileConfig Comparison screenshots from macOS Tahoe and the Golden Gate beta Could you please confirm whether this is: a known issue in the Golden Gate beta, an intentional change in PPPC behavior, or an issue with our PPPC configuration profile? If this is an operating system issue, we would appreciate it if it could be investigated and addressed in a future Golden Gate beta release. Environment Affected OS: Golden Gate 27.0 Beta (26A5388g) Working OS versions: macOS Tahoe and macOS Sequoia MDM Solution: Jamf Pro 11.30.1 Affected Application: Fortra Digital Guardian Required Permission: Accessibility (Control the Computer) Architecture: Apple silicon We would also appreciate it if you could review the attached .mobileconfig files and let us know whether any modifications are required to make the PPPC profiles compatible with the Golden Gate beta, or if any additional information would be helpful for your investigation.

PermissionDefaults under Privacy for com.apple.configuration.app.settings , device reports Info.UnsupportedSettings for "$.Privacy.PermissionDefaults for macOS 27 device iMac manufactured 2024 Request from MDM : "Type": "com.apple.configuration.app.settings", "Payload": { "Privacy": { "PermissionDefaults": { "net.soti.mobicontrol.macOS": { "OrganizationJustification": "Message", "Accessibility": "Allow" }, "net.soti.mobicontrol.macOSHelper": { "OrganizationJustification": "Message", "Accessibility": "Allow" } } } }, "Identifier": "2adc58b3-f631-41b8-93d8-f55612055c30", "ServerToken": "4dc895cc-b7c2-4729-b8a4-f9e2f8dba5a9" } Response from Device: { "StatusItems": { "management": { "declarations": { "activations": [ { "active": true, "identifier": "77409e31-ff4f-4f86-a1bd-175515e3a3bd", "valid": "valid", "server-token": "b096dd48-a127-4f65-a60d-bd615911deb8-1" }, { "active": true, "identifier": "84992e13-edc2-4791-989e-0cc54bd18ab8", "valid": "valid", "server-token": "8460aca3-b263-43fe-b659-343c81a6479e" }, { "active": true, "identifier": "bfd661e8-b81f-4383-b243-00330fca13ae", "valid": "valid", "server-token": "38399079-5402-401a-83f4-c39e8b4807e8" } ], "configurations": [ { "active": true, "identifier": "00d217fe-f6e2-479f-89b5-73b479bd9f1d", "valid": "valid", "server-token": "c25104a2-6d13-44a1-ac00-ccc916490ae9" }, { "reasons": [ { "details": { "Settings": [ "$.Privacy.PermissionDefaults" ] }, "code": "Info.UnsupportedSettings" } ], "active": true, "identifier": "2adc58b3-f631-41b0-93d8-f55612055c30", "valid": "valid", "server-token": "4dc895cc-b7c2-4429-b8a4-f9e2f8dba5a9" }, { "reasons": [ { "details": { "Settings": [ "$.Privacy.PermissionDefaults" ] }, "code": "Info.UnsupportedSettings" } ], "active": true, "identifier": "c5bc77f6-745d-43ae-9e49-6e9100d3f6a5", "valid": "valid", "server-token": "e3a5cdb3-fd51-42a2-afb4-fe5f602a493d-1" } ], "assets": [], "management": [] } } }, "Errors": [] }

I am evaluating Apple Music integration for a paid Windows desktop application that lets users migrate playlists they own between music services. The app would not stream, download, cache, redistribute, or monetize Apple Music audio, artwork, or previews. The Apple Music integration would be limited to: reading the user’s playlists; matching songs using catalog identifiers and metadata; creating playlists in the user’s Apple Music library; reconstructing the user’s playlists on another music service at their explicit request. I would like to clarify whether this type of user-initiated playlist migration is compatible with MusicKit / Apple Music API terms, especially for a paid application. If this is not the correct forum for a policy question, could an Apple engineer please point me to the appropriate channel? Thank you.

I’m developing a macOS VPN app distributed directly with Developer ID. Its NEPacketTunnelProvider is packaged as a System Extension (packet-tunnel-provider-systemextension). On macOS 15.6 (24G84), I installed a configuration profile containing: A com.apple.security.acme payload with HardwareBound=true, Attest=true, and a P-256 key. A com.apple.vpn.managed payload whose PayloadCertificateUUID references that ACME payload. VPNSubType and ProviderBundleIdentifier identify my app and provider. macOS issued the certificate, and the managed VPN starts the provider. In startTunnel, protocolConfiguration.identityReference is non-nil (20 bytes). However, resolving it in the provider returns -25291 (errSecNotAvailable): `let query: [CFString: Any] = [ kSecClass: kSecClassIdentity, kSecValuePersistentRef: identityReference, kSecUseDataProtectionKeychain: true, kSecReturnRef: true, kSecMatchLimit: kSecMatchLimitOne ] var result: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &result) The containing app receives the same non-nil reference, but its identity query returns -25306. Neither binary currently has the com.apple.managed.vpn.shared keychain access group; I understand that this group requires a separate managed capability. An Apple Device Management Engineer states that third-party processes cannot access hardware-bound ACME identities in the Data Protection Keychain, with an exception for VPN extensions. The NETunnelProviderManager documentation says that apps and Packet Tunnel Providers need com.apple.managed.vpn.shared to use credentials supplied by configuration profiles. Is com.apple.managed.vpn.shared the supported way for a Developer ID Packet Tunnel System Extension to resolve this specific hardware-bound ACME identity? If granted, should the provider use the query above, or another public API? Does the VPN-extension exception apply when the System Extension runs outside the logged-in user’s keychain context? If this is unsupported for a System Extension, what is the supported approach for a directly distributed Developer ID VPN app to perform client authentication with this non-exportable key? I need a usable SecIdentity or signing operation, not the private-key bytes.