Notifications
Clear all
Topic starter
19/08/2026 3:45 pm
TL;DR: Remote Key Attestation can relay attestation requests through a remote device, letting attackers spoof Android device trust signals and weaken deterministic checks built around Key Attestation, according to Guardsquare’s analysis. The real issue is not attestation alone but backend verification, key provenance, and relay detection across device identity flows.
NHIMG editorial — based on content published by Guardsquare: Bypassing Key Attestation: How Remote Devices Exploit the API
Questions worth separating out
Q: How should mobile security teams handle attestation when devices can relay trust signals?
A: Treat attestation as one evidence source, not proof of device integrity.
Q: Why do long-lived attestation keys create more governance risk than short-lived keys?
A: Long-lived keys expand the time attackers have to reuse leaked material before revocation catches up.
Q: What breaks when mobile apps trust attestation responses without backend correlation?
A: The app loses the ability to tell whether the response came from the requesting device or from a proxy device.
Practitioner guidance
- Correlate attestation with device context Track nonce, app identity, hardware lineage, and environment signals together so a valid response is not accepted in isolation.
- Flag reused or cross-device key patterns Build rules that detect when the same attestation key, key serial, or device fingerprint appears across unrelated devices or vendors.
- Shorten the lifetime of trust assumptions Prefer short-lived, remotely provisioned trust material where available and remove reliance on legacy fused keyboxes as soon as the platform allows it.
What's in the full article
Guardsquare's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how keyboxes are relayed from one device to another in real attack setups
- Technical comparison of legacy fused keys versus remote provisioning in the Android attestation model
- Backend monitoring patterns for spotting key reuse, device drift, and suspicious attestation spikes
- Practical guidance on when app attestation should complement Key Attestation in production workflows
👉 Read Guardsquare's analysis of Remote Key Attestation abuse and Android trust bypass →
Remote key attestation abuse: are mobile trust controls keeping up?
Explore further
19/08/2026 4:22 pm
Remote attestation is now an identity signal, not just a device-health check. Once the attestation response can be relayed, the control is no longer proving locality of the device but only proving that some trusted material was available somewhere. That is a governance problem as much as a technical one, because identity decisions are being made on evidence that may not belong to the presenting device. Practitioners should treat attestation as one input into a broader trust model, not as a standalone access decision.
A question worth separating out:
Q: How do security teams reduce the risk of relayed device identity in mobile authentication flows?
A: Use attestation as a signal to score, not a gate to trust blindly. Enforce backend validation, compare device behaviour over time, and remove legacy trust anchors that can be copied, replayed, or hidden behind relay infrastructure.
👉 Read our full editorial: Remote key attestation abuse exposes mobile trust assumptions
