Thanks for the answer — it covers the app-transfer case clearly. I have a related question that this answer doesn't cover, and I'd like to confirm it before building a two-team test setup. Setup: two independent developer accounts (Team A and Team B), with no app transfer involved. Question: an app signed under Team A calls DCDevice.current.generateToken(). Can a backend authenticating with Team B's DeviceCheck private key and iss (Team B's Team ID) redeem that device_token — e.g. POST /v1/query_two_bits? Or is a device_token bound to the team that minted it, so such a request must fail? Two follow-ups: If Team B presents a token minted under Team A, does the failure occur at the auth layer (401 "Unable to verify authorization token") or at the token-validation layer (400, e.g. invalid device token)? That distinction tells me whether Apple even attempts to resolve the token cross-team. Are the two bits for the same physical device stored separately per team, so Team B could never read what Team A wrote? The transfer answer says the state "persists across the transfer" — I want to be sure that doesn't imply the bits are app-scoped rather than team-scoped. What I've already verified against the live API, so I don't waste anyone's time: no Authorization header gives 400 "Missing or badly formatted authorization token"; a malformed JWT gives 401 "Unable to verify authorization token"; a well-formed ES256 JWT signed with a self-signed (unregistered) key plus a dummy device_token gives 401; update_two_bits with the correct field names (bit0/bit1) gives 401 as well. So the auth layer is behaving correctly for unregistered keys — the only remaining variable in my test is the team/key pairing. Happy to attach a redacted curl repro once I have both teams live. Thanks!