General: Forums topic: Privacy & Security Apple Platform Security support document Developer > Security Enabling enhanced security for your app documentation article Creating enhanced security helper extensions documentation article Security Audit Thoughts forums post Cryptography: Forums tags: Security, Apple CryptoKit Security framework documentation Apple CryptoKit framework documentation Common Crypto man pages — For the full list of pages, run: % man -k 3cc For more information about man pages, see Reading UNIX Manual Pages. On Cryptographic Key Formats forums post SecItem attributes for keys forums post CryptoCompatibility sample code Keychain: Forums tags: Security Security > Keychain Items documentation TN3137 On Mac keychain APIs and implementations SecItem Fundamentals forums post SecItem Pitfalls and Best Practices forums post Investigating hard-to-reproduce keychain problems forums post App ID Prefix Change and Keychain Access forums post Smart cards and other secure tokens: Forums tag: CryptoTokenKit CryptoTokenKit framework documentation Mac-specific resources: Forums tags: Security Foundation, Security Interface Security Foundation framework documentation Security Interface framework documentation BSD Privilege Escalation on macOS Related: Networking Resources — This covers high-level network security, including HTTPS and TLS. Network Extension Resources — This covers low-level network security, including VPN and content filters. Code Signing Resources Notarisation Resources Trusted Execution Resources — This includes Gatekeeper. App Sandbox Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

General: Forums topic: Privacy & Security Privacy Resources Security Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I've been unable to enroll in the Apple Developer Program for several weeks. When I navigate to the enrollment page, I'm redirected to a contact form instead of the enrollment flow — this happens for both Individual and Organization enrollment, on multiple browsers and devices. I have an existing support ticket on file and have provided the requested screenshot. The ticket has gone unanswered. Is there anything on the account side that is blocking enrollment from proceeding? If an Apple staff member can look into this, I'm happy to provide my Apple ID and ticket number via direct message.

Dear community, I recently transferred my iOS app to a different developer account as part of an app acquisition. When uploading now on the new team the first build from the new team via Xcode Cloud, I get: ITMS-90076: Potential Loss of Keychain Access - The previous version of software has an application-identifier value of ['OLDTEAMID.ch..'] and the new version of software being submitted has an application-identifier of ['NEWTEAMID.ch..']. This will result in a loss of keychain access. I understand this is expected, since the App ID prefix changed from the old Team ID to the new one. The problem is that this app is a crypto wallet: it stores the user's private key in the keychain using the default access group ($(AppIdentifierPrefix)$(CFBundleIdentifier)), with kSecAttrAccessibleWhenUnlockedThisDeviceOnly and no iCloud synchronization. If existing users update to a build signed by the new team, they permanently lose access to their keys — there is no server-side recovery. <key>keychain-access-groups</key> <array> <string>$(AppIdentifierPrefix)$(CFBundleIdentifier)</string> </array> It was extremely stupid to do it like this :( I've read the "App ID Prefix Change and Keychain Access" post, which describes migrating keychain items into an app-group-based access group before the transfer, then transferring the app group along with the app. Unfortunately, my transfer has already completed. My questions: Is transferring the app back to the original team, shipping a migration update that moves keychain items into an app group access group, and then re-transferring the app together with the app group still the recommended (and only) path in this situation? Are there any pitfalls with migrating items protected by SecAccessControl (.userPresence) into an app group access group, given that reading them requires biometric/passcode authentication? Is there any timing constraint or cooldown I should be aware of when transferring an app back and then transferring it again shortly after? Any other less time intensive options? Is it possible to "transfer a team id"? Or rename/handover the old account to the new developer? Thank you for the team and guidance on this.

Hi, I have an app which I would like to test on macOS27, specifically the use of 'Accessibility' permission which is granted via the new DDM payload introduced in macOS27 (com.apple.configuration.app.settings). Problem is once the app is launched once and the consent popup is displayed and a choice is made ('Allow' or 'Not Now') I cannot reset the system so that the popup appears again for test purposes, i.e. is there a command line I can execute similar to 'tccutil reset Accessibility' which would reset the system? Thanks

Steps to reproduce: register a passkey on device A authenticate on device A, using the prf extension and a constant salt. Note the prf output go to device B. wait for iCloud sync authenticate on device B using the prf extension and the same constant salt. Note the prf output The prf outputs are different. Note: Repeat the authentication on each device. The prf output is identical for a given device, which seems to point towards the inclusion of a device specific component in the prf derivation. In my scenario, I need the prf output to be the same regardless of the device since I use it as the recovery key for my app data. Could you confirm that this is the expected behavior or not? Thanks,

With the recent Platform SSO announcements from Apple, I noticed that users can now authenticate at the macOS login window and Filevault screen using an OIDC-based web authentication flow through their IDP. My understanding was that historically, unlocking the user's keychain and establishing a login session required either: The user's local account password, or Smart card-based authentication integrated with macOS login mechanisms. Given the new Platform SSO capabilities, I am curious about the underlying authentication model and whether it introduces new possibilities for third-party developers. Specifically, is there now any supported mechanism for a third-party login or authorization solution to leverage Secure Enclave-backed credentials to establish a user session and unlock the login keychain without requiring a local password, similar to the passwordless experience enabled by Platform SSO? My use case is providing a passwordless login experience through a custom authorization plugin for organizations that may not want to deploy Platform SSO but still want users to authenticate using device-bound cryptographic credentials stored in the Secure Enclave. Are the capabilities used by Platform SSO available to third-party developers, or are they restricted to the Platform SSO framework and its associated system integrations? Any guidance on supported architectures or limitations would be appreciated.

We are a financial institution and are considering to introduce passkeys as login mechanism for our web banking application. We see this as an important step to curb phishing. But we saw that there is a way to share passkeys with others - https://support.apple.com/guide/iphone/share-passwords-iphe6b2b7043/ios - and are wondering if this can be disabled by us for our passkeys. Social engineering attacks are very sophisticated nowadays and we are afraid attackers would be able to manipulate customers to share their passkeys with them. thanks for your help stefan

We are evaluating whether Apple Platform SSO can be used by a native macOS application to silently authenticate against our backend through an identity provider's SSO extension. Our environment is as follows: Apple Platform SSO is configured and active. Device registration and user registration have completed successfully. Authentication is backed by Secure Enclave / Platform SSO. The identity provider is integrated through an SSO extension. Tokens are active and Not Expired We would like to understand the intended behavior and supported usage patterns of Platform SSO from the perspective of a third-party native macOS application. Specifically: Once Platform SSO is active, is there a supported way for a third-party macOS application to obtain IdP bearer/access tokens silently (without UI, password prompts, or web-based authentication) through the SSO extension? If silent token acquisition is supported, is it intended to work for any third-party application, or only for applications developed and distributed by the IdP/vendor that provides the SSO extension? In our testing, requests created via ASAuthorizationSingleSignOnRequest are rejected by the extension with doNotHandle. Does this generally indicate that: the request falls outside the extension's supported flow, a different request configuration is expected, or ASAuthorizationSingleSignOnRequest is not intended for this Platform SSO scenario? For native macOS applications that need silent authentication, should the recommended approach be: standard OAuth/OIDC flows, Platform SSO APIs, or a combination of both? If OAuth/OIDC is involved, which parts of those flows are expected to be handled transparently by Platform SSO and the SSO extension? If a combination of both is the recommended approach, many OAuth/OIDC flows rely on flow-specific security mechanisms such as client secrets, private keys, client certificates, or signed client assertions. In that case, the overall model becomes unclear Is there a standard protocol or capability that SSO extensions are expected to implement to support application authentication under Platform SSO, or is this entirely vendor-specific and dependent on the IdP's implementation and SDK? If there is an Apple-recommended pattern for enabling silent authentication from native third-party macOS applications when an IdP SSO extension is present, we would appreciate any guidance or references to relevant documentation. Thank you.

I am using ASAuthorizationProviderExtensionLoginManager.resetKeys() to generate new user-specific keys, specifically userDeviceSigningKey and userDeviceEncryptionKey. Based on the documentation, my understanding was that resetKeys() only resets keys associated with a particular user account: https://developer.apple.com/documentation/authenticationservices/asauthorizationproviderextensionloginmanager/resetkeys/ However, during testing, I observed that calling resetKeys() also resets sharedDeviceSigningKey. I had assumed that shared device keys would only be reset via resetDeviceKeys().

We are developing an enterprise security solution for macOS that includes Wi-Fi awareness and network-based policy enforcement - WiFi Control. On current macOS releases, access to the connected Wi-Fi's SSID/BSSID appears to require Location Services authorization. In many corporate environments, end users do not have local administrator privileges and cannot enable Location Services themselves. Enabling it often requires coordination with IT administrators, which can be difficult to scale in large organizations with a geographically distributed workspace. This creates a deployment challenge for enterprise security products because network identification becomes unavailable on managed Macs, even when the device is enrolled and managed through MDM. As far as we understand: MDM on macOS does not provide a mechanism equivalent to managed-device Wi-Fi control available in iOS management scenarios. System Extension running with elevated privileges cannot obtain the current SSID/BSSID through frameworks such as CoreWLAN even when Location Services access is granted (it requires user session). Our questions are: Is there currently any supported API or entitlement that allows enterprise security products to determine the currently connected SSID/BSSID on managed macOS devices without requiring end users to enable Location Services? Are there plans to provide a managed-device exception, entitlement, or MDM-controlled authorization model for enterprise security vendors that need network identity information for security and compliance use cases? Would Apple consider exposing SSID/BSSID information to approved System Extensions or Endpoint Security-based products in managed corporate environments, while maintaining existing privacy protections for consumer devices? We fully understand the privacy rationale behind restricting Wi-Fi information, but enterprise security and compliance solutions often need to identify trusted and untrusted networks. Today, the Location Services dependency significantly complicates deployment and usability in managed corporate environments. Any guidance on recommended approaches or future platform direction would be greatly appreciated.

For a Swift package that requires app developers to set a String API key at the app level (one key per app, not per user), what is Apple’s recommended approach for allowing those keys to be securely rotated without requiring an App Store redeploy?

Many apps are distributed on the public App Store. Those same apps can also be installed on company managed devices. While user enrolled devices will likely or certainly have an Apple Account on there, that is not the case for supervised devices. The company that manages the device might prohibit the use of Apple Accounts. I'd like to see a capability where the MDM can provision the device with an assurance of an age being met. In the majority of practical purposes, users enrolling devices into an MDM are likely employees due to the nature of MDM. Same for users of supervised devices. An API that lets the MDM tell the app that even though the API returns unavailable (or some new enum), that its okay to proceed because the business is assuming the risk of the age being met to consume some app. I have a feedback I wrote up last December for this FB21340165 Another idea I've played around with would be to have a fail proof way for developers to detect if the app is MDM installed, just on the regular, not related to DeclaredAgeRange API. One could look for managed app configuration via the legacy UserDefaults mechanism, or the new ManagedApp framework--but there is no guarantee that the MDM administrator is actually going to use that feature. If you're deploying an app to your company devices and employee enrolled devices, you can implement app config with a signal to the app, but for B2B apps and other businesses there is no assurance. To be clear, I'm not asking for interpretation of the regional laws as I know the FAQ page directs developers to our internal legal reps, I just want to know how to best use the DeclaredAgeRange API in the context of an MDM deployment.

es_set_deadline_miss_mode() is there going to be a way to check the deadline was missed and ES replied? what file open flags are going to be used? es_set_deadline_max_milliseconds() is there a limit for the max value? can we apply it for all event types or are there any limitations? es_set_deadline_min_milliseconds() is for ES descendants clients but the set_deadline_max version does not mention descendants in the description. Is it just missed in the description? Could you describe intended usage of the descendant ES clients a bit more, please? Are the reserved ES events (like the one for pasteboard) preparation for potential public use or are they solely intended for internal use?

Is there a setting or option from the last iOS updates that turned on stolen device protection? There seemed to be mixed results coming out from these updates that either turned this on when it was off, remained off and didn't get turned on, or had no effect (ie. it was off initally and stayed off).

Unlike almost all other system TCC prompts, the DeclaredAgeRange does not have an API to detect the current status. This makes it hard to determine when it is appropriate to show a permission flow that explains what the app does with the information. I do the workflow during onboarding, and when app features are being accessed. I would like to not just 'pop up' if the user completed onboarding on iOS 18, and then upgraded to 26 (or 27). FB21157742

The DeclaredAgeRange framework's 'actions' are not sendable. This means when the app is in swift 6 mode, the sample code provided in the documentation won't even compile due to the thread isolation. Is there any reason why the action closure in the environment can't be sendable? Otherwise @preconcurrency import for me. FB20959748

As the direct TCC.db access will be restricted, is there a recommended way to check what permissions an app is granted in real time without the need to restart for changes to take effect? How does end-user popup fatigue and complacency come to factor into your decisions to gate functionality behind TCC?

I have an ES client that tracks file activity on the system. Was I'm finding is that es_event_unlink_t events are sent when some process attempts to delete a file, but such attempts can fail, of course, due to permissions or any number of other reasons. Can you suggest ways for my client program to determine reliably whether a file was actually deleted? I suppose I could schedule a stat() or something, and assume the file was deleted if it doesn't exist (and wasn't re-created in the meantime), but it seems a bit fiddly. Am I missing anything?

For a Swift package that requires app developers to set a String API key at the app level (one key per app, not per user), what is Apple’s recommended approach for allowing those keys to be securely rotated without requiring an App Store redeploy?

I'd like to know if there is any way for an app to deep link the user to their Apple Account --> Personal Information --> Age Range for Apps screen within settings. I don't have a feedback for this (yet). The idea is simple. If a user denies sharing permission, but the app developer makes the decision to use the API to enforce their own apps terms (i.e. 16+, 18+, etc.) one would throw up a non-dismissible screen and the user is stuck. The best I have come up with is to link to Apple's support page on the Age Range for Apps feature. However, this isn't an ideal user experience and leaves a lot for the user to do. If they really want to use they can change their mind and I want to help reduce that friction. Why does this matter? From my 'non-legal' research and experimentation with this API, I have decided the easiest thing is to just check the age in all regions--use it for checking and evaluating against your apps terms of use. For example, I have a brewery app, while it won't check 21+ through the API, certainly the app is not meant to be used by minors. Aside from a few rough edges in the API, the framework is overall really well thought out. Most people I talk with about this haven't even heard of the new Apple Account setting, and the ones that think they can find it go to privacy and security in the Settings app.

Are there any plans to add Endpoint Security support for intercepting or observing listen() calls, so SIEM and EDR products can reliably monitor when processes begin accepting inbound network connections?