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"

To use passkeys, you need to place the correct AASA file on the web server and add an entry in the Entitlements.plist, for example webcredentials:mydomain.com. This is clear so far, but I would like to ask if it's possible to set this webcredentials in a different way in the app? The reason for this is that we are developing a native app and our on-premise customers have their own web servers. We cannot know these domains in advance so creating a dedicated app for each customer is not option for us. Thank you for your help!

I've contacted Apple support about this topic, and they've directed me to this forum. I regularly perform Pentests of iOS applications. To properly assess the security of iOS apps, I must bypass given security precaution taken by our customers, such as certificate pinning. According to a number of blog articles, this appears to only be viable on jailbroken devices. If a target application requires a modern version of iOS, the security assessment can't be properly performed. As it should be in Apple's best interest, to offer secure applications on the App Store, what's the recommended approach to allow intrusive pentesting of iOS apps?

Our company has a micro service which sends a notification email to an iCloud account/email and the email is going to the junk folder. As we tested, the email generated from user-field.company.com goes to the Inbox, while the email from user-dev.company.com goes to the Junk folder. Is there a way to avoid sending the emails to client's Junk folder when the email is sent from a specific company domain?

We use Jamf Blueprint to deploy the managed app and identity to the iOS device (iOS 26.3 installed). Our managed app can access the identity via let identityProvider = ManagedAppIdentitiesProvider() let identity: SecIdentity do { identity = try await identityProvider.identity(withIdentifier: "myIdentity") } catch { } However, the app extension cannot access the same identity. Our app extension is notification extension that implemented UNNotificationServiceExtension APIs. We use above code in didReceive() function to access identity that always failed. The MDM configuration payload is: "AppConfig": { "Identities": [ { "Identifier": "myIdentity", "AssetReference": "$PAYLOAD_2" } ] }, "ExtensionConfigs": { "Identifier (com.example.myapp.extension)": { "Identities": [ { "Identifier": "myIdentity", "AssetReference": "$PAYLOAD_2" } ] } }, "ManifestURL": "https://example.net/manifest.plist", "InstallBehavior": { "Install": "Required" } } Is there any problem in our MDM configuration? Or the notification extension cannot integrate with ManagedApp FM?

hello, I'm writing to seek clarification on Apple account security, particularly regarding potential risks of compromise, implemented safeguards, and residual risks with corresponding mitigation strategies. We would appreciate your insights on the following specific points: iCloud Keychain Access: Is an Apple ID login strictly required to access iCloud Keychain? We understand that a compromise of iCloud Keychain is unlikely unless a malicious actor successfully takes over the legitimate user's Apple ID. Is this understanding correct? Passkey Theft Methods and Protections: What are the conceivable methods a malicious actor might employ to steal a legitimate user's passkey, and how are these attempts protected against? Impact of Apple ID Compromise on Passkeys: If a malicious actor successfully compromises a legitimate user's Apple ID, is it accurate to assume that the legitimate user's passkeys would then synchronize to the attacker's device, potentially allowing them to log in using their own biometrics? Authorization Flow on Legitimate User's Device: Could you please detail the authorization flow that occurs on the legitimate user's device? We are particularly interested in the types of authentication involved and the conditions under which they are triggered. Detection and Additional Authentication for Unauthorized Login: How are attempts to log in to an Apple ID from an unrecognized device or browser detected, and what additional authentication steps are implemented in such scenarios? Thank you for your time and assistance in addressing these important security questions.

My app Mocawave is a music player distributed through the Mac App Store. It declares specific audio document types (public.mp3, com.microsoft.waveform-audio, public.mpeg-4-audio, public.aac-audio) in its CFBundleDocumentTypes with a Viewer role. When a user sets Mocawave as the default app for audio files and double-clicks an MP3 downloaded from the internet (which has the com.apple.quarantine extended attribute), macOS displays the alert: "Apple could not verify [filename] is free of malware that may harm your Mac or compromise your privacy." This does not happen when: Opening the same file via NSOpenPanel from within the app Opening the same file with Apple's Music.app or QuickTime Player The app is: Distributed through the Mac App Store Sandboxed (com.apple.security.app-sandbox) Uses com.apple.security.files.user-selected.read-write entitlement The file being opened is a regular audio file (MP3), not an executable. Since the app is sandboxed and distributed through the App Store, I expected it to have sufficient trust to open quarantined data files without triggering Gatekeeper warnings — similar to how Music.app and QuickTime handle them. Questions: Is there a specific entitlement or Info.plist configuration that allows a sandboxed Mac App Store app to open quarantined audio files without this alert? Is this expected behavior for third-party App Store apps, or could this indicate a misconfiguration on my end? Environment: macOS 15 (Sequoia), app built with Swift/SwiftUI, targeting macOS 13+.

Could you tell me about account security and passkeys? Our service is considering implementing passkeys, and these questions are to understand how Apple protects accounts from third parties. ① Apple website states that two-factor authentication is mandatory for newly created Apple Accounts. When did this requirement come into effect? What are the conditions for users who do not have two-factor authentication enabled? ② Apple website mentions that a verification code may be required when signing into an Apple Account from a new device or browser. Is my understanding of the situations where a verification code is requested accurate, as listed below? Are there any other situations? Completely signing out of the Apple Account on that device. Erasing the device. Needing to change the password for security reasons. ③ If a user is already using a passkey on an Apple device, and then upgrades to a new device, will additional authentication, such as entering a PIN code, be required to use the passkey on the new device?

While working with Platform SSO on macOS, I’m trying to better understand how the system handles cases where a user’s local account password becomes unsynchronized with their Identity Provider (IdP) password—for example, when the device is offline during a password change. My assumption is that macOS may store some form of persistent token during the Platform SSO user registration process (such as a certificate or similar credential), and that this token could allow the system to unlock the user’s login keychain even if the local password no longer matches the IdP password. I’m hoping to get clarification on the following: Does macOS actually use a persistent token to unlock the login keychain when the local account password is out of sync with the IdP password? If so, how is that mechanism designed to work? If such a capability exists, is it something developers can leverage to enable a true passwordless authentication experience at the login window and lock screen (i.e., avoiding the need for a local password fallback)? I’m trying to confirm what macOS officially supports so I can understand whether passwordless login is achievable using the persistent-token approach. Thanks in advance for any clarification.

I am not very well versed in this area, so I would appreciate some guidance on what should be enabled or disabled. My app is an AppKit app. I have read the documentation and watched the video, but I find it hard to understand. When I added the Enhanced Security capability in Xcode, the following options were enabled automatically: Memory Safety Enable Enhanced Security Typed Allocator Runtime Protections Enable Additional Runtime Platform Restrictions Authenticate Pointers Enable Read-only Platform Memory The following options were disabled by default: Memory Safety Enable Hardware Memory Tagging Memory Tag Pure Data Prevent Receiving Tagged Memory Enable Soft Mode for Memory Tagging Should I enable these options? Is there anything I should consider disabling?

Hi, After enabling the new Enhanced Security capability in Xcode 26, I’m seeing install failures on devices running < iOS 26. Deployment target: iOS 15.0 Capability: Enhanced Security (added via Signing & Capabilities tab) Building to iOS 18 device error - Unable to Install ...Please ensure sure that your app is signed by a valid provisioning profile. It works fine on iOS 26 devices. I’d like to confirm Apple’s intent here: Is this capability formally supported only on iOS 26 and later, and therefore incompatible with earlier OS versions? Or should older systems ignore the entitlement, meaning this behavior might be a bug?

(Xcode 26.2, iPhone 17 Pro) I can't seem to get hardware tag checks to work in an app launched without the special "Hardware Memory Tagging" diagnostics. In other words, I have been unable to reproduce the crash example at 6:40 in Apple's video "Secure your app with Memory Integrity Enforcement". When I write a heap overflow or a UAF, it is picked up perfectly provided I enable the "Hardware Memory Tagging" feature under Scheme Diagnostics. If I instead add the Enhanced Security capability with the memory-tagging related entitlements: I'm seeing distinct memory tags being assigned in pointers returned by malloc (without the capability, this is not the case) Tag mismatches are not being caught or enforced, regardless of soft mode The behaviour is the same whether I launch from Xcode without "Hardware Memory Tagging", or if I launch the app by tapping it on launchpad. In case it was related to debug builds, I also tried creating an ad hoc IPA and it didn't make any difference. I realise there's a wrinkle here that the debugger sets MallocTagAll=1, so possibly it will pick up a wider range of issues. However I would have expected that a straight UAF would be caught. For example, this test code demonstrates that tagging is active but it doesn't crash: #define PTR_TAG(p) ((unsigned)(((uintptr_t)(p) >> 56) & 0xF)) void *p1 = malloc(32); void *p2 = malloc(32); void *p3 = malloc(32); os_log(OS_LOG_DEFAULT, "p1 = %p (tag: %u)\n", p1, PTR_TAG(p1)); os_log(OS_LOG_DEFAULT, "p2 = %p (tag: %u)\n", p2, PTR_TAG(p2)); os_log(OS_LOG_DEFAULT, "p3 = %p (tag: %u)\n", p3, PTR_TAG(p3)); free(p2); void *p2_realloc = malloc(32); os_log(OS_LOG_DEFAULT, "p2 after free+malloc = %p (tag: %u)\n", p2_realloc, PTR_TAG(p2_realloc)); // Is p2_realloc the same address as p2 but different tag? os_log(OS_LOG_DEFAULT, "Same address? %s\n", ((uintptr_t)p2 & 0x00FFFFFFFFFFFFFF) == ((uintptr_t)p2_realloc & 0x00FFFFFFFFFFFFFF) ? "YES" : "NO"); // Now try to use the OLD pointer p2 os_log(OS_LOG_DEFAULT, "Attempting use-after-free via old pointer p2...\n"); volatile char c = *(volatile char *)p2; // Should this crash? os_log(OS_LOG_DEFAULT, "Read succeeded! Value: %d\n", c); Example output: p1 = 0xf00000b71019660 (tag: 15) p2 = 0x200000b711958c0 (tag: 2) p3 = 0x300000b711958e0 (tag: 3) p2 after free+malloc = 0x700000b71019680 (tag: 7) Same address? NO Attempting use-after-free via old pointer p2... Read succeeded! Value: -55 For reference, these are my entitlements. [Dict] [Key] application-identifier [Value] [String] … [Key] com.apple.developer.team-identifier [Value] [String] … [Key] com.apple.security.hardened-process [Value] [Bool] true [Key] com.apple.security.hardened-process.checked-allocations [Value] [Bool] true [Key] com.apple.security.hardened-process.checked-allocations.enable-pure-data [Value] [Bool] true [Key] com.apple.security.hardened-process.dyld-ro [Value] [Bool] true [Key] com.apple.security.hardened-process.enhanced-security-version [Value] [Int] 1 [Key] com.apple.security.hardened-process.hardened-heap [Value] [Bool] true [Key] com.apple.security.hardened-process.platform-restrictions [Value] [Int] 2 [Key] get-task-allow [Value] [Bool] true What do I need to do to make Memory Integrity Enforcement do something outside the debugger?

QuickLookAR shares the actual USDZ model instead of the original website URL — critical copyright and data leak issue on iOS 26 Since iOS 26, QuickLookAR (or ARQuickLookPreviewItem) no longer preserves the original web URL when sharing a model. Instead of sending the link to the hosted file, the system directly shares the actual USDZ model file with the recipient. This is a critical regression and a severe breach of intellectual property protection, as it exposes proprietary 3D models that must never be distributed outside of the controlled web environment. In earlier iOS versions (tested up to iOS 18), QuickLookAR correctly handled sharing — the share sheet would send the website link where the model is hosted, not the file itself. Starting with iOS 26, this behavior has changed and completely breaks the intended secure flow for AR experiences. Our project relies on allowing users to view models in AR via QuickLook, without ever transferring the underlying 3D assets. Now, the share operation forces full file sharing, giving end users unrestricted access to the model file, which can be copied, rehosted, or reverse-engineered. This issue critically affects production environments and prevents us from deploying our AR-based solutions. Implement a standard QuickLookAR preview with a USDZ file hosted on your web server (e.g., via ARQuickLookPreviewItem). 2. Open the AR view on iOS 26. 3. Tap the Share icon from QuickLookAR. 4. Send via any messenger (Telegram, WhatsApp, etc.). 5. Observe that the actual .usdz model is sent instead of the original website URL. ⸻ Expected behavior: QuickLookAR should share only the original URL (as in iOS 17–18), not the file itself. This ensures that intellectual property and licensed 3D models remain protected and controlled by the content owner. ⸻ Actual behavior: QuickLookAR shares the entire USDZ file, leaking the model content outside of the intended environment. ⸻ Impact: • Violation of copyright and confidential data policies • Loss of control over proprietary 3D assets • Breaking change for all existing web-based AR integrations • Critical blocker for AR production deployment ⸻ Environment: • iOS 26.0 and 26.1 (tested on iPhone 14, iPhone 15) • Safari + QuickLookAR integration • Works correctly on iOS 17 / iOS 18 ⸻ Notes: This regression appears to have been introduced in the latest iOS 26 system handling of QuickLookAR sharing. Please escalate this issue to the ARKit / QuickLook engineering team as it directly affects compliance, IP protection, and usability of AR features across production applications. Additional Notes / Verification: Please test this behavior yourself using the CheckAR test model on my website: https://admixreality.com/ios26/ • If the login page appears, click “Check AR” and then “View in Your Space”. • On iOS 18 and earlier, sharing correctly sends the website URL. • On iOS 26, sharing sends the actual USDZ model file. This clearly demonstrates the regression and the security/IP issue.

I am trying to integrate those into my app, stuck on it would not transfer to view that inside app, can someone help? Scott

Hello, we are using DeviceCheck – App Attest in a production iOS app. The integration has been live for some time and works correctly for most users, but a small subset of users encounter non-deterministic failures that we are unable to reproduce internally. Environment iOS 14+ Real devices only (no simulator) App Attest capability enabled Correct App ID, Team ID and App Attest entitlement Production environment Relevant code let service = DCAppAttestService.shared service.generateKey { keyId, error in // key generation } service.attestKey(keyId, clientDataHash: hash) { attestation, error in // ERROR: com.apple.devicecheck.error 3 / 4 } service.generateAssertion(keyId, clientDataHash: clientDataHash) { assertion, error in // ERROR: com.apple.devicecheck.error 3 / 4 } For some users we intermittently receive: com.apple.devicecheck.error error 3 com.apple.devicecheck.error error 4 Characteristics: appears random affects only some users/devices sometimes resolves after time or reinstall not reproducible on our test devices NSError contains no additional diagnostic info Some questions: What is the official meaning of App Attest errors 3 and 4? Are these errors related to key state, device conditions, throttling, or transient App Attest service issues? Is there any recommended way to debug or gain more insight when this happens in production? Any guidance would be greatly appreciated, as this impacts real users and is difficult to diagnose. Thank you.

Our Goal: We are implementing a workflow for derived credentials. Our objective is to have a PIV/CAC derived credential (from Entrust), installed via the Intune MDM Company Portal app, and then use it within our (managed) app to generate digital signatures. Challenge: The Intune Company Portal installs these identities into the System Keychain. Because third-party apps are restricted from accessing private keys in the System Keychain, we are running into a roadblock. Our Question: 1) Is there an API that allows us to create a signature without us having to pass the private key itself, but instead just pass a handle/some reference to the private key and then the API can access the private key in the system keychain and create the signature under the hood. SecKeyCreateSignature is the API method that creates a signature but requires passing a private key. 2) If #1 is not feasible, is there a way to get access to system keychain to retrieve certs + private key for managed apps

I'm building a macOS app that registers itself for HTTP(S) url handling and would like it to participate in the ASWebAuthenticationSession fow. I did: update the plist to register as a handler for URL shemes (http, https, file) use NSWorkspace setDefaultApplication API to set this app as a default handler for urls in question wrote custom ASWebAuthenticationSessionWebBrowserSessionHandling implementation and set it as SessionManager's sessionHandler I launched this app from Xcode, then I triggered authentication flow from a third-party app. When the sign in flow is initiated, I can see that my app is activeated (willBecomeActive and didBecomeActive callbacks are both called), but there is no call for sessionHandler's begin() method. With some additional debugging I see that my app receives an apple event when the flow is started: {sfri,auth target=SafariLaunchAgent {qntp=90/$627......},aapd=TRUE If I switch system default browser back to Safari and then start the login flow, it correctly displays a sign in web page. What do I miss? PS. I'm on Tahoe 26.2

Hi, I’m seeing a production issue on iOS 26+ that only affects some users. symptoms: It does NOT happen for all users. It happens for a subset of users on iOS 26+. If we write a value to Keychain and read it immediately in the same session, it succeeds. However, after terminating the app and relaunching, the value appears to be gone: SecItemCopyMatching returns errSecItemNotFound (-25300). Repro (as observed on affected devices): Launch app (iOS 26+). Save PIN data to Keychain using SecItemAdd (GenericPassword). Immediately read it using SecItemCopyMatching -> success. Terminate the app (swipe up / kill). Relaunch the app and read again using the same service -> returns -25300. Expected: The Keychain item should persist across app relaunch and remain readable (while the device is unlocked). Actual: After app relaunch, SecItemCopyMatching returns errSecItemNotFound (-25300) as if the item does not exist. Implementation details (ObjC): We store a “PIN” item like this (simplified): addItem: kSecClass: kSecClassGenericPassword kSecAttrService: <FIXED_STRING> kSecValueData: kSecAttrAccessControl: SecAccessControlCreateWithFlags(..., kSecAttrAccessibleWhenUnlockedThisDeviceOnly, 0, ...) readItem (SecItemCopyMatching): kSecClass: kSecClassGenericPassword kSecAttrService: <FIXED_STRING> kSecReturnData: YES (uses kSecUseOperationPrompt in our async method) Question: On iOS 26+, is there any known issue or new behavior where a successfully added GenericPassword item could later return errSecItemNotFound after app termination/relaunch for only some users/devices? What should we check to distinguish: OS behavior change/bug vs. entitlement/access-group differences (app vs extension, provisioning/team changes), device state/policies (MDM, passcode/biometrics changes), query attributes we should include to make the item stable across relaunch? Build / Dev Environment: macOS: 15.6.1 (24G90) Xcode: 26.2

[Q] When is the kTCCServiceEndpointSecurityClient set by macOS and in which conditions? From what I'm gathering, the kTCCServiceEndpointSecurityClient can not be set by a configuration profile and the end user can only grant full disk access. I searched for documentation on Apple's develop website (with the "kTCCServiceEndpointSecurityClient" search) and did not get any useful result. Using a more complete search engine, or the forum search engine, only points to the old annoying big bug in macOS Ventura. The problem I'm investigating is showing a process being listed as getting granted kTCCServiceEndpointSecurityClient permissions in the TCC database when: it's not an Endpoint Security client. it does not have the ES Client entitlement. the bundle of the process includes another process that is an ES Client and is spawn-ed by this process but I don't see why this should have an impact. This process is supposed to have been granted kTCCServiceSystemPolicyAllFiles via end user interaction or configuration profile. AFAIK, the kTCCServiceEndpointSecurityClient permission can only be set by macOS itself. So this looks like to be either a bug in macOS, an undocumented behavior or I'm missing something. Hence the initial question. macOS 15.7.3 / Apple Silicon

We are using SecItemCopyMatching from LocalAuthentication to access the private key to sign a challenge in our native iOS app twice in a few seconds from user interactions. This was working as expected up until about a week ago where we started getting reports of it hanging on the biometrics screen (see screenshot below). From our investigation we've found the following: It impacts newer iPhones using iOS 26.1 and later. We have replicated on these devices: iPhone 17 Pro max iPhone 16 Pro iPhone 15 Pro max iPhone 15 Only reproducible if the app tries to access the private key twice in quick succession after granting access to face ID. Looks like a race condition between the biometrics permission prompt and Keychain private key access We were able to make it work by waiting 10 seconds between private key actions, but this is terrible UX. We tried adding adding retries over the span of 10 seconds which fixed it on some devices, but not all. We checked the release notes for iOS 26.1, but there is nothing related to this. Screenshot:

Apple has repeatedly ignored my reports about a critical privacy issue in Spotlight on macOS 26, and the problem persists in version 26.3 RC. This is not a minor glitch, it is a fundamental breach of user trust and privacy. Several aspects of Spotlight fail to respect user settings: • Hidden apps still exposed: In the Apps section (Cmd+1), Spotlight continues to display apps marked with the hidden flag, even though they should remain invisible. • Clipboard reactivation: The clipboard feature repeatedly turns itself back on after logout or restart, despite being explicitly disabled by the user. • Excluded files revealed: Most concerning, Spotlight exposes files in Suggestions and Recents (Cmd+3) even when those files are explicitly excluded under System Settings > Spotlight > Search Privacy. This behavior directly violates user expectations and system settings. It is not only a major privacy issue but also a security risk, since sensitive files can be surfaced without consent. Apple must address this immediately. Users rely on Spotlight to respect their privacy configurations, and the current behavior undermines both trust and security.