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"

We have a macOS application that adds entries to the Authorization Database (system.login.console) as part of its setup. We observed that after upgrading from macOS Tahoe to the macOS Golden Gate beta, the entries added by our application were removed, and the default system.login.console configuration was restored. Is this expected behavior in the current Golden Gate beta, or is it a known issue? If it is a known issue, is there an expectation that it will be addressed in a future beta release? Additionally, is there any recommended approach for preserving or restoring application-specific Authorization Database entries across major macOS upgrades? It would be of great help if there is any suggested approach for the same.

We have a macOS Authorization Plugin that reads and writes data from login.keychain-db during the login flow (logout→login scenario). On macOS 26.6, SecKeychainUnlock consistently fails in the pre-session context — before the user session is established. Error returned: Error Domain=NSOSStatusErrorDomain Code=-25293 "errSecAuthFailed: The username or passphrase you entered is not correct." However, the error message is misleading. We tested four combinations on macOS 26.6 to isolate the exact cause: Active session + correct password → Success Active session + wrong password → -25293 Pre-session + correct password → -25293 Pre-session + wrong password → -25293 In the pre-session context, macOS 26.6 returns -25293 for both correct and wrong passwords identically. This strongly suggests macOS is not evaluating the password at all in that context — the failure happens before password validation, likely because the session-bound material required to unlock login.keychain-db does not exist yet when the auth plugin runs. Key observations: The same code works correctly on macOS 26.3.1 and 26.5.1 — SecKeychainUnlock succeeds with the correct password in the pre-session context on those versions. The issue is specific to macOS 26.6. The file path /Users//Library/Keychains/login.keychain-db is unchanged — we get -25293 (auth failed), not -25294 (no such keychain), confirming the file is found and opened correctly. SecKeychainUnlock(ref, 0, NULL, NO) also fails for login.keychain-db in both pre-session and active session contexts. System.keychain with SecKeychainUnlock(ref, 0, NULL, NO) continues to work correctly in the pre-session context on macOS 26.6. Questions: Has the protection model for login.keychain-db changed in macOS 26.6 such that it can no longer be unlocked viaSecKeychainUnlock in a pre-session authorization plugin context? Is this an intentional security hardening change, or a regression? Is there a supported API or entitlement for authorization plugins to access login.keychain-db before the user session is established? Does the modern Data Protection Keychain (SecItemCopyMatching/SecItemAdd with kSecUseDataProtectionKeychain: @YES) work correctly in the authorization plugin pre-session context on macOS 26.6? If yes, is migrating to that API the recommended approach? Note: We are aware that SecKeychainUnlock is deprecated. We are actively evaluating migration to the modern Data Protection Keychain API, but understanding whether this is an intentional change, would help us choose the right fix approach.

I am planning an app transfer between two developer teams, iOS only, no macOS app. The app shares an app group with a notification service extension and a share extension. The container holds a SQLite database, message attachments and user avatars. The database encryption key is in the keychain. I have read thread https://developer.apple.com/forums/thread/706128 (including the 2026-03-31 revision), and the plan is to follow it: a pre-transfer release moving keychain items into the AGI keychain access group, time for adoption, then the app transfer, then the app group transfer. I've also read https://developer.apple.com/forums/thread/774831, https://developer.apple.com/forums/thread/782132 and https://developer.apple.com/forums/thread/815779. My questions are about the container rather than the keychain: Step 7 of 706128 says that when a user installs the post-transfer version, "it will have access to your app group, and hence your keychain items". Does that access include the files already in the app group container, written while the app was signed by the old team? Or does the transfer restore only AGI keychain access group membership, leaving the container's prior contents inaccessible? If those files are not preserved, is there a supported way to migrate them, or should I relocate that data into the app's own container before the transfer? Thread 815779 asked this and I do not think it was answered. While the app group transfer is in progress, do already installed builds signed by the old team, which the user has not updated, keep working against the original container? App Store Connect Help (Transfer an app > Overview of app transfer > Apps using App Groups) says the app group "can be deleted from the transferor's account and registered to the recipient's account". Is that the same operation as step 5 of 706128, "transfer the app group ID", or two different things? I ask because the developer in thread 774831, who lost shared container data for roughly 25% of users, deleted and recreated the group during the transfer, whereas 706128 step 5 says to do it once the app transfer is complete.

Sign in with Apple fails for every App ID in our team (K9UFUZF2XW), on every device and every Apple ID we have tried. The system sheet appears, the user authenticates successfully, the sheet then shows "Sign Up Not Completed", and no credential is returned. The failure happens after authentication — this is not a client-side rejection. I have spent several days isolating this and have ruled out everything on my side. Posting the full evidence in case an Apple engineer can look at the server-side state for our team, and in case it helps others hitting the same wall. WHAT THE FRAMEWORK ACTUALLY RETURNS The client library we use (expo-apple-authentication) discards the original NSError, so I patched its native layer to surface the raw error verbatim. This is what ASAuthorizationController hands back to didCompleteWithError, immediately after the user authenticated and the sheet displayed "Sign Up Not Completed": ASAuthorizationError .canceled (rawValue = 1001) domain = com.apple.AuthenticationServices.AuthorizationError code = 1001 desc = The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError, error 1001) userInfo: NSUnderlyingError: So the framework reports a user cancellation that never happened, with a completely empty userInfo and no underlying error. There is no diagnostic information on the client at all — I cannot debug this any further from my side, because the information does not exist there. Note: the same failure surfaces as a different error code depending on the client library version — .unknown (1000) with the older version, .canceled (1001) with the current one. The user-visible behaviour ("Sign Up Not Completed") is identical in both. So the error code is not a reliable signal here. WHAT I RULED OUT Not the App ID. I created a brand-new App ID (kz.auraai.ios) with Sign in with Apple enabled as a primary App ID, built a fresh binary, tested on the same device with the same Apple ID — identical failure. Two independent App IDs in the same team fail the same way. Not the entitlement. Verified inside the signed binary, not just in the portal: application-identifier = K9UFUZF2XW.kz.auraai.ios com.apple.developer.applesignin = ["Default"] I also tried the workaround suggested elsewhere on these forums (removing the entitlement while keeping the capability in the portal). That made it strictly worse: iOS then rejects the request instantly, without showing the sheet at all. Which confirms iOS reads the entitlement correctly, the sheet works, and the user authenticates — the failure is downstream of all of that. No stray or wildcard App IDs. A commonly cited cause is other App IDs in the team lacking the entitlement. I enumerated the whole team via the App Store Connect API: it contains exactly two App IDs, both with APPLE_ID_AUTH = PRIMARY_APP_CONSENT. No wildcard identifiers exist. Not the Apple ID, the device, or the iOS version. The same Apple ID, on the same device, with the same iOS, signs in successfully through another app belonging to a different team (Expo Go, host.exp.Exponent) — a valid identity token is returned. A second, unrelated Apple ID on another device fails in my app in exactly the same way. So this is not scoped to one account: it affects every user of the app. Agreements and membership are in good standing. Program License Agreement accepted 30 June 2026; Developer Agreement accepted 26 June 2026; membership active. Both distribution types fail. TestFlight and ad-hoc. WHAT IS LEFT After all of the above, the only variable that differs between the working case (a different team's app, same device, same Apple ID) and the failing case (my app) is the Apple Developer team itself. This exact signature — sheet renders fully, final server submit fails, "Sign Up Not Completed", delegate reports canceled with no userInfo, not reproducible in other apps on the same device — is documented in thread 122458 ("Error: Sign-Up Not Completed"). In that case it affected multiple developers, including Apple's own sample app, and was ultimately resolved by Apple on the server side, with a recurrence reported in June 2025. THE ASK Could someone from Apple check the server-side Sign in with Apple registration for team K9UFUZF2XW (App IDs kz.auraai.app and kz.auraai.ios)? I am not looking for configuration advice — I have exhausted the client side and there is nothing left to configure. This looks like the same server-side state that was fixed in the referenced cases. Feedback Assistant: FB23716661 (includes sysdiagnose with the Accounts/AuthKit profile, timestamp, and video of the failure). This is currently blocking us: because Sign in with Apple works for none of our users, guideline 4.8 prevents us from offering Google Sign-In, so we are shipping with email-only login. Happy to provide the binary, entitlements dump, or a fresh sysdiagnose on request.

Our app's Sign in with Apple never completes. Apple's create-account sheet renders fully (name + share/hide-my-email step), then the final server submit fails and shows the "Sign Up Not Completed" sheet. The authorization callback returns ASAuthorizationError.canceled (1001) with no userInfo — even though the user did not cancel. Reproduced on multiple physical devices and multiple Apple IDs (all with 2FA), on iOS 26.5.1, since our first build. Team ID: 24XS837728 App ID: C54N9Q226H (bundle com.sucsessmaperrs.careerAssessmentApp) Verified on our side: com.apple.developer.applesignin = [Default] present in the distribution build (codesign -d --entitlements); embedded profile is the explicit App Store profile for the App ID (not wildcard). App ID has Sign in with Apple enabled as a primary App ID; capability deleted + recreated via the App Store Connect API today, no change. Firebase consumes the identity token; the failure is in Apple's UI before our code runs. App Store Connect agreements are clean. Key isolating fact: the same Apple ID on the same device completes a first-time Sign in with Apple sign-up in other third-party apps — only ours fails. So the cause appears scoped to our App ID / team on Apple's side, not the device, the Apple ID, 2FA, or our client code. This matches the widespread server-side "Sign Up Not Completed" failure in thread 675756 — same signature: multiple devices/Apple IDs, no console error, the failure delegate surfacing only as "cancel", newly created apps affected, even Apple's own sample app failing — which Apple ultimately resolved server-side (with a recurrence reported June 2025). Note this is the native ASAuthorizationController flow, not the REST/web flow, so the query-parameter percent-encoding fix from thread 122458 does not apply here. Could an Apple engineer check the server-side Sign in with Apple / account-association state for App ID C54N9Q226H (Team 24XS837728)? Happy to provide a screen recording or sysdiagnose.

Product area macOS / Privacy & Security / ScreenCaptureKit / Core Graphics Environment macOS 27 Beta 4 (build: fill in your exact build number, e.g. 27A5xxx) Xcode 26.5 / SDK 260500 (adjust to match what you actually built with) App holds the com.apple.developer.persistent-content-capture entitlement (approved via Apple's request form), targeting macOS 14.4+ Summary Our app is a remote-support/remote-control tool (screen viewing + control), comparable to VNC-style products. On macOS 27, we've found that System Settings > Privacy & Security now shows a "Remote Desktop" entry that is distinct from "Screen & System Audio Recording" — granting one does not affect the other. We need a way to check, at any time, whether our app currently has "Remote Desktop" authorization, without causing the system to show a permission-request alert as a side effect. We have not found a documented, public API that does this. What we've tried CGPreflightScreenCaptureAccess() Confirmed via a controlled test on-device: granting only "Remote Desktop" leaves this API returning false; granting only "Screen & System Audio Recording" makes it return true. So this API appears to reflect kTCCServiceScreenCapture only, and does not reflect the "Remote Desktop" permission at all. ScreenCaptureKit (SCShareableContent, e.g. via a refreshAvailableContentWithCompletionHandler:-style call) This call does appear to interact with the "Remote Desktop" permission — but calling it triggers a real system consent alert every time we call it, even when we only intend to read the current status, not request it. This makes it unusable for passive/background status polling (e.g. to decide what to show in our own onboarding UI without surprising the user with an OS-level prompt). We are intentionally not reading /Library/Application Support/com.apple.TCC/TCC.db directly — we understand this is a private, undocumented database and want a supported API instead. Sample code illustrating both attempts // Attempt 1: CGPreflightScreenCaptureAccess — does not reflect Remote Desktop grant BOOL preflightResult = CGPreflightScreenCaptureAccess(); // preflightResult stays NO even after the user grants "Remote Desktop" in // System Settings > Privacy & Security > Remote Desktop. // It correctly flips to YES only when "Screen & System Audio Recording" is granted. // Attempt 2: ScreenCaptureKit-based check — reflects it, but prompts every time SCShareableContent... // (via our wrapper) refreshAvailableContentWithCompletionHandler: // This call appears to influence/query the Remote Desktop TCC entry, but the OS // shows a permission alert as a side effect of the call itself, even when we only // want to read the current authorization state. Question Is there a public, documented API equivalent to CGPreflightScreenCaptureAccess() — i.e., a read-only, non-prompting status check — for the new "Remote Desktop" privacy category introduced around macOS 26/27? Is com.apple.developer.persistent-content-capture actually the entitlement that governs this new "Remote Desktop" category, or is it unrelated? Apple's own documentation describes this entitlement purely in terms of "persistent access to screen capture" for VNC apps, with no mention of a distinct "Remote Desktop" permission surface — we'd like to confirm whether that description is still accurate on macOS 26/27, or whether the underlying TCC service (kTCCServiceRemoteDesktop, which we found via TCC.db schema inspection only, not public docs) has been intentionally split out. If no such API exists yet, is this planned, and is there a recommended interim approach for apps that need to know this state before deciding whether to show their own onboarding/permission UI?

We urgently need a response from the relevant authorities

Hello! I develop a voicemail app service and I use MMI codes to let users enable/disable call forwarding to their voicemail number. For example, the app opens the Phone app with a code such as: **21*<phone number># This is expected behavior and is required for the service to work. However on iOS 27, those links are now blocked with a “Malicious link blocked” warning, saying that the link may forward incoming calls/messages. Is there any supported way for apps with a legitimate use case like this to request an exemption, or otherwise avoid this warning?

It appears that we are able to read the currently logged-in Platform SSO user by reading the AltSecurityIdentities field in the dscl repository for the user. However, that seems to be something that could easily be spoofed by just having an external process write a new AltSecurityIdentities value. It also feels "hacky" to just read that value directly from the dscl repository for this purpose. Our application would like to read the user that is logged in to Platform SSO so we can report it up to our security service as the "device logged in user". Is there an API-based approach to retrieving the true user that is logged in via Platform SSO from within the context of my application?

Issue Summary We are seeing consistently high latency when calling DCAppAttestService.shared.attestKey(_:clientDataHash:). The call routinely takes 4–5 seconds in the development environment and 7–8 seconds in production. In contrast, other DeviceCheck operations execute very quickly on the same setup (e.g., DCDevice.generateToken takes ~100ms, and generateAssertion takes ~80ms). Environment Details Platform: iOS (reproduced on physical devices) Framework: DeviceCheck / App Attest Entitlements: com.apple.developer.devicecheck.appattest-environment set appropriately for each environment (development / production) Execution Flow: generateKey (or keychain lookup) $\rightarrow$ attestKey $\rightarrow$ generateAssertion Representative Timings (Development / Physical Device) ensureKey (keychain reuse): 5 ms generateDeviceToken: 91 ms attestKey (Apple API execution): 5,196 ms generateAssertion: 76 ms Total Wall Time: ~5,505 ms Steps to Reproduce On a physical iPhone, invoke DCAppAttestService.shared.generateKey() (or retrieve an existing keyId). Generate a client challenge hash (SHA256). Invoke attestKey(_:clientDataHash:completionHandler:) with the keyId and hash. Observe the multi-second delay before the completion handler returns the attestation statement. Questions & Guidance Requested Expected Baseline: Is 4–8 seconds for a successful attestKey call considered expected behavior for Apple’s attestation servers, or does this indicate an anomaly? Environment & Regional Latency: Are there known factors (e.g., server geographic routing, network handshakes, or environment differences) that cause attestKey to be noticeably slower in production compared to development? Mitigation / Best Practices: Since attestation is recommended once per key/device lifecycle upon key generation, are there specific architectural patterns Apple recommends to avoid blocking UI or onboarding flows during this high-latency step? Note: We can supply full sysdiagnose logs, device model/iOS version breakdowns, and code snippets if required.

Hi everyone! We recently integrated "Sign in with Apple" into our application using standard social login flows. For the vast majority of our users, the integration works perfectly—we receive the user's email during sign-in and sign-up. However, we are noticing an edge case where a small subset of users are returning an ID token that is completely missing the email. We can't seem to reproduce this error ourselves during testing. Every time we test a sign-up or sign-in, the email payload is included exactly as expected. My Questions: Is there a specific reason why Apple would omit the email claim from the ID token? Any insights or guidance would be greatly appreciated. Thank you!

We have observed significant UI changes to the SFUnlock login experience in the latest macOS Golden Gate Beta. After entering the account password at the SFUnlock screen,user has to click on Use Password button once and then click on the OK button to proceed to the desktop and for the login process to continue successfully. This behaviour is consistently reproducible in our testing. We would like to understand: 1.Is this a known issue with the current macOS Golden Gate Beta? 2.Is this expected behaviour due to the UI redesign, or is it considered a bug? 3.If it is a known issue, is there a fix planned for an upcoming beta or the final release? Any information or guidance would be appreciated. Thank you.

Hi, Feedback ID - FB24176019 I am investigating a Sign in with Apple issue affecting my production application and would appreciate guidance on what Apple may be rejecting during the token exchange. The authorization stage succeeds and Apple returns an authorization code to our callback. The failure occurs when the authorization code is exchanged at: https://appleid.apple.com/auth/token The production OAuth implementation uses Better Auth 1.6.13. Apple configuration: Primary App ID / Bundle ID: com.whatsupplier.uk Services ID / client_id: com.whatsupplier.uk.signin Registered return URL: https://www.whatsupp.uk/api/auth/callback/apple We have checked the client secret JWT and confirmed: alg = ES256 kid matches the active Apple key iss matches our Apple Team ID sub = com.whatsupplier.uk.signin aud = https://appleid.apple.com iat/exp are valid the JWT signature verifies locally against the configured Apple private key the signature is P1363/raw r||s rather than ASN.1 DER the private key is EC / prime256v1 the redirect_uri exactly matches the registered return URL the token request uses application/x-www-form-urlencoded The unusual behaviour is reproducible: The real Better Auth token exchange reaches Apple's /auth/token endpoint but Apple responds: HTTP 400 error: invalid_client We created a diagnostic request directly to the same Apple token endpoint using the same configured credentials and a deliberately invalid authorization code. Apple responds: HTTP 400 error: invalid_grant "The code has expired or has been revoked." This indicates Apple accepts the client credentials/JWT in the direct request and proceeds as far as validating the authorization code. We also performed an A/B test using the exact same generated client-secret JWT: Test A: grant_type code redirect_uri client_id client_secret Result: invalid_grant Test B: grant_type code redirect_uri client_id client_secret code_verifier Result: invalid_grant Therefore code_verifier alone does not change Apple's classification. We then captured the observable shape of the real Better Auth token request and compared it with a direct request. The client_id, redirect_uri, grant_type, client-secret JWT claims, URLSearchParams/form encoding and absence of an Authorization header were consistent. Despite this, the real framework-generated exchange returns invalid_client while the direct diagnostic request is accepted at the client-authentication stage and returns invalid_grant. Could Apple advise what additional property of the token request could cause this difference in classification? In particular, is there any server-side state or request characteristic used by Sign in with Apple that could cause an otherwise valid client_secret to be classified as invalid_client only during the real authorization-code exchange? I have also prepared detailed diagnostic evidence and can submit the requested sensitive request information through Feedback Assistant rather than posting JWTs, authorization codes, or other credentials publicly. Thank you.

Case #20000132024383 has been filed with Developer Support; posting here as well for visibility Hi Apple Developer Support team, We are experiencing a release-blocking issue: Sign in with Apple always fails server-side with AKAuthenticationServerError -24000 for our bundle com.dadilo.app, on all devices and all Apple IDs we have tested, while the same devices and accounts use Sign in with Apple successfully in other apps. IDENTIFIERS Team ID: HF53KC83Z3 (Individual - Nguyen Duy Mao) Bundle ID: com.dadilo.app (App ID resource 96Q4FAZ8PF) App Store Connect app: "Dadilo: Giup viec nha" - Apple ID 6782634291 (unreleased; TestFlight builds 1.0.0 (120-126)) Client: native ASAuthorizationAppleIDProvider request (Flutter sign_in_with_apple plugin). No web/Services-ID flow is involved. SYMPTOM Every Sign in with Apple attempt completes the system sheet (Face ID/password succeeds, scope selection is shown), then iOS shows the alert "Sign-Up Not Completed". The app's ASAuthorizationControllerDelegate receives ASAuthorizationError code 1001. No credential is ever issued. Device syslog at the exact moment of each failure (captured 2026-08-07 and 2026-08-08): akd: SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2 AKRemoteViewController did complete with authorization (null), error Domain=com.apple.AppleIDAuthSupport Code=2, NSUnderlyingError Domain=AKAuthenticationServerError Code=-24000 akd: Creating AKAuthenticationServerResponse with status contents: (null) akd: Invalid/missing value for key acname: (null); Invalid value for key ut: (null); Invalid value for key authType: (null) The server rejects the request and returns an EMPTY payload; -24000 is the client's reaction to it. An initial tap sometimes logs AKAuthenticationError -7003 first. REPRODUCTION - fails in EVERY combination Devices: iPad mini (iPad16,2, iPadOS 26.5.2) and an iPhone (iOS 26.x) - fails on both Apple IDs: 2 different accounts (2FA enabled, adult, region Vietnam) - fails on both Builds: TestFlight 1.0.0 builds 122, 124, 125, 126 - fails on all Request shape: the standard request (email + fullName scopes, SHA-256 nonce) AND a minimal request (no scopes, no nonce) both fail identically DECISIVE CONTROL TEST (2026-08-08) On the SAME iPad, SAME Apple ID, SAME network, minutes after our app failed,le authorization for another app (ChatGPT - never previously authorized on this account) succeeded normally. So fresh-authorization SRP works for this erver issues credentials for other bundles but rejects com.dadilo.app specifically. Existing authorizations (Notion, Grab, Shopee, Goodnotes) alsocounts. ALREADY VERIFIED / RULED OUT Entitlement com.apple.developer.applesignin = [Default] present in the binary; the provisioning profile contains the entitlement (decoded and checked); the authorization sheet opens and biometric completes, so the entitlement is honored App ID capability APPLE_ID_AUTH enabled, APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (verified via App Store Connect API); no grouped-app configuration conflicts on the team Program License Agreement issued 2026-06-18, accepted 2026-06-21; no pendi Test Apple IDs are healthy: 2FA on, adult birthdays, no Family restrictionh Apple with other apps No stale authorizations: this app is not listed in Settings > Sign in with- Capability re-provisioning attempted 2026-08-08: deleted and re-created APnerated a brand-new App Store provisioning profile, rebuilt and re-tested(build 125) - identical -24000 failure Apple System Status showed no Sign in with Apple outage during any test REQUEST AKAuthenticationServerError -24000 is not publicly documented. Everything clecks out, and the failure is 100% reproducible for this bundle ID only.Please inspect the server-side Sign in with Apple configuration/state for co3 and advise what is rejecting credential issuance.The app is complete and ready for App Store submission; Sign in with Apple ier Guideline 4.8, so this issue is blocking our first release. Fullidevicesyslog captures from both days are available on request. Thank you, Nguyen Duy Mao Team HF53KC83Z3

Sign in with Apple never completes for our app. The authorization sheet presents, the user confirms, and we get ASAuthorizationError 1000. The akd log shows the local entitlement check PASSING and the failure happening server-side. Environment: native ASAuthorizationAppleIDProvider (no web flow, no Services ID), TestFlight build, iOS 26. New App ID created 2026-08-06. akd, abridged — local check passes: akd Requesting password only: NO akd Client has default access level in SiwA entitlement akd Client has underage-users access level in SiwA entitlement sheet presents, user confirms: akd presenting authorization UI for request akd Remote view sent a user response event akd Attempting authorization with response then the server rejects it, after returning HTTP 200: akd Adding passwordlessToken: NO, and idmsDataToken: NO, to auth-params akd No password, but CK is available. Will ask for ck-based auth. akd Performing SRP request with context akd Task ... received response, status 200 content K akd AppleIDAuthSupport: setError: 2:M2 missing (bad password) akd Invalid/missing value for key acname: (null) akd SRP authentication with server failed! Domain=com.apple.AppleIDAuthSupport Code=2 akd Error performing auth request: Domain=AKAuthenticationError Code=-7003 What we have already ruled out: Sign in with Apple enabled on the App ID, configured as "Enable as a primary App ID" (verified in the portal UI, not just via the App Store Connect API). Provisioning profiles deleted and regenerated AFTER enabling the capability, twice, the second time a full day later. The embedded .mobileprovision in the shipped build contains com.apple.developer.applesignin = (Default). The signed binary carries the entitlement (codesign -d --entitlements on the archive). More than 24 hours elapsed since enabling the capability, per the guidance on -7003 in thread 789697. requestedScopes tried as both [.email] and [.fullName, .email]. App deleted and reinstalled; device restarted. Reproduced on a SECOND device (an iPad) that had never had the app installed. Control: a third-party App Store app created a brand-new Sign in with Apple association (it prompted for name, so first-time consent) on the same device and same Apple ID, minutes after our failure, so the account and device can create new associations. Question: what causes Apple's identity service to reject the SRP exchange for one client while accepting it for others on the same device and account? Is there additional App ID or account state we cannot see from the portal? Happy to provide the full akd log.

Hi, we are currently investigating an issue with Kerberos support in one of our apps. The apps are deployed as managed apps via MDM, together with the new extensible SSO Kerberos profile. In this scenario, Ivanti EPMM is used as MDM, and the extensible SSO configuration has placeholders for the actual user principal name that get filled with the users actual information from our directory. In general, the setup works fine, the Kerberos tickets are requested and supplied to the device, and the SSO extension is providing them to the service. However, in our test MDM environment we enroll i.e. iPad test devices with different test users from our directory and change those users during testing to switch between defined personas. We observed that the credentials acquired by the Kerberos SSO extension dialogue persist even after MDM unenrollment, and even after a device reset. Even if we enroll back to MDM with another user, the previous principal name shows in the SSO extension dialogue and cannot be changed. To us, this seems like a design issue. We use same Apple ID when running these tests, so I suspect that the credential caching could be at Keychain level. Regardless of where they are cached, since the configuration was a managed one, I would expect it to clear the credentials after unenrollment and at least after a device reset. We found some article regarding macOS on the internet, which seems to go into a similar direction however the author states that the credentials could be removed with MDM removal. https://automatica.com.au/2026/01/remove-additional-platform-single-sign-on-credentials-saved-in-macos-when-using-psso-with-microsoft-365-entra-and-company-portal/ Question: How are we supposed to get Kerberos SSO credentials cleared on iOS devices? Is this a known issue, or something that does not work as designed?

Dear Apple Developer Support, We are currently encountering a recurring issue with the DeviceCheck API across multiple devices in our production environment. The following error is frequently returned: com.apple.devicecheck.error 0 We would like to ask the following: What are the possible underlying causes that could lead to this specific error code (0) in the DeviceCheck API? Is there any known behavior or condition where Wi-Fi network configurations (e.g., DNS filtering, proxy settings, captive portals) could result in this error? Are there known timeouts, connectivity expectations, or TLS-level requirements that the DeviceCheck API enforces which could fail silently under certain network conditions? Is this error ever triggered locally (e.g., client library-level issues) or is it always from a failed communication with Apple’s servers? Any technical clarification, documentation, or internal insight into this error code would be greatly appreciated. This would help us significantly narrow down root causes and better support our users

Hi, We are looking for guidance on synchronizing a user’s login keychain passphrase after changing that user’s local account password, when the user is not currently logged in. Context We have an MDM product for macOS, and we sometimes need to change a local account password while that user is not logged in. Updating the account password itself from our privileged daemon is fine. The hard part is keeping their login keychain in sync — that only seems to work when we run as that user, in their own session. So we perform the keychain update from a per-user LaunchAgent, not from root. What works (user is logged in) From the user’s LaunchAgent we run: # 1) Change account password (if not already changed) dscl . -passwd "/Users/<username>" "<currentPassword>" "<newPassword>" # 2) Sync login keychain passphrase security set-keychain-password -o "<currentPassword>" -p "<newPassword>" login.keychain-db With correct current/new secrets, this succeeds when the helper is running as that user while they are logged in. What fails (user is not logged in) Starting the same LaunchAgent for that user fails with: Bootstrap failed: 125: Domain does not support specified action So we cannot get user-context execution for the keychain update while the user is not logged in. Approaches we already tried Post-login LaunchAgent — We stage the current/new passwords and install a LaunchAgent that runs after the user logs in to migrate the keychain. By the time the user is logged in and the agent runs, macOS has already created a new login keychain and renamed the previous one (e.g. login.keychain-db-renamed-N). At that point we can no longer reliably migrate/restore the original keychain. sudo -u <username> security set-keychain-password … from a root daemon — Led to Keychain Access / keychain state corruption in our testing; we do not consider this a production path. Delete the login keychain — Works as a reset, but discards saved credentials. Acceptable for some admin reset flows; not acceptable for a password change where we know both secrets and want to preserve the keychain. Ask Is there a supported way to update login.keychain-db for a user who is not logged in, given known current and new passphrases, without deleting the keychain? If so, what is that way? If not is there a way to merge the old login keychain as we have the old password too? Also please confirm whether updating another user’s login keychain from root / sudo -u is unsupported, so we can exclude it from product design. Happy to provide sanitized logs (error 125, security failures, renamed keychain timelines) if useful. Thanks.

Trying to find the best place to get guidance from Apple on this issue. Apple support has suggested this Forum. We are trying to get our BIMI to show in iOS devices but so far in the inbox it does not show. But the email header indicates all is good, BIMI=pass. Not sure where to turn to next. My ticket is 20000127527288 with Apple support. But where to get appropriate feedback on our issue is what I'm looking for guidance.

Hey there, I'm trying to building an iOS credential provider (ASCredentialProviderExtension, iOS 17+) that manages passkeys backed by keys generated in the Secure Enclave, attested via App Attest. My question is about the cross-device (FIDO2 hybrid / "passkey on a nearby device") flow, where a phone authenticates a sign-in initiated on a separate client device (e.g. a laptop browser). Specifically, Can a third-party credential provider serve as the authenticator in this flow, signing with its own key — or is the cross-device role reserved for iCloud Keychain? If it can, does the OS handle the BLE advertisement and tunnel/handshake on the provider's behalf? I ask because it seems like CBPeripheralManager.startAdvertising(_:) will not emit raw bytes, so an app can't emit a CTAP hybrid advert itself. If neither is supported, is there any supported API — including MDM-managed/supervised-device capabilities — for an app to act as a cross-device FIDO2 authenticator with a non-iCloud-Keychain key? Thanks!