Hello, Since we enabled App Attest in our production app on Aug 13, 2026, a small subset of users consistently fails attestation with DCError.invalidKey. For multiple confirmed devices the failure appears to be permanent: attestKey rejects even newly generated keys, and reinstalling the app, rebooting the device, or updating the app does not help. Environment Production builds from the App Store, real devices only, production App Attest environment Attestation succeeds for the vast majority of users (about 70,000 keys registered so far) Primary case (user-reported, verified end to end): iPhone XS Max, iOS 17.6.1, region US. 34 invalidKey events since Aug 13; no attestation record on our server; reinstall and reboot did not help Other devices showing the same persistent pattern in our internal logs (each of these reported invalidKey exclusively): iPhone X, iOS 16.7.16: 69 events over 16 days iPhone X (a second device), iOS 16.7.16: 60 events over 17 days iPhone 8, iOS 16.7.16: 12 events over 7 days iPhone XR, iOS 18.7.9: 11 events over 7 days We also see a smaller number of devices failing persistently with unknownSystemFailure instead of invalidKey, for example an iPhone XR on iOS 18.6.2 with 39 events over 15 days In our internal logs, App Attest errors in general appear across a range of iOS versions and devices Implementation flow DCAppAttestService.shared.generateKey attestKey(_:clientDataHash:) with a SHA-256 hash of a server-issued nonce On failure we retry up to 3 times, with backoff intervals of 0.5, 1, and 2 seconds. For DCError.invalidKey, each retry discards the previous key and generates a brand-new key before calling attestKey again; for serverUnavailable we retry with the same key and clientDataHash, per the DCError header guidance Error characteristics For the affected device, all 3 attempts fail with DCError.invalidKey (com.apple.devicecheck.error code 3), even though every attempt uses a newly generated key ID The failure has persisted continuously since Aug 13, 2026 (19 days and ongoing at the time of writing) App reinstall and device reboot do not resolve it, and the failure has persisted across three consecutive app versions Our server has no attestation record for this user at all, so the key has never been successfully attested; this is not a case of a stale or previously attested key being reused The device supports App Attest. For some users of our sibling app in Japan the same error was transient: they hit invalidKey and then attested successfully later, so invalidKey is clearly transient in some cases but appears permanent in others Scale Our internal logs show 478 attestation-failure events from 61 users between Aug 13 and Sep 1, across all DCError codes Of those, at least 298 events from 30 users are invalidKey, roughly 0.01 percent of our active users (about 360,000) What we have ruled out Key reuse: every retry generates a fresh key clientDataHash handling: identical code succeeds for 99.99 percent of users Server-side verification: the failure happens client-side in attestKey, before our server is ever contacted Account state: the affected user is in good standing Questions Under what conditions can attestKey return invalidKey for a freshly generated key? The documentation describes invalidKey as an invalid key identifier, but here the key ID comes directly from a just-completed generateKey call. Is there any known device-side or Apple-server-side state that can cause a specific device to fail attestation persistently (for weeks, across reinstalls and reboots)? If so, is there anything the user or we can do to remediate it? Is there a recommended way to distinguish between a transient failure, a permanent device-level failure, and an Apple-side service issue, or to get more diagnostics for these failures in production? The NSError carries no information beyond the DCError code, which does not seem to differentiate these cases. Is the guidance from earlier threads (for example thread 812308) still current, that is: should we treat a device that persistently fails attestation as if App Attest were unsupported and fall back accordingly? We are hesitant because that fallback becomes an obvious bypass path for bad actors. Could this be related to throttling or rate limiting of attestKey? Our retries are capped at 3 attempts per verification flow, with 0.5 to 2 second backoff. Any insight would be greatly appreciated. Thank you.