Hi Quinn, Thanks for your previous explanation. After further investigation, I realized that our Keychain item structure might be related to the issue, so I’d like to share more details in case this helps narrow down the cause. How we currently store data in a single Keychain item For the same Keychain item, we store two different business values: kSecValueData → contains the deviceId kSecAttrAccount → contains a dynamic userKey This means the item looks like this: Service: <fixed service name> Account: <userKey> // changes when user switches account Value: <deviceId> kSecAttrAccessible: kSecAttrAccessibleAfterFirstUnlock Potential problem we’ve discovered Because the userKey (stored in kSecAttrAccount) can change over time, our update operation may unintentionally rewrite or merge attributes in a way that leaves some users with inconsistent Keychain item metadata. For example: Version A of the app may write incorrect or incomplete attributes. Version B fixes the attributes, but existing users still keep the old item with mismatched attributes. The item may end up with: a different account name than the app expects missing or incorrect accessible settings values written by older versions of the app In this state, the item sometimes becomes readable in the foreground but fails in the background with:errSecInteractionNotAllowed (-25308) My question From your experience, could this type of Keychain item design— storing two business values (deviceId + userKey) inside the same item and allowing attributes like kSecAttrAccount to change across app versions— lead to the kind of attribute inconsistency that causes background reads to fail even when kSecAttrAccessibleAfterFirstUnlock has been set correctly in the latest version? If this pattern is unsafe, we are considering splitting it into two independent Keychain items: One item dedicated to deviceId A separate item for userKey Each item with stable kSecAttrAccount and fixed attributes Plus a migration mechanism to repair old inconsistent records Before implementing this migration, I’d like to confirm whether this theory aligns with how Keychain attributes are expected to behave internally, especially across updates. Any further guidance you can provide would be greatly appreciated. Thanks again for your time and expertise! Share and Enjoy, — Yvan