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"

Hi, I'm very interested in bringing TrustInsights to our mobile banking app but I'm unable to get it working in Xcode 27 beta 1 and 2. When adding an import I get "Unable to resolve module dependency: 'TrustInsights'" and I don't see TrustInsights in the list of Capabilities to add in the settings of the target. best regards Stefan

We have a custom SecurityAgentPlugin that is triggered by multiple authorizationdb entries. Some customers report that the SecurityAgent process takes window focus even though no UI or windows are displayed. Our plugin explicitly ignores the _securityAgent user and does not show any UI for that user. However, in macOS 26.1, it appears that the plugin still causes the SecurityAgent to take focus as soon as it is triggered. Is this a change in macOS 26.1 or a bug? Can we do anything to prevent "focus stealing"?

Environment: MacBook Pro 14-inch Nov 2023 (Apple Silicon M3) macOS 26.5 (25F71) and 26.5.1 (25F80) MDM: Kandji/Iru enrolled BeyondTrust EPM-M 26.1.1495 Confirmed chain via epsext exec logs: The Kandji/Iru Parameter Agent (kandji-parameter-agent) calls /usr/sbin/systemsetup -getusingnetworktime every 15 minutes. Each invocation requests the system.preferences authorization right, waking authd → writeconfig.xpc → SecurityAgent. SecurityAgent then opens a SkyLight connection, calls SetFrontProcess, causes the active window to resign key appearance, and closes — all within 3–15 seconds. Cross-referenced against user-reported times: User reported focus steal at 10:13, 10:58, 11:13, 11:43 (CDT). SecurityAgent fired at exactly those times to the second in our WindowServer logs. Key finding: The systemsetup call itself is not the root issue — it's doing its job. The problem is that on macOS 26 Tahoe, this auth request causes SecurityAgent to grab keyboard focus as a side effect, which it should not do for a background/silent authorization check with no user interaction required. BeyondTrust KB0023327 documents the PMCAdapter event as a separate but related trigger. Both are symptoms of the same underlying SecurityAgent behaviour change in macOS 26.

I’m seeing a regression in macOS 27 beta when using SwiftUI LocalAuthenticationView. When an LAContext is attached to LocalAuthenticationView, subsequent policy evaluation fails immediately with: Error Domain=com.apple.LocalAuthentication Code=-1007 NSDebugDescription="Caller is not Apple signed." NSLocalizedDescription="Authentication denied." The same policies work when evaluated on a plain LAContext that has not been attached to LocalAuthenticationView. Minimal shape of the failing path: @State private var context = LAContext() LocalAuthenticationView(context: context) { EmptyView() } context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: "Unlock") { success, error in print(success, error as Any) } This affects Touch ID unlock in our macOS app. We currently work around it by detecting LAErrorDomain / -1007, removing LocalAuthenticationView, and asking the user to manually start Touch ID with a fresh LAContext. Filed as Feedback: FB23262713 Could someone from the beta / LocalAuthentication team confirm whether this is an intended restriction for LocalAuthenticationView, or a macOS 27 beta regression?

When I install a new version in /Library/Security/SecurityAgentPlugins, the Mac keeps loading from the StagedPlugins folder. Probably due to the previous version crashing at some point.

Hi everyone, was hoping I could get some help. Recently I've been trying to implement passkeys on my app and one of the use cases was that we don't allow users to create duplicated passkeys from the same device they are on. I passed the excludedCredentials into the registration and tried creating a passkey twice, on the 2nd time I am unable to create a passkey but instead of triggering the .matchedExcludedCredentials from the ASAuthorizationError like I hoped, I get a WKErrorDomain code 8 with the localized description At least one credential matches an entry of the excludeCredentials list in the platform attached authenticator. Been debugging but I still couldn't find the answer as to why the AS error is not triggered.

Hello, We searched Apple documentation and found no official guidance on Arcade‑specific tracking rules. Enforcement seems implicit via App Tracking Transparency (ATT) and App Review, so we want to confirm whether Arcade builds must be treated as stricter than, or the same as, normal App Store builds. Specifically: Are ATT prompts and IDFA usage completely disallowed in Arcade builds? Are third‑party analytics SDKs (e.g., Firebase, Adjust, GameAnalytics) permitted in Arcade? Is crash reporting limited to Apple‑approved frameworks only? Should all tracking/telemetry be restricted to gameplay and iCloud sync only? We plan to adjust our entitlement logic and QA requirements accordingly, so an official clarification would be very helpful. Thank you, Phong

I am developing a macOS system service (standalone binary running as a LaunchDaemon) that requires the ability to sign data using a private key which will be deployed via MDM. The Setup: Deployment: A .mobileconfig pushes a PKCS12 identity to the System Keychain. Security Requirement: For compliance and security reasons, we cannot set AllowAllAppsAccess to <true/>. The key must remain restricted. The Goal: I need to use the private key from the identity to be able to sign the data The Problem: The Certificate Payload does not support a TrustedApplications or AccessControl array to pre-authorize binary paths. As a result, when the process tries to use the private key for signing (SecKeyCreateSignature), it prompts the user to allow this operation which creates a disruption and is not desired. What i've tried so far: Manually adding my process to the key's ACL in keychain access obviously works and prevents any prompts but this is not an "automatable" solution. Using security tool in a script to attempt to modify the ACL in an automated way, but that also asks user for password and is not seamless. The Question: Is there a documented, MDM-compatible way to inject a specific binary path into the ACL of a private key? If not, is there a better way to achieve the end goal?

My app runs as expected when debugging, trigging the MacOS to ask the user for permission to use the microphone. The notarized version of the app does not have the MacOS asking for user permission but the app gets the message 'User rejected permission'. I'm seeing this after upgrading to 26.5.1 and so is one of my users. What changed in getting microphone permission?

https://support.apple.com/en-us/126655 As stated in the “Prepare your network environment for stricter security requirements.” my understanding is that additional security requirements will be introduced from OS 27 onward and that we need to prepare for them. However, I understand that the content on this page is mainly about distributing apps and operating the app itself. For example, I believe that simply accessing a web page within the app, or conducting HTTP communications with servers unaffiliated with Apple, will remain possible as before. Is my understanding correct?

Hello Apple Developer Support, We are using ILMessageFilterExtension with the IdentityLookup framework to classify carrier messages. We have already verified that the Message Filter extension is invoked for RCS messages. Our remaining question is specifically about end-to-end encrypted RCS messages on iOS 26.5. Could Apple please clarify the expected behavior for RCS E2EE messages? When an RCS conversation is end-to-end encrypted, is ILMessageFilterExtension expected to receive an ILMessageFilterQueryRequest callback? If the extension is invoked for RCS E2EE, does ILMessageFilterQueryRequest.messageBody contain the decrypted message body locally on device? If the extension is not invoked for RCS E2EE, is this expected behavior because the message content is end-to-end encrypted? Is the behavior different based on carrier, region, or RCS encryption availability? Is there any public Apple documentation that explicitly describes IdentityLookup / Message Filter behavior for RCS E2EE messages? Environment: iOS version: 26.5 Framework: IdentityLookup Extension: ILMessageFilterExtension API: ILMessageFilterQueryHandling.handle(_:context:completion:) Confirmed behavior: Message Filter extension is invoked for RCS messages Question: Whether the same behavior applies to end-to-end encrypted RCS messages We need this clarification to finalize expected product behavior and test coverage for RCS E2EE message filtering.

Hi, we are looking for a solution to install an extension to Microsoft PowerPoint app in a way that's compatible with the new macOS 15 behavior for Group Containers content. PowerPoint extensions Microsoft PowerPoint can be extended by PowerPoint Add-in (.ppam) files. These files must be installed in the app's container at this location: ~/Library/Group Containers/UBF8T346G9.Office/User Content.localized/Add-Ins.localized/ The PPAM file must be also registered in the MicrosoftRegistrationDB.reg file which is a sqlite database stored at this location: ~/Library/Group Containers/UBF8T346G9.Office/MicrosoftRegistrationDB.reg These locations can be access by non-sandboxed app on macOS 14 and earlier. Slido integration Our Slido app for macOS is distributed outside the Mac App Store, it is not sandboxed and it signed and notarized. The Slido app will install the PPAM file to the documented location and register it in the database. This installation did not require additional user approval on macOS 14 and older. With changes to macOS 15, a new permissions dialog is shown with this text: "Slido" would like to access data from other apps. This will allow Slido to integrate with Microsoft PowerPoint app. [Don't Allow] [Allow] We understand this is a security feature, yet we would like to make the experience for customers much better. As users are able to save PPAM files to the location by themselves without additional permissions, they expect the Slido app would be able to do so as well when run in the user context. Slido installs its files to this location: ~/Library/Group Containers/UBF8T346G9.Office/User Content.localized/Add-Ins.localized/SlidoAddin.localized/ Can we obtain com.apple.security.temporary-exception.files.home-relative-path.read-write to the SlidoAddin.localized folder? Even when we are different TeamID? Can we obtain a user permission which will be persisted so next time the Slido app can verify its files and uninstall them without further prompts? By having access to the SlidoAddin.localized folder our app would not be able to access any other data in Microsoft PowerPoint. We understand accessing the MicrosoftRegistrationDB.reg file is more sensitive and getting exception to access it would not be feasible. But we are trying to find out our options to make the experience seamless as that's what is expected by our customers on Apple platform. I am thankfully for any guidance and constructive feedback. Jozef, Tech Leader at Slido integrations team

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.

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?