Thanks for the help. Looks like SecItemUpdate is not affected by this issue, so we ended up with the following solution: for modifications use SecItemUpdate instead of SecItemDelete + SecItemAdd for cleanup use SecItemUpdate with an empty data as a fallback when SecItemDelete fails

I can reliably reproduce the same issue: SecItemDelete returns errSecInvalidOwnerEdit after renaming the app bundle. This is a rename in the Finder, right? And the app is not running at the time you do the rename? Yes, a simple rename in Finder is enough to break this. Another use case is for app to copy itself under a different name using FileManager.default.copyItem(at:to:). In this case, the app is running at the moment of copying. The copy won't be able to modify any pre-existing keychain items due to the same error. And the app is signed, right? Is this Developer ID signing? Or is this a Mac App Store app? The app is signed using Developer ID and notarized.