Hello, We are reaching out as a company providing Wi-Fi connectivity services through captive portals to report a potential issue identified after upgrading to iOS 26. Since the release of this version, we have received multiple reports from customers who are unable to complete the authentication process on captive portal networks. The observed behavior is as follows: The device correctly detects the Wi-Fi network. The connection is established at the link level, but after entering access credentials and proceeding to the next login step, an “error opening page” message is consistently displayed. When the user taps “OK,” the captive portal mini-browser closes. As a result, the user is unable to authenticate or gain internet access. We have verified that: Our network infrastructure and captive portals function correctly on other operating systems (Android, Windows, and previous iOS versions). No recent changes have been made to our platforms that could explain this behavior. The issue appears to be consistently reproducible on devices running iOS 26. Additionally, we have identified similar reports from users in public communities like reddit, suggesting this is not an isolated case. https://www.reddit.com/r/ios/comments/1no4vzt/switched_to_ios_26_and_now_i_cant_connect_to/ Given the direct impact on user experience and services relying on web-based authentication, we would appreciate any information on whether this behavior is being investigated or if there are any technical recommendations to mitigate the issue. Thank you for your attention.

We are implementing Platform SSO with Secure Enclave–based authentication. In a standard (post-enrollment) flow, everything behaves as expected: Authentication uses urn:ietf:params:oauth:grant-type:jwt-bearer The Secure Enclave–backed credential is used correctly However, when using Automated Device Enrollment (ADE) with Simplified Setup, we observe different behavior: After device registration, Platform SSO triggers a login request to our IdP That request uses grant_type=password Instead of the expected urn:ietf:params:oauth:grant-type:jwt-bearer This occurs even though: The configuration specifies Secure Enclave as the authentication method The same configuration works as expected outside ADE Questions: Is this password grant during ADE / Simplified Setup an expected bootstrap flow? Is there any official documentation describing this? This behavior is currently undocumented, and clarification would help ensure correct IdP implementation.

I'm following up from an old existing post per the recommendation by DTS Engineer I'm referencing that comment specifically because i'm only able to reproduce this issue when using a device through browserstack. (a service that allows remote access to physical ios devices for testing, etc) I haven't been able to reproduce the issue on my physical device. When attempting to launch an ASWebAuthenticationSession using callback: .https(host: path:), The session immediately fails (before even presenting the web modal) with the error: Error Domain=com.apple.AuthenticationServices.WebAuthenticationSession Code=1 NSLocalizedFailureReason=Application with identifier com.builderTREND.btMobileAppAdHoc is not associated with domain test.buildertrend.net. Using HTTPS callbacks requires Associated Domains using the webcredentials service type for test.buildertrend.net. Which doesn't make sense, since our AASA file does specify that url and has the app ID listed in webcredentials Our app's entitlements file also contains webcredentials:*.buildertrend.net So it seems like everything is set up properly, but this issue is persistent.

Hi, I’m working with an SSO extension (ASAuthorizationProviderExtension) and am looking for clarification on how Apple determines whether the calling app is considered managed for ASAuthorizationProviderExtensionAuthorizationRequest.isCallerManaged. In my test, the authorization request is triggered from an app that is managed by our organization. We are using Jamf. However, in the SSO extension, I see the following caller metadata isCallerManaged=false I’d like to understand what conditions must be met for isCallerManaged to return true. Thanks.

On Sonoma beta 7, if system.login.screensaver is updated to use “authenticate-session-owner-or-admin”, and then Lock Screen is not hiding the macOS Desktop. Step1. Update system.login.screensaver authorizationdb rule to use “authenticate-session-owner-or-admin”( to get old SFAutorizationPluginView at Lock Screen ). Step 2. Once the rule is in place after logout and login, now click on Apple icon and select “Lock Screen”. Even after selecting Lock Screen, complete macOS Desktop is visible with no control for the user to unlock the screen. To gain access we have to restart the MAC.

tl;dr: The title and/or can I even add a keychain entitlement to a cli app? I'm trying to store a generated private key and certificate properly in a CLI app. The call to SecItemAdd always results in an error with message A required entitlement isn't present. I assume this is errSecMissingEntitlement, and its docs say it happens "when you specify an access group to which your app doesn’t belong". But I'm not even specifying one. Here's a small excerpt (I know it's not a MVCE but the question is pretty general anyway): func storeCert(_ cert: Data) throws { let addQuery = [ kSecClass: kSecClassCertificate, kSecValueRef: cert, kSecAttrLabel: CERT_USER_LABEL, kSecAttrApplicationLabel: CERT_APP_LABEL ] as [String: Any] let status = SecItemAdd(addQuery as CFDictionary, nil) guard status == errSecSuccess else { let msg = SecCopyErrorMessageString(status, nil) as String? ?? "" throw MyErr.generic(message: "Unable to store cert: \(msg)") } } I can't add the keychain entitlement to my CLI target, it doesn't show as an option in the add capability window. Disclaimer: I'm quite new to macOS / Apple development, so if there's something obvious I'm missing, my bad.

When implementing a custom right in macOS authorizationdb, the mechanism array element builtin:authenticate is displaying the message 'Enter the name and password of a user in the "(null)" group to allow this.' on the macOS credential prompt UI popup. I am trying to find a fix to avoid the reference to null group in the message label that is displayed just above the username and password input fields. The current plist uses class as the key and value as the evaluate-mechanisms. The mechanisms array includes mechanism array with elements "builtin:login-begin", "mycustombundle:mycustompreaction", "builtin:authenticate", "mycustombundle:mycustommechanism". I have tried specifying group in the plist, have tried setting hint in the MechanismInvoke for group, username, security, authority, prompt, reason among several other hints into the context duing the execution of mycustombundle:mycustompreaction, but none seem to fix the "(null)" in the message label. Any help is greately appreciated. There is not much of any documentation for developers implementing custom authorization in macOS.

Hi Apple Developer Community, Quick question — is there currently a way to disable the “Save Password” prompt in iOS while keeping AutoFill enabled? From what I can see, the only available setting under Settings → Passwords → Password Options controls AutoFill as a whole, with no option to turn off just the save prompt. I’m using a third-party password manager and would prefer to keep AutoFill but avoid the repeated prompts to save credentials. Has anyone found a workaround for this, or is this simply not configurable at the moment? Thanks!

Hi Apple Developer Community, Quick question — is there currently a way to disable the “Save Password” prompt in iOS while keeping AutoFill enabled? From what I can see, the only available setting under General → AutoFill & Passwords controls AutoFill as a whole, with no option to turn off just the save prompt. I’m using a third-party password manager and would prefer to keep AutoFill but avoid the repeated prompts to save credentials. Has anyone found a workaround for this, or is this simply not configurable at the moment? Thanks!

Apple's submission for FIPS140-3 (https://support.apple.com/guide/certifications/macos-security-certifications-apc35eb3dc4fa/web) has no mention of review for Intel or Intel T2 in FIPS Compliance on Tahoe. Is there any effort for this or will there be any effort? Has there any been any word that Intel as an architecture is completely out of the picture for FIPS140-3?

When an app is trying to access identities put in the keychain by cryptotokenkit extension, the user gets asked a permission pop-up which reads 'Token Access Request" would like access a token provided by: " with 2 options 'Don't allow' and 'OK' I accidently clicked "Don't allow" and now can't access identities put in crypto token kit. How can I reset the preference?

Hi, I created an app and want to use Google Admob to show ads. I am a little bit confused how exactly tracking, more specifically, the ATT-framework and Google Admob relate to each other. The current work flow is: ATT-permission given -> show google ad mob consent form However, I am confused what I should do if the ATT permission is denied. Can I still show the consent form of google admobs or is that forbidden? If so what do I need to then? Thank you!

I am using the CryptoTokenKit API in order to communicate with smart cards through NFC, with TKSmartCardSlotNFCSession. I call the createNFCSlotWithMessage method from TKSmartCardSlotManager, which displays successfuly the NFC dialog. However, when I put any smart card next to the phone, the NFC dialog shuts down instantly. I notice the following log in the system console: -[_NFReaderSession(Entitlement) validateAID:allowsPrefixMatch:]:317 Non-permissible identifier: A000000308000010000100 When I add the A000000308000010000100 AID mentioned in the error message to the Info.plist of my application, the NFC dialog does not shut down anymore and I am able to communicate with the smart card (using TKSmartCard). This behavior has been reproduced on an iPhone 16e, iOS 26.4. This AID does not correspond to anything in the smart card. It seems to be related to PIV, but this behavior also occurs with cards that are not PIV (PKCS#15...). Also, with an implementation using CoreNFC API instead of CryptoTokenKit API, this AID is not needed to be able to communicate with the card, so it seems CryptoTokenKit-specific. I did not find anything related to this in the documentation, have I missed something here ? Is this a special AID that is required all the time to work with NFC through CryptoTokenKit ?

Hello Apple Developer: I encountered some issues during development. I encrypted the secret key and stored it in the Keychain, but it failed when I tried to read it. I would like to ask if there is any problem with the code I wrote. Below is my code, including the storage and retrieval NSMutableDictionary *query = [[NSMutableDictionary alloc] initWithObjectsAndKeys:(id)kSecClassGenericPassword,(id)kSecClass, serviceID,(id)kSecAttrService, @YES,(id)kSecReturnData,nil]; CFTypeRef dataTypeRef = NULL; NSLog(@"SecItemCopyMatching"); OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)(query), &dataTypeRef); NSLog(@"SecItemCopyMatching end status = %d",status); if (status == errSecSuccess) { *privateData = CFBridgingRelease(dataTypeRef); return 0; }else{ return status; } NSMutableDictionary *attributespri = [[NSMutableDictionary alloc] initWithObjectsAndKeys: (id)kSecClassGenericPassword, (id)kSecClass, serviceID, (id)kSecAttrService, outData, (id)kSecValueData, nil]; CFTypeRef dataRef = NULL; OSStatus priStatus = SecItemAdd((__bridge CFDictionaryRef)attributespri, &dataRef); if (dataRef) CFRelease(dataRef); return priStatus == noErr;

Hi, In the app I’m working on, we rely on SecKeychainUnlock to verify that a password can be used to unlock the login keychain. When macOS 26.4 rolled out, we started getting bug reports that led me to a discovery that makes me think SecKeychainUnlock behavior was changed. I’m going to illustrate my findings with a sample code: #include <pwd.h> #include <stdio.h> #include <string.h> #include <unistd.h> #include <Security/SecKeychain.h> #pragma clang diagnostic ignored "-Wdeprecated-declarations" int main(void) { char password[100]; printf("password: "); scanf("%s", password); struct passwd *home = getpwuid(getuid()); if (!(home && home->pw_dir)) return 1; char path[1024]; strcat(path, home->pw_dir); strcat(path, "/Library/Keychains/login.keychain-db"); SecKeychainRef keychain = NULL; OSStatus result = SecKeychainOpen(path, &keychain); if (result != errSecSuccess) { fprintf(stderr, "SecKeychainOpen failed (error %d)\n", result); return 1; } SecKeychainStatus status = 0; result = SecKeychainGetStatus(keychain, &status); if (result != errSecSuccess) { fprintf(stderr, "SecKeychainGetStatus failed (error %d)\n", result); return 1; } if (status & kSecUnlockStateStatus) { printf("keychain is unlocked, will try to lock first\n"); result = SecKeychainLock(keychain); if (result != errSecSuccess) { fprintf(stderr, "SecKeychainLock failed (error %d)\n", result); return 1; } printf("SecKeychainLock succeeded\n"); } else { printf("keychain is locked\n"); } result = SecKeychainUnlock(keychain, strlen(password), password, TRUE); if (result == errSecSuccess) { printf("SecKeychainUnlock succeeded\n"); printf("password '%s' appears to be valid\n", password); } else { printf("SecKeychainUnlock failed (error %d)\n", result); printf("password '%s' appears to be invalid\n", password); } return 0; } Here are the outputs of this program on a machine running macOS 26.3 when provided with a correct password deadbeef and with an incorrect password foobar: testuser1@tahoe1 kcdebug % ./kcdebug password: deadbeef keychain is unlocked, will try to lock first SecKeychainLock succeeded SecKeychainUnlock succeeded password 'deadbeef' appears to be valid testuser1@tahoe1 kcdebug % ./kcdebug password: foobar keychain is unlocked, will try to lock first SecKeychainLock succeeded SecKeychainUnlock failed (error -25293) password 'foobar' appears to be invalid And here are the outputs of this program on a machine running macOS 26.4: testuser1@tahoe2 kcdebug % ./kcdebug password: deadbeef keychain is unlocked, will try to lock first SecKeychainLock succeeded SecKeychainUnlock succeeded password 'deadbeef' appears to be valid testuser1@tahoe2 kcdebug % ./kcdebug password: foobar keychain is unlocked, will try to lock first SecKeychainLock succeeded SecKeychainUnlock succeeded password 'foobar' appears to be valid I’m prepared to send a feedback with Feedback Assistant, but I would like to get a confirmation that this is indeed a bug and not an intended change in behavior. I would also like to know what are my options now. SecKeychainUnlock is just a means to an end; what I really need is the ability to keep the keychain password in sync with the user password when the latter is changed by our program. Thanks in advance.

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.

I've been trying over the past few days to use a PIV-programmed Yubikey to perform mTLS (i.e. mutual client cert auth) in my custom app. My understanding is that I need to feed NSURLSession a SecIdentity to do so. Yubico's instructions state that I need their Yubico Authenticator app for this, but this directly contradicts Apple's own documentation here. I dont need NFC/lightening support, and I only need support for my specific app. When I plug in my key to my iPhone and have TKTokenWatcher active, I DO see "com.apple.pivtoken" appear in the logs. And using Yubico's SDK, I CAN get data from the key (so I'm pretty sure my entitlements and such are correct). But using the below query to get the corresponding (fake? temporary?) keychain item, it returns NULL no matter what I do: let query: [String: Any] = [ kSecClass as String: kSecClassIdentity, kSecReturnRef as String: true, kSecAttrTokenID as String: "apple.com.pivtoken", // Essential for shared iPads kSecMatchLimit as String: kSecMatchLimitOne ] var item: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &item) "status" is always -25300 (which is "not found"). I've also created a CTK extension (as Yubico's authenticator does) and tried to use self.keychainContents.fill(), and then tried to access it with kSecAttrTokenID as ":Yubico YubiKey OTP+FIDO+CCID", as that's what shows via TKTokenWatcher, and this also doesn't work. I've also tried just the app extension ID, and that doesn't work. Both my extension and my main app have the following entitlements: <key>com.apple.developer.default-data-protection</key> <string>NSFileProtectionComplete</string> <key>com.apple.security.application-groups</key> <array/> <key>com.apple.security.smartcard</key> <true/> <key>keychain-access-groups</key> <array> <string>$(AppIdentifierPrefix)com.apple.pivtoken</string> <string>$(AppIdentifierPrefix)myAppExtensionId</string> </array> As one final test, I tried using the yubikey in safari to access my server using mTLS, and it works! I get prompted for a PIN (which is odd because I've programmed it not to require a PIN), but the request succeeds using the key's default PIN. I just cannot get it working with my own app. Can anyone here (or preferably, at Apple) point me in the right direction? I have a feeling that the documentation I've been reading applies to MacOS, and that iOS/ipadOS have their own restrictions that I either need to work around, or which prevent me from doing what I need to do. It's obviously possible (i.e. the Yubico Authenticator sort of does what I need it to), but not in the way that Apple seems to describe in their own documentation.

Can a macOS Platform SSO extension reliably identify the original app behind a Safari or ASWebAuthenticationSession-mediated request, or does ASAuthorizationProviderExtensionAuthorizationRequest only expose the immediate caller such as Safari ? We are seeing: callerBundleIdentifier = com.apple.Safari callerTeamIdentifier = Apple audit-token-based validation also resolves to Safari So the question is whether this is the expected trust model, and if so, what Apple-recommended mechanism should be used to restrict SSO participation to approved apps when the flow is browser-mediated.

Xcode 26.x + iOS 26.x MTE Compatibility Feedback Reporter：Third-party App Developer Date：2026 Environments：Xcode 26.2 / 26.4, iOS 26.2 / 26.4 SDK, iPhone 17 Pro, Third-party App (Swift/C++/Python/Boost) Core Issue MTE (Memory Tagging Extension) under Memory Integrity Enforcement generates extensive false positives for valid high-performance memory operations in third-party apps, causing crashes. No official configuration exists to bypass these false positives, severely impacting stability and development costs. Key Problems 1. Widespread False Positives (Valid Code Crashes) After enabling MTE (Soft/Hard Mode), legitimate industrial-standard operations crash: Swift/ C++ containers: Array.append, resize, std::vector reallocation Custom memory pools / Boost lockfree queues:no UAF/corruption Memory reallocation:Legitimate free-reuse patterns are judged as tag mismatches. 2. MTE Hard Mode Incompatibility iOS 26.4 opens MTE Hard Mode for third-party apps, but it immediately crashes apps using standard high-performance memory management. No whitelist/exception mechanism for third-party developers. 3. MTE Soft Mode Limitations Detects far fewer issues than actual memory corruption reports. Only generates 1 simulated report per process, hiding multiple potential issues. Impact Stability: Apps crash in production when MTE is enabled. Cost: Massive code changes required to abandon memory pools/lockfree structures for system malloc. Ecosystem: Popular libraries (Python, Boost) are incompatible. Recommendations Optimize MTE rules: Add system-level exceptions for valid container resizing and memory pool operations. Provide exemptions: Allow per-region/module MTE exceptions for high-performance modules. Support runtimes: Officially support common third-party runtimes (Python/Boost) or provide system-level exemptions. Improve debugging: Increase MTE Soft Mode coverage and allow multiple reports per process.

Hello, I am using the prf extension for passkeys that is available since ios 18 and macos15. I am using a fixed, hardcoded prf input when creating or geting the credentials. After creating a passkey, i try to get the credentials and retrieve the prf output, which works great, but i am getting different prf outputs for the same credential and same prf input used in the following scenarios: Logging in directly (platform authenticator) on my macbook/iphone/ipad i get "prf output X" consistently for the 3 devices When i use my iphone/ipad to scan the qr code on my macbook (cross-platform authenticator) i get "prf output Y" consistently with both my ipad and iphone. Is this intended? Is there a way to get deterministic prf output for both platform and cross-platform auth attachements while using the same credential and prf input?