We have an application (macOS) which opens an ASWebAuthenticationSession window to prompt the user for credentials. This works well, except for there are times when the window is opened behind other windows - and the user does not see that they are being prompted for authentication. Is there some way to force this window to be always-on-top or at the very least, to bring it to the foreground on top of other windows (including other browser windows from the same default system browser).

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

I'm seeing a behavior difference in CGWindowListCopyWindowInfo between macOS 26 Tahoe and macOS 27 Golden Gate beta regarding the Screen Recording / System Audio Recording privacy permission, and I'd like to confirm whether this is intentional or a beta regression. Environment macOS 26 Tahoe (26.x) — tested behavior below macOS 27 Golden Gate beta 4 (26A5388g) — tested behavior below Expected behavior (matches Tahoe) When my app does NOT have permission under System Settings > Privacy & Security > Screen & System Audio Recording: CGWindowListCopyWindowInfo still returns window list entries for other running apps. However, kCGWindowOwnerName for windows owned by processes other than my own app is nil. When permission IS granted, kCGWindowOwnerName is populated correctly for all windows. Actual behavior on Golden Gate Even without Screen Recording permission granted (verified in System Settings, and via CGPreflightScreenCaptureAccess() returning false), kCGWindowOwnerName is populated for windows owned by other running apps — i.e., the same as if permission had been granted. Repro swift let options: CGWindowListOption = [.optionOnScreenOnly, .excludeDesktopElements] let windowList = CGWindowListCopyWindowInfo(options, kCGNullWindowID) as? [[String: AnyObject]] for window in windowList ?? [] { let owner = window[kCGWindowOwnerName as String] as? String print(owner ?? "nil") } On Tahoe without permission: prints nil for other apps' windows. On Golden Gate beta 4 without permission: prints the actual owner name for other apps' windows. Question Is this a known/intentional change in Golden Gate, or a beta regression in the TCC enforcement path for this API? Since Apple has been steadily tightening screen-capture-adjacent APIs (Sonoma/Sequoia/Tahoe) and recommending migration to ScreenCaptureKit, should we treat any reliance on kCGWindowOwnerName's permission-gated nil behavior as unsupported going forward, and use a different API to check whether the process has Screen Recording access? Any guidance from DTS would be appreciated. Happy to file a Feedback Assistant report with a sample project if useful — let me know the FB number format expected.

Question I'm encountering a very strange RSA issue on iOS. I'm using a 1024-bit RSA key pair generated by SecKeyGeneratePair. Public Key MIGJAoGBAK2wYDpTcGxFDe+0SwUj4twWOQWfWE+pvbgoUFsXZ/XBplEv7qlruq8ZutG+q7qW2M1983V5HzWGmtDrz2l8vLHYNKaBqEGYAtlYIePBq6+lfsUj2qmFE5Uui8R44KLz8i8QqMxYJUQoeUY3JxHeOe4DnUMWK3+X2nWWv4YWv9qxAgMBAAE= Private Key MIICWwIBAAKBgQCtsGA6U3BsRQ3vtEsFI+LcFjkFn1hPqb24KFBbF2f1waZRL+6pa7qvGbrRvqu6ltjNffN1eR81hprQ689pfLyx2DSmgahBmALZWCHjwauvpX7FI9qphROVLovEeOCi8/IvEKjMWCVEKHlGNycR3jnuA51DFit/l9p1lr+GFr/asQIDAQABAoGAAe2GUpITWkmgQw6Z0uZdfIAM+nm/YcT6di/mXRh4VC3l0hq0LV0PfvrhYWDFKFvyb0IhthEAg8LTzD6tzZfaQqIOMEu77BkuDnpu3g7xTnZP2n2nmBU+4kz7F9l/pBr0KL6RopnagcwfuAtPXxGKv2kfWWbX3szHJXwjMo2KjgECQQDhN/i/yDjhzu8psTHvGptiHrOqi5H1CdmSg7u7EbBbZIPp/FsoxBsxcY8FPmMAkD0bR0JIpwBmYkPLFm+rITeBAkEAxW13UsOstGN8rRJ34SklhlYUDUQKN2R8OLyES5w7rRPcOUfCdKR45SJ2OWrLHATqlPRN+9jo5WmsQWArxlm7MQJAF/2DVMJ6NKt7VGCYphSaeqA0mTUWzhhHgdDgfXPL6mBRoOoNt9Dz6JdlGbTkjNnQeIhlqiGH7GAJQqfYK011gQJATWDIAaI7kD/l35d7cL5FvM8D8OcX8fnqTfplB5VmNkGwcKrVZg4IbBYDrCFVFdg/cL4HyouLTE8MelsNDSKiIQJAEwj2CoK+uupS2T1gJNd57wqOkZp+LbkVX92oSUbJQfez1P7Ldtbn4uCMyoOL34I9CTDfCzlxWqbZnwFmSq3eaQ== Test Data Plaintext: SO202605140735073974 Encrypted ciphertext (Base64): AAKhsQxaEVqqZbFLUzC1+8uzdyCDVxzkTbq37pea6cgLlCTOniYeZQVwaOIRdioQmZ/M/0q33l0votNRWZje8bj4Km0vQF2NjvX+8EjPg6T6OsJKEt/KZf+bX6+PoNooSh1tC9H/HVFhhgNJdpKj9s/Fdl3eLH4qEsmQ25FS53M= After calling SecKeyDecrypt, I get the following decrypted bytes: 4d48734341514177457759484b6f5a497a6a3043415159494b6f5a497a6a304441514545595442664167454242426835707a4b493973744f4e42416b4a4757646e5035465842546d386e555272565367436759494b6f5a497a6a3044415147684e414d794141545a542b4a49746b4a4e647554424e70624d336f324d7a654e5565306f6e4e617a623767645975303370712f2f4271505861397747504e4575462b7145786a4c633d However: NSString *result = [[NSString alloc] initWithData:plainData encoding:NSUTF8StringEncoding]; returns nil. Additional Information This RSA key pair works correctly for many other plaintext values. The failure only occurs when encrypting and decrypting this specific string: SO202605140735073974 The RSA key pair is generated using: SecKeyGeneratePair(...) with a 1024-bit key size. Encryption and decryption use the Security framework APIs: SecKeyEncrypt SecKeyDecrypt Decryption returns errSecSuccess (status == noErr). There are no Security framework errors. Decryption Code status = SecKeyDecrypt( key, kSecPaddingNone, dataSegment.bytes, dataSegmentRealSize, cipherBuffer, &cipherBufferSize ); status is noErr. However, converting the decrypted data to UTF-8 always returns nil. My Questions Why can SecKeyDecrypt return noErr, yet the resulting data is not valid UTF-8? Is it possible that the decrypted bytes are actually an ASN.1/DER structure rather than the original plaintext? Could this be related to using kSecPaddingNone instead of kSecPaddingPKCS1? Is there anything special about this plaintext (SO202605140735073974) that could trigger this behavior, even though other plaintexts work correctly with the same key pair? Any insights would be greatly appreciated. Thanks!

I am developing a macOS solution that exposes a cloud-backed digital signing credential as a system identity through a persistent CryptoTokenKit token extension. My main goal is to allow third-party macOS applications, especially Adobe Acrobat, to discover the signing identity through the standard macOS Keychain infrastructure and use it for signing PDF documents. Intended signing flow The flow I am trying to implement is: The user adds a cloud signing credential in my macOS container application. My application retrieves the certificate and credential metadata from a remote signing service using the CSC protocol. My application creates or updates the persistent CryptoTokenKit token configuration. The CryptoTokenKit extension exposes the certificate and its associated private-key capability as a macOS system identity. The user opens a PDF document in Adobe Acrobat and starts a digital signature operation. Adobe Acrobat discovers the identity through the standard macOS certificate and Keychain selection flow. The signing request is routed to my CryptoTokenKit token extension. My extension forwards the signing request to the remote CSC signing service and returns the resulting signature. The private key is held by the remote signing infrastructure. It is never stored or exported locally. Environment macOS 26.4.1 (25E253) Xcode 26.4.1 (17E202) Swift Persistent Token Extension created from the Xcode template macOS container application Apple silicon Mac Current implementation issue I have built a prototype consisting of a macOS container application and a persistent CryptoTokenKit token extension. While managing the persistent token configuration, I encountered a reproducible issue with TKTokenDriver.Configuration.driverConfigurations. When I access this API from the container application process, the operation can block indefinitely without returning an error. I tested different threads and dispatch queues, but the behavior remained the same. However, when I execute the same configuration operation from a newly launched helper XPC process, it completes successfully. At this stage, I would first like to confirm that the overall architecture is correct before submitting detailed code and reproduction steps. Questions Is a persistent CryptoTokenKit token extension the Apple-supported architecture for exposing a cloud-backed signing credential as a macOS system identity? What is the recommended Apple-supported pattern for creating and updating persistent TKTokenDriver.Configuration entries? Should this be done directly by the container application, or is a separate process expected? Is there any official Apple sample project or technical guidance covering persistent CryptoTokenKit tokens, network-backed signing and consumption by third-party applications? I have a focused test project and can provide minimal code, logs, process samples and detailed reproduction steps if they are useful. Any architectural guidance, sample code or experience with a similar Adobe Acrobat signing flow would be greatly appreciated. Thank you!

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,

We've filed FB22448572 for this, but posting here in case others are hitting the same issue. After upgrading macOS from 26.3.2 to 26.4, SecItemCopyMatching returns errSecAuthFailed (-25293) when reading kSecClassGenericPassword items from the default login keychain. The keychain reports as unlocked, but all authenticated operations fail. The error doesn't self-resolve — we've observed it persisting for 7+ minutes across repeated calls and process restarts. The only workaround we've found is SecKeychainLock(nil) followed by SecKeychainUnlock(nil, 0, nil, false), which prompts the user for their password and clears the stale state. Apple's own security CLI tool also fails while the keychain is in this state: $ security show-keychain-info ~/Library/Keychains/login.keychain-db security: SecKeychainCopySettings .../login.keychain-db: The user name or passphrase you entered is not correct. The trigger seems to be process lifecycle — a new process accessing the keychain early in startup (e.g., from the app delegate) can hit this state after the OS upgrade. It's probabilistic: not every machine and not every restart, but once it happens, it sticks until manual intervention. We're an enterprise app using legacy keychain APIs (SecKeychainCopyDefault, kSecUseKeychain) deployed to thousands of managed devices. We've reproduced this on multiple machines (M1, M2) and have reports from customers in the field after the 26.4 upgrade. I noticed a possibly related thread — Calling SecKeychainUnlock with a locked keychain and an invalid password returns errSecSuccess on macOS 26.4 — where SecKeychainUnlock stopped properly validating passwords after 26.4. Our symptom is different (reads fail on an unlocked keychain rather than unlock succeeding with wrong password), but both appeared after 26.4 and both point to something changing in securityd's authentication handling. Wondering if these could be related. A couple of questions: Is there a known issue with securityd's keychain authentication after 26.4? Could this be related to the CVE-2026-28864 fix ("improved permissions checking" in the Security component)? Would migrating to the data protection keychain (kSecAttrAccessible instead of kSecUseKeychain) avoid this class of issue entirely? Is there a way to detect and clear this stale state programmatically without the user entering their password? Any guidance appreciated.

Hello Apple Developer Team, I am developing a general-purpose web browser for iOS using WKWebView. Current status: • The app is distributed through TestFlight (Internal Testing). • The app is registered in App Store Connect. • The browser supports standard web browsing with multiple tabs and arbitrary websites. My goal is to support WebAuthn passkey authentication for websites such as Google, GitHub, Microsoft, and other websites that support passkeys. While reviewing Apple's documentation, I found: "Passkey use in web browsers" "Authenticating people by using passkeys in browser apps" These documents mention that browser apps on iOS can support passkeys using: ASAuthorizationWebBrowserPublicKeyCredentialManager and the entitlement: com.apple.developer.web-browser.public-key-credential However, I could only find a request form titled: "Request the macOS Web Browser Public Key Credential Entitlement" which specifically asks: "Is your app a web browser on macOS?" My application is an iOS web browser, not a macOS browser. In addition, I previously requested the Default Web Browser entitlement, but my request was declined. My questions are: Is there a separate application process for requesting the Web Browser Public Key Credential entitlement for an iOS browser? Is approval of the Default Web Browser entitlement required before an iOS browser can use WebAuthn passkeys? Can an iOS browser request only the Web Browser Public Key Credential entitlement without becoming the system default browser? Is there any official documentation describing the entitlement request process for iOS browser apps? I know that third-party browsers such as Aloha Browser appear to support system Passkeys on iOS, so I would like to understand the correct implementation and entitlement process for an iOS browser. Thank you very much for your guidance.

Hi! We're developing a security product that uses both EndpointSecurity.framework to intercept and authorize process and file events; and NetworkExtension.framework o intercept and inspect network connections. We're occasionally seeing crashes caused by Endpoint Security timeouts. After investigating several crash reports, we believe we've identified a deadlock involving code signature verification: our Network Extension intercepts connections initiated by nsurlsessiond to retrieve OCSP/CRL data (we believe these requests are made on behalf of trustd during code signature validation). To determine which policy should be applied to an intercepted connection, our Network Extension verifies the code signature of the originating process. However, that code signature verification itself blocks while waiting for the OCSP/CRL requests to complete. Since those requests are being intercepted by our Network Extension, we end up with a circular dependency: A process requires code signature verification. Signature verification triggers OCSP/CRL network requests. Those requests are intercepted by our Network Extension. Our Network Extension attempts to verify the initiator's code signature before allowing the connection. That verification waits for the same OCSP/CRL requests to complete. As a result, code signature verification becomes blocked process-wide, including verification performed while handling Endpoint Security events. Eventually, our Endpoint Security client exceeds the allowed response timeout and is terminated. We're considering bypassing interception for OCSP/CRL traffic to avoid this deadlock, but we'd like to understand whether this is the recommended or most robust approach. Questions Is there a reliable way to identify network connections that are fetching OCSP or CRL data for code signature validation? What is the relationship between trustd and nsurlsessiond for these requests? Is there a dedicated nsurlsessiond instance serving trustd, or are these requests performed by the shared system/session-wide nsurlsessiond? Would it be a reasonable and future-proof approach to identify these requests by checking NEAppProxyFlow.remoteHostname (for example, ocsp.apple.com and crl.apple.com) and bypassing interception for those connections? Is there another recommended approach to avoid this deadlock when combining Endpoint Security and Network Extension in this way? Any guidance or best practices would be greatly appreciated. Thank you!

Quinn, you've often suggested that to validate the other side of an XPC connection, we should use the audit token. But that's not available from the XPC object, whereas the PID is. So everyone uses the PID. While looking for something completely unrelated, I found this in the SecCode.h file OSStatus SecCodeCreateWithXPCMessage(xpc_object_t message, SecCSFlags flags, SecCodeRef * __nonnull CF_RETURNS_RETAINED target); Would this be the preferred way to do this now? At least from 11.0 and up. Like I said, I was looking for something completely unrelated and found this and don't have the cycles right now to try it. But it looks promising from the description and I wanted to check in with you about it in case you can say yes or no before I get a chance to test it. Thanks

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().

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?

We generate Secure Enclave keys via SecKeyCreateRandomKey with kSecAttrTokenIDSecureEnclave on macOS. We need to prove to a remote server that the key is genuinely hardware-bound, not a software key claiming to be one. Is there any API on macOS for an app to obtain an Apple-signed certificate or attestation statement for such a Secure Enclave key, similar to how ASAuthorizationProviderExtensionLoginManager.attestKey() works within Platform SSO but available to general apps? Or other possible workaround for this? Thank you!

Hi, I would like to share a keychain item common for mac os app (sandboxed) and swift cli app (non sandboxed). Is there a recommended way for doing this? Thanks

% 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

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.

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