[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.

I have filed bug reports on this to no avail, so I am bringing it up here hoping someone at Apple will address this. Since the first beta of 26.3, with voice control enabled there are now two icons in the menu bar (*plus an orange dot in full screen) that never go away. That orange microphone isn't serving its intended purpose to notify me that something is accessing my microphone if it is always displayed. I use voice control extensively, so it is nearly always on. In every prior version of macOS, the orange icon was not on for voice control. Even if voice control is not listening but simply enabled in system settings, the orange icon will be there. And there is no need for this icon to be on for a system service that is always listening. This orange icon in the menu bar at all times is incredibly irritating, as it takes up valuable space to the right of the notch, and causes other actual useful menu bar items to be hidden. As well, if some other application on my system were to turn on the mic and start recording me I would never know since that orange icon is always on. It also places an orange dot next to the control center icon taking up even more of the precious little menu bar real estate. Please fix this! Either exempt voice control (as Siri is always listening and it doesn't get the orange icon) or exempt all system services, or give me a way to turn this off. If you cannot tell, I find this incredibly annoying and frustrating.

% curl -v https://app-site-association.cdn-apple.com/a/v1/zfcs.bankts.cn Host app-site-association.cdn-apple.com:443 was resolved. IPv6: (none) IPv4: 218.92.226.151, 119.101.148.193, 218.92.226.6, 115.152.217.3 Trying 218.92.226.151:443... Connected to app-site-association.cdn-apple.com (218.92.226.151) port 443 ALPN: curl offers h2,http/1.1 (304) (OUT), TLS handshake, Client hello (1): CAfile: /etc/ssl/cert.pem CApath: none (304) (IN), TLS handshake, Server hello (2): (304) (IN), TLS handshake, Unknown (8): (304) (IN), TLS handshake, Certificate (11): (304) (IN), TLS handshake, CERT verify (15): (304) (IN), TLS handshake, Finished (20): (304) (OUT), TLS handshake, Finished (20): SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF ALPN: server accepted http/1.1 Server certificate: subject: C=US; ST=California; O=Apple Inc.; CN=app-site-association.cdn-apple.com start date: Sep 25 13:58:08 2025 GMT expire date: Mar 31 17:44:25 2026 GMT subjectAltName: host "app-site-association.cdn-apple.com" matched cert's "app-site-association.cdn-apple.com" issuer: CN=Apple Public Server RSA CA 11 - G1; O=Apple Inc.; ST=California; C=US SSL certificate verify ok. using HTTP/1.x GET /a/v1/zfcs.bankts.cn HTTP/1.1 Host: app-site-association.cdn-apple.com User-Agent: curl/8.7.1 Accept: / Request completely sent off < HTTP/1.1 404 Not Found < Content-Type: text/plain; charset=utf-8 < Content-Length: 10 < Connection: keep-alive < Server: nginx < Date: Wed, 04 Feb 2026 02:26:00 GMT < Expires: Wed, 04 Feb 2026 02:26:10 GMT < Age: 24 < Apple-Failure-Details: {"cause":"context deadline exceeded (Client.Timeout exceeded while awaiting headers)"} < Apple-Failure-Reason: SWCERR00301 Timeout < Apple-From: https://zfcs.bankts.cn/.well-known/apple-app-site-association < Apple-Try-Direct: true < Vary: Accept-Encoding < Via: https/1.1 jptyo12-3p-pst-003.ts.apple.com (acdn/3.16363), http/1.1 jptyo12-3p-pac-043.ts.apple.com (acdn/3.16363), https/1.1 jptyo12-3p-pfe-002.ts.apple.com (acdn/3.16363) < X-Cache: MISS KS-CLOUD < CDNUUID: 736dc646-57fb-43c9-aa0d-eedad3a534f8-1154605242 < x-link-via: yancmp83:443;xmmp02:443;fzct321:443; < x-b2f-cs-cache: no-cache < X-Cache-Status: MISS from KS-CLOUD-FZ-CT-321-35 < X-Cache-Status: MISS from KS-CLOUD-XM-MP-02-16 < X-Cache-Status: MISS from KS-CLOUD-YANC-MP-83-15 < X-KSC-Request-ID: c4a640c815640ee93c263a357ee919d6 < CDN-Server: KSFTF < X-Cdn-Request-ID: c4a640c815640ee93c263a357ee919d6 < Not Found Connection #0 to host app-site-association.cdn-apple.com left intact

I'm developing a passkey manager using ASCredentialProviderViewController. I've set a custom AAGUID in the attestation object during registration: let aaguid = Data([ 0xec, 0x78, 0xfa, 0xe8, 0xb2, 0xe0, 0x56, 0x97, 0x8e, 0x94, 0x7c, 0x77, 0x28, 0xc3, 0x95, 0x00 ]) However, when I test on webauthn.io, the relying party receives: AAGUID: 00000000-0000-0000-0000-000000000000 Provider Name: "iCloud Keychain" It appears that macOS overwrites the AAGUID to all zeros for third-party Credential Provider Extensions. This makes it impossible for relying parties to distinguish between different passkey providers, which is one of the key purposes of AAGUID in the WebAuthn specification. Is this expected behavior? Is there a way for third-party Credential Provider Extensions to use their own registered AAGUID? Environment: macOS 26.2 Xcode 26.2

In these threads, it was clarified that Credential Provider Extensions must set both Backup Eligible (BE) and Backup State (BS) flags to 1 in authenticator data: https://developer.apple.com/forums/thread/745605 https://developer.apple.com/forums/thread/787629 However, I'm developing a passkey manager that intentionally stores credentials only on the local device. My implementation uses: kSecAttrAccessibleWhenUnlockedThisDeviceOnly for keychain items kSecAttrTokenIDSecureEnclave for private keys No iCloud sync or backup These credentials are, by definition, single-device credentials. According to the WebAuthn specification, they should be represented with BE=0, BS=0. Currently, I'm forced to set BE=1, BS=1 to make the extension work, which misrepresents the actual backup status to relying parties. This is problematic because: Servers using BE/BS flags for security policies will incorrectly classify these as synced passkeys Users who specifically want device-bound credentials for higher security cannot get accurate flag representation Request: Please allow Credential Provider Extensions to return credentials with BE=0, BS=0 for legitimate device-bound passkey implementations. Environment: macOS 26.2 (25C56), Xcode 26.2 (17C52)

Hello, I’m working on an authorization plugin which allows users to login and unlock their computer with various methods like a FIDO key. I need to add smart cards support to it. If I understand correctly, I need to construct a URLCredential object with the identity from the smart card and pass it to the completion handler of URLSessionDelegate.urlSession(_:didReceive:completionHandler:) method. I’ve read the documentation at Using Cryptographic Assets Stored on a Smart Card, TN3137: On Mac keychain APIs and implementations, and SecItem: Pitfalls and Best Practices and created a simple code that reads the identities from the keychain: CFArrayRef identities = nil; OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)@{ (id)kSecClass: (id)kSecClassIdentity, (id)kSecMatchLimit: (id)kSecMatchLimitAll, (id)kSecReturnRef: @YES, }, (CFTypeRef *)&identities); if (status == errSecSuccess && identities) { os_log(OS_LOG_DEFAULT, "Found identities: %{public}ld\n", CFArrayGetCount(identities)); } else { os_log(OS_LOG_DEFAULT, "Error: %{public}ld\n", (long)status); } When I use this code in a simple demo app, it finds my Yubikey identities without problem. When I use it in my authorization plugin, it doesn’t find anything in system.login.console right and finds Yubikey in authenticate right only if I register my plugin as non-,privileged. I tried modifying the query in various ways, in particular by using SecKeychainCopyDomainSearchList with the domain kSecPreferencesDomainDynamic and adding it to the query as kSecMatchSearchList and trying other SecKeychain* methods, but ended up with nothing. I concluded that the identities from a smart card are being added to the data protection keychain rather than to a file based keychain and since I’m working in a privileged context, I won’t be able to get them. If this is indeed the case, could you please advise how to proceed? Thanks in advance.

Hi, I'm using webauthn.io to test my macOS Passkey application. When registering a passkey whichever value I set for User Verification, that's what I get when I check registrationRequest.userVerificationPreference on prepareInterface(forPasskeyRegistration registrationRequest: any ASCredentialRequest). However, when authenticating my passkey I can never get discouraged UV on prepareInterfaceToProvideCredential(for credentialRequest: any ASCredentialRequest). In the WWDC 2022 Meet Passkeys video, it is stated that Apple will always require UV when biometrics are available. I use a Macbook Pro with TouchID, but if I'm working with my lid closed, shouldn't I be able to get .discouraged?

Trusted execution is a generic name for a Gatekeeper and other technologies that aim to protect users from malicious code. General: Forums topic: Code Signing Forums tag: Gatekeeper Developer > Signing Mac Software with Developer ID Apple Platform Security support document Safely open apps on your Mac support article Hardened Runtime document WWDC 2022 Session 10096 What’s new in privacy covers some important Gatekeeper changes in macOS 13 (starting at 04: 32), most notably app bundle protection WWDC 2023 Session 10053 What’s new in privacy covers an important change in macOS 14 (starting at 17:46), namely, app container protection WWDC 2024 Session 10123 What’s new in privacy covers an important change in macOS 15 (starting at 12:23), namely, app group container protection Updates to runtime protection in macOS Sequoia news post Testing a Notarised Product forums post Resolving Trusted Execution Problems forums post App Translocation Notes (aka Gatekeeper path randomisation) forums post Most trusted execution problems are caused by code signing or notarisation issues. See Code Signing Resources and Notarisation Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Estou compartilhando algumas observações técnicas sobre Crash Detection / Emergency SOS no ecossistema Apple, com base em eventos amplamente observados em 2022 e 2024, quando houve chamadas automáticas em massa para serviços de emergência. A ideia aqui não é discutir UX superficial ou “edge cases isolados”, mas sim comportamento sistêmico em escala, algo que acredito ser relevante para qualquer time que trabalhe com sistemas críticos orientados a eventos físicos. Contexto resumido A partir do iPhone 14, a Detecção de Acidente passou a correlacionar múltiplos sensores (acelerômetros de alta faixa, giroscópio, GPS, microfones) para inferir eventos de impacto severo e acionar automaticamente chamadas de emergência. Em 2022, isso resultou em um volume significativo de falsos positivos, especialmente em atividades com alta aceleração (esqui, snowboard, parques de diversão). Em 2024, apesar de ajustes, houve recorrência localizada do mesmo padrão. Ponto técnico central O problema não parece ser hardware, nem um “bug pontual”, mas sim o estado intermediário de decisão: Aceleração ≠ acidente Ruído ≠ impacto real Movimento extremo ≠ incapacidade humana Quando o classificador entra em estado ambíguo, o sistema depende de uma janela curta de confirmação humana (toque/voz). Em ambientes ruidosos, com o usuário em movimento ou fisicamente ativo, essa confirmação frequentemente falha. O sistema então assume incapacidade e executa a ação fail-safe: chamada automática. Do ponto de vista de engenharia de segurança, isso é compreensível. Do ponto de vista de escala, é explosivo. Papel da Siri A Siri não “decide” o acidente, mas é um elo sensível na cadeia humano–máquina. Falhas de compreensão por ruído, idioma, respiração ofegante ou ausência de resposta acabam sendo interpretadas como sinal de emergência real. Isso é funcionalmente equivalente ao que vemos em sistemas automotivos como o eCall europeu, quando a confirmação humana é inexistente ou degradada. O dilema estrutural Há um trade-off claro e inevitável: Reduzir falsos negativos (não perder um acidente real) Aumentar falsos positivos (chamadas indevidas) Para o usuário individual, errar “para mais” faz sentido. Para serviços públicos de emergência, milhões de dispositivos errando “para mais” criam ruído operacional real. Por que isso importa para developers A Apple hoje opera, na prática, um dos maiores sistemas privados de segurança pessoal automatizada do mundo, interagindo diretamente com infraestrutura pública crítica. Isso coloca Crash Detection / SOS na mesma categoria de sistemas safety-critical, onde: UX é parte da segurança Algoritmos precisam ser auditáveis “Human-in-the-loop” não pode ser apenas nominal Reflexões abertas Alguns pontos que, como developer, acho que merecem discussão: Janelas de confirmação humana adaptativas ao contexto (atividade física, ruído). Cancelamento visual mais agressivo em cenários de alto movimento. Perfis de sensibilidade por tipo de atividade, claramente comunicados. Critérios adicionais antes da chamada automática quando o risco de falso positivo é estatisticamente alto. Não é um problema simples, nem exclusivo da Apple. É um problema de software crítico em contato direto com o mundo físico, operando em escala planetária. Justamente por isso, acho que vale uma discussão técnica aberta, sem ruído emocional. Curioso para ouvir perspectivas de quem trabalha com sistemas similares (automotivo, wearables, safety-critical, ML embarcado). — Rafa

Hi Apple Developers, I'm having a problem with evaluatedPolicyDomainState: on the same device, its value keeps changing and then switching back to the original. My current iOS version is 26.1. I upgraded my iOS from version 18.6.2 to 26.1. What could be the potential reasons for this issue? { NSError *error; BOOL success = YES; char *eds = nil; int edslen = 0; LAContext *context = [[LAContext alloc] init]; // test if we can evaluate the policy, this test will tell us if Touch ID is available and enrolled // success = [context canEvaluatePolicy: LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&error]; if (SystemVersion > 9.3) { // test if we can evaluate the policy, this test will tell us if Touch ID is available and enrolled success = [context canEvaluatePolicy: LAPolicyDeviceOwnerAuthentication error:&error]; } else{ // test if we can evaluate the policy, this test will tell us if Touch ID is available and enrolled success = [context canEvaluatePolicy: LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&error]; } if (success) { if (@available(iOS 18.0, *)) { NSData *stateHash = nil; if ([context respondsToSelector:@selector(domainState)]) { stateHash = [[context performSelector:@selector(domainState)] performSelector:@selector(stateHash)]; }else{ stateHash = [context evaluatedPolicyDomainState]; } eds = (char *)stateHash.bytes; edslen = (int)stateHash.length; } else { eds = (char *)[[context evaluatedPolicyDomainState] bytes]; edslen = (int)[[context evaluatedPolicyDomainState] length]; } CC_SHA256(eds, edslen, uviOut); *poutlen = CC_SHA256_DIGEST_LENGTH; } else { *poutlen = 32; gm_memset(uviOut, 0x01, 32); } }

After registe Passkey with webauthn library, i create a passkeyRegistration with follow, let passkeyRegistration = ASPasskeyRegistrationCredential(relyingParty: serviceIdentifier, clientDataHash: clientDataHashSign, credentialID: credentialId, attestationObject: attestationObject) and then completeRegistrationRequest like that, extensionContext.completeRegistrationRequest(using: passkeyRegistration) But a bad outcome occurred from user agent. NotAllowedError:The request is not allowed by the user agent or the platform in the current context. And the return data rawID & credentialPublicKey is empty,

My application is supporting hybrid transport on FIDO2 webAuthn specs to create credential and assertion. And it support legacy passkeys which only mean to save to 1 device and not eligible to backup. However In my case, if i set the Backup Eligibility and Backup State flag to false, it fails on the completion of the registrationRequest to save the passkey credential within credential extension, the status is false instead of true. self.extension.completeRegistrationRequest(using: passkeyRegistrationCredential) The attestation and assertion flow only works when both flags set to true. Can advice why its must have to set both to true in this case?

Hi I'm developing an app that autofills Passkeys. The app allows the user to authenticate to their IdP to obtain an access token. Using the token the app fetches from <server>/attestation/options. The app will generate a Passkey credential using a home-grown module - the extension has no involvement, neither does ASAuthorizationSecurityKeyPublicKeyCredentialProvider. I can confirm the passkey does get created. Next the credential is posted to <server>/attestation/results with the response JSON being parsed and used to create a ASPasskeyCredentialIdentity - a sample of the response JSON is attached. Here is my save function: static func save(authenticator: AuthenticatorInfo) async throws { guard let credentialID = Data(base64URLEncoded: authenticator.attributes.credentialId) else { throw AuthenticatorError.invalidEncoding("Credential ID is not a valid Base64URL string.") } guard let userHandle = authenticator.userId.data(using: .utf8) else { throw AuthenticatorError.invalidEncoding("User handle is not a valid UTF-8 string.") } let identity = ASPasskeyCredentialIdentity( relyingPartyIdentifier: authenticator.attributes.rpId, userName: authenticator.userId, // This is what the user sees in the UI credentialID: credentialID, userHandle: userHandle, recordIdentifier: authenticator.id ) try await ASCredentialIdentityStore.shared.saveCredentialIdentities([identity]) } Although no error occurs, I don't get any identities returned when I call this method: let identities = await ASCredentialIdentityStore.shared.credentialIdentities( forService: nil, credentialIdentityTypes: [.passkey] ) Here is the Info.plist in the Extension: <plist version="1.0"> <dict> <key>NSExtension</key> <dict> <key>NSExtensionAttributes</key> <dict> <key>ASCredentialProviderExtensionCapabilities</key> <dict> <key>ProvidesPasskeys</key> <true/> </dict> <key>ASCredentialProviderExtensionShowsConfigurationUI</key> <true/> </dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.authentication-services-credential-provider-ui</string> <key>NSExtensionPrincipalClass</key> <string>$(PRODUCT_MODULE_NAME).CredentialProviderViewController</string> </dict> </dict> </plist> The entitlements are valid and the app and extension both support the same group. I'm stumped as to why the identity is not getting saved. Any ideas and not getting retrieved. attestationResult.json

Hi, In our app we are using DeviceCheck (App Attest) in a production environment iOS. The service works correctly for most users, but a user reported failure in a flow that use device check service. This failure is not intermittently, it is constant. We are unable to reproduce this failure and we are believing that this failure occurred by new version ios 26.3 because for others users using early versions the service is normally. Environment iOS 26.3 Real device App Attest capability enabled Correct App ID, Team ID and App Attest entitlement Production environment Characteristics: appears constantly affects only unique user -Don't resolves after time or reinstall not reproducible on our test devices NSError contains no additional diagnostic info (Error Domain=com.apple.devicecheck.error Code=3 "(null)") We saw about this error code 3 in this post 812308, but it's not our case because the ios version in this case is not iOS 17.0 or earlier. Please, help us any guidance for solution. Thank you

Hi everyone, I'm working on an app that stores multiple secrets in the Keychain, each protected with .userPresence. My goal is to authenticate the user once via FaceID/TouchID and then read multiple Keychain items without triggering subsequent prompts. I am reusing the same LAContext instance for these operations, and I have set: context.touchIDAuthenticationAllowableReuseDuration = LATouchIDAuthenticationMaximumAllowableReuseDuration However, I'm observing that every single SecItemCopyMatching call triggers a new FaceID/TouchID prompt, even if they happen within seconds of each other using the exact same context. Here is a simplified flow of what I'm doing: Create a LAContext. Set touchIDAuthenticationAllowableReuseDuration to max. Perform a query (SecItemCopyMatching) for Item A, passing [kSecUseAuthenticationContext: context]. Result: System prompts for FaceID. Success. Immediately perform a query (SecItemCopyMatching) for Item B, passing the same [kSecUseAuthenticationContext: context]. Result: System prompts for FaceID again. My question is: Does the .userPresence access control flag inherently force a new user interaction for every Keychain access, regardless of the LAContext reuse duration? Is allowableReuseDuration only applicable for LAContext.evaluatePolicy calls and not for SecItem queries? If so, is there a recommended pattern for "unlocking" a group of Keychain items with a single biometric prompt? Environment: iOS 17+, Swift. Thanks!

"I am attempting to read and write data to an Office Group Container, and I am consistently prompted with the "App would like to access data from other apps" alert. How can I configure the application or environment to suppress this repeated permission prompt?"

Hello, I would like to seek clarification regarding the availability of the NFC Secure Element (SE) / ISO7816 entitlement by region, specifically for Indonesia. I recently contacted Apple Developer Support regarding the use of NFC for reading ISO7816-compatible cards. I was informed that, at this time, the NFC & Secure Element entitlement is not available in Indonesia. For technical planning and compliance purposes, I would like to confirm the following: Is the NFC Secure Element / ISO7816 entitlement currently restricted by region, and is Indonesia officially unsupported at this time? For apps distributed on the App Store in Indonesia, is Core NFC limited to NDEF and non–Secure Element tag reading only? Are there any publicly supported alternatives or recommended architectural approaches for NFC-based workflows in regions where the Secure Element entitlement is unavailable? Is there any public documentation or guidance that outlines regional availability for NFC Secure Element features? I understand that entitlement approvals and availability may vary by region and are handled on a case-by-case basis. Any clarification from Apple engineers or developers with experience in this area would be greatly appreciated. Thank you for your time and assistance. Best regards.

On iOS 26, QuickLookAR (ARQuickLookPreviewItem) shares the actual .usdz file via the system Share Sheet instead of the original website URL. This is a regression from iOS 17–18, where sharing correctly preserved and sent only the source URL. Repro steps: 1. Open a web-hosted USDZ model in QuickLookAR (Safari). 2. Tap Share. 3. Share via any messenger. 4. The full .usdz file is sent. Expected: Share Sheet sends only the original URL. Actual: Share Sheet sends the USDZ file. Impact: Uncontrolled distribution of proprietary 3D assets. Critical IP / data leak. Blocks production AR deployments relying on QuickLook. Environment: iOS 26.0–26.1, iPhone 14 / 15. Works as expected on iOS 17–18. Test case: https://admixreality.com/ios26/