Hi, I’m a colleague of @alemazz_pa and wanted to add more production data on this issue. Thank you for the explanation regarding error semantics and the iOS 17.0/17.1 known bug. Our main concern is Error 3 (invalidKey): It affects a large population (~70,000 users) in our telemetry. We also observe it on recent devices / OS versions (for example iPhone 17 Pro on iOS 26), so it does not appear limited to devices that were “stuck” before iOS 17.1. For a subset of users, reinstalling the app does not recover. The failure can be persistent for the same app instance. Given this, could you help clarify whether invalidKey in practice can also represent server-side key state mismatches beyond local key corruption? Specifically, documentation mentions that: generateAssertion(_:clientDataHash:completionHandler:) may fail if called with an unattested key. Could there be cases where a key that was previously generated+attested later becomes unusable (for example attestation state no longer recognized), resulting in invalidKey? If yes, we’d appreciate guidance on: Whether re-attestation is expected/allowed for an existing keyId, or if a full new key lifecycle is required. Recommended recovery strategy for persistent invalidKey on modern iOS versions (fallback, key rotation policy, cooldown/backoff). Any extra diagnostics/telemetry fields we can log. We’re happy to provide additional anonymized aggregates (OS distribution, device classes, failure persistence patterns) if useful. Thanks again for the support.