Throwing an update here: after migrating our code from the deprecated SecKeychain API, and removing the SeyKeychainOpen before querying the keychain, we have not seen these prompts show anymore. This was tested on machines running both macOS 26.7 and macOS 27.0.1. I can't confirm if it stopped showing because our code fix, or because newer OS versions (26.7/27.0), or because a silent update pushed (I know that Apple supports "security updates" but I've never seen it happening). Maybe Quinn can confirm.

Thanks Quinn, this is really helpful. I've filed the bug: FB24637565. It includes the securityd crash report and a sysdiagnose taken after reproducing, and - as you suggested - it calls out that Apple's own airportd triggers the same CSSMERR_DL_INVALID_DB_HANDLE and takes securityd down, with no third-party software involved in the crash window. We've also read TN3137 - thanks for pointing to it. Your guidance lines up with what we've done: we've moved to the SecItem API and off the deprecated SecKeychain* calls, and since parts of our product run outside a user context we're staying on the file-based (System) keychain rather than attempting a data-protection migration in a bug-fix release. In parallel, we're also engaging Apple through AppleCare Enterprise for additional help on this (case 20000149598654), so the two efforts can reference each other. Thanks again for the quick, detailed responses.

Quick follow-up with a new data point that I think matters for root cause. After migrating our app fully off the legacy SecKeychain*/CSSM path, we still saw securityd crash on this machine, so I went digging into who else was hitting it. It turns out Apple's own airportd triggers the exact same CSSMERR_DL_INVALID_DB_HANDLE and takes securityd down, with our app completely out of the picture. Here's a clean example from this machine (macOS 26.6.2, 25G83). In this window our agent logged nothing at all - the only thing hitting the error was airportd (pid 634): 04:26:44.933 airportd[634] (Security) [com.apple.securityd:security_exception] CSSM Exception: -2147413942 CSSMERR_DL_INVALID_DB_HANDLE 04:26:53.249 airportd[634] (Security) [com.apple.securityd:security_exception] CSSM Exception: -2147413942 CSSMERR_DL_INVALID_DB_HANDLE 04:27:03.883 airportd[634] (Security) [com.apple.securityd:security_exception] CSSM Exception: -2147413942 CSSMERR_DL_INVALID_DB_HANDLE 04:27:15.110 airportd[634] (Security) [com.apple.securityd:security_exception] CSSM Exception: -2147413942 CSSMERR_DL_INVALID_DB_HANDLE securityd was then corpsed at 04:27:20 and relaunched at 04:27:26. We've counted 22 securityd crashes on this machine this week, crash-looping (consecutiveCrashCount reached 17), all EXC_BAD_ACCESS (SIGSEGV) at 0x0. This reframes the root cause a bit: our leaked legacy handles were a contributor, but they aren't required to crash securityd on 26.6.x — a first-party daemon (airportd) hits the identical error on its own. That fits the theory that the 26.4/26.6 file-based-keychain changes made stale/invalid DL/DB handle use fatal for any CSSM client, Apple's included. It also explains why our fix removed our contribution but didn't fully stop the prompts/crashes: something else on the system keeps knocking securityd over. Does the airportd repro change your read on root cause - i.e. is this a securityd/CSSM regression in 26.6.x rather than something specific to third-party keychain use?

Thanks Quinn - answering your questions and sharing what we've since found. The alert is the standard macOS login keychain prompt, here's an example from an unrelated app to our app: Regarding the crash report: yes, Apple Support captured a securityd crash on an affected machine (securityd-2026-08-20-105000.ips). The key frames: `Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000 (Security) [com.apple.security:seckey] SecKeyCreateSignature failed: Error Domain=NSOSStatusErrorDomain Code=-67680 "CSSM Exception: -2147413942 CSSMERR_DL_INVALID_DB_HANDLE" (Security) [com.apple.securityd:integrity] dbBlobVersion() failed for a CssmError: 1 unknown error 1=1` Here are two example .ips crash files after reproducing the issue on my own machine. securityd-2026-09-02-113000.ips securityd-2026-09-01-160001.ips We believe we identified the root cause and would like you to confirm. Our cert-lookup code used the legacy CSSM APIs: SecKeychainOpen (and SecKeychainCreate in one path) to open keychains by file path, then queried with kSecMatchSearchList. The opened keychain refs were never released (no CFRelease), so each lookup leaked a DL/DB handle into securityd. Our theory is that those leaked/stale DB handles are what surface as CSSMERR_DL_INVALID_DB_HANDLE and eventually crash securityd. Once securityd is down, macOS falls back to prompting for the login keychain password - which explains why unrelated apps got hit too (they weren't the cause, they were just the next thing to touch the keychain after the crash). This lines up with our two workarounds: a clean reinstall resets the state and delays the buildup, and setting the item ACL to "allow all applications" removes the repeated per-app access checks that were driving the lookups. We believe this issue is tied to 26.6.x specifically because it's the same binary, unchanged for a long time - we only started seeing this after machines moved to 26.6.x. That also matches Apple's release notes on macOS 26.6 mentioning Keychain CVEs specifically. On earlier macOS the same code didn't crash securityd. To be clear on your endpoint-security question: we're a network/VPN agent (with a system/network extension), not doing anything that should be poking securityd on a loop - the keychain calls are only our own client-cert lookups. We currently applied a fix that migrated every cert-lookup path off SecKeychain*/CSSM to SecItemCopyMatching. Where we still need user-vs-system scoping, we build the search list via SecKeychainCopyDomainSearchList rather than opening keychains by path, so no keychain refs are held or leaked. After this, the leak is gone and we no longer reproduce the crash or the prompts. What we'd like confirmed: Is our root cause plausible from your side? Do the leaked legacy SecKeychain* DB handles driving CSSMERR_DL_INVALID_DB_HANDLE / the securityd SIGSEGV, made fatal by the macOS 26.4/26.6 keychain changes? Is fully moving to SecItem* (default keychain, no SecKeychain*) the right long-term direction, or is there extra guidance for apps that still need to scope lookups to a specific keychain? Thanks again.

@DTS Engineer Thanks for the reply. I've already seen apps with similar behavior (popover with a menu bar icon) that do not dimiss the menu bar in full-screen. I wish to achieve the same behavior.