DeviceCheck query_two_bits returns last_update_time in the future — what could cause this?

Question

Created 4d

Replies 1

Boosts 0

Participants 2

Hi everyone,

I'm integrating Apple's DeviceCheck API into my app and have run into a strange issue that I can't find documented anywhere.

The Problem

When I call Apple's DeviceCheck query endpoint (POST https://api.devicecheck.apple.com/v1/query_two_bits), the response occasionally returns a last_update_time value that is in the future — ahead of the current server time.

Example response: { "bit0": true, "bit1": false, "last_update_time": "2026-05" // future month, not yet reached }

What I've Checked

My server's system clock is correctly synced via NTP
The JWT token I generate uses the current timestamp for the iat field
This doesn't happen on every device — only on some specific devices
The issue is reproducible on the same device across multiple calls

Questions

Is last_update_time sourced from the device's local clock at the time update_two_bits was called? Or is it stamped server-side by Apple?
Could a device with an incorrectly set system clock (set to the future) cause Apple's servers to record a future last_update_time?
Is there a recommended way to validate or sanitize last_update_time on the server side to handle this edge case?
Has anyone else encountered this behavior? Any known workarounds?

Any insight would be greatly appreciated. Thanks!

Boost

Answer 1

Engineer OP

Apple

4h

We believe this might be a bug in DeviceCheck for an edge case you seem to be running into, and the team would appreciate a Bug Report for this in order to investigate the cause and issue a fix or suggest a workaround.

We would also require a diagnostic log from the device to see if this is indeed a bug or a device side anomaly. If you can please run your app and/or take the actions for the device to record a last_update_time, and once that is done create a sysdiagnose following these instructions. If the problem devices are only in the hands of your users, then please send as much details and logs from your server side communications. If you are able to provide it, the first time stamp for when update_two_bits was sent for this device and wrong last_update_time returned by the last query_two_bits would be essential information.

Once you have created the bug report and added the relevant information, please share the Feedback ID here, and @mention me in your reply so I can pass on the information to the DeviceCheck team right away.

0