Thanks for the response - that's helpful. I've been able to drill down a little more and I now believe it's down to a Keychain change that I made which appears to have manifested itself after a device restart. The upgrade to 18.3.1 is likely a red herring - it's just that these days that's the only time many people do a restart. FWIW, what I did was add access control attributes to further constrain some code that stores and retrieves token values from the keychain. The expectation was that this would a) only provide the token while the device was unlocked and b) avoid using an existing token when the biometry set was changed. var error: Unmanaged<CFError>? defer { error?.release() } return SecAccessControlCreateWithFlags( nil, kSecAttrAccessibleWhenUnlockedThisDeviceOnly as CFString, [.biometryCurrentSet], &error ) } Previously, I was using: kSecAttrAccessible as String: kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly, in the attributes. One some devices this seems to be causing a Face Id check to appear for each query for the current value. It's curious to me that it's not happening on all devices on which I test, though. If it's inconsistently manifesting on fresh installs on different devices, while I wouldn't expect it given the 'this device only' directive, I still suspect it's possible there's some remnant data clouding the waters here due to further misunderstandings on my part.

So, the idea I propose above isn't particularly viable, since we'd still be left with a key in the dev environment that can be used to send production pushes. So, what are the options here for isolating production keys? This seems like a very odd decision by Apple to not provide the ability to create a key that can only be used for sandbox pushes, unless I'm missing something.