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.
We've filed FB22448572 for this
Thanks. That’s the best path forward for this.
Is there a known issue with securityd’s keychain authentication after 26.4?
Well there is now that you’ve filed a bug about it (-:
Seriously though, as I mentioned on that other thread you found, macOS 26.4 has significant changes to how we unlock the login keychain. In that thread, the developer is doing something unusual, and it’s not clear what the right path forward is. But in your case my understanding is that you’re doing something pedestrian — accessing a keychain item from early in your app’s lifecycle — and that makes the path forward clear: File a bug so that the keychain team can investigate. Which is what you’ve done (-:
Would migrating to the data protection keychain … avoid this class of issue entirely?
It’s hard to be 100% sure without knowing exactly what’s causing the problem, but I think it’s very likely that the answer to your question is is “Yes.”
Additionally, moving to the data protection keychain is a good idea regardless. So, unless there’s something blocking you from doing that [1], it’s something to consider.
Of course, writing, testing, and deploying that code isn’t trivial. And you’ll likely want a mechanism to migrate your keychain items from the login keychain to the data protection keychain, and that code might hit exactly this issue )-:
kSecAttrAccessible instead of kSecUseKeychain
Just to be clear, the best way to enable the data protection keychain is kSecUseDataProtectionKeychain. Once you do that, you can then use attributes, like kSecAttrAccessible, that are specific to that keychain.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] TN3137 describes one case where that’s not possible, namely, where you need to use the keychain from a daemon. That doesn’t apply here, but I can imagine there are other cases that I’ve not thought about.
