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.
