Topic starter
21/10/2026 2:46 pm
TL;DR: Native app attestation across iOS, Android, and HarmonyOS still leaves policy gaps when devices are unsupported or the signal is spoofed, according to Approov. Mobile API protection still needs secret custody and backend enforcement alongside device checks.
Editorial analysis by NHI Mgmt Group, based on content published by Approov: “Why Native Hardware Attestation Falls Short and How to Enhance It”.
Key questions
Q: Why do embedded API keys create risk even when attestation succeeds?
A: Because attestation proves something about the environment, not about whether the app binary contains extractable credentials.
Q: How can security teams measure whether mobile app attestation is working?
A: Look for blocked requests from repackaged clients, fewer anomalous device fingerprints, and lower success rates for scripted API abuse.
Q: What breaks when mobile attestation is treated as the only trust signal?
A: The control breaks at the point where the device signal is separated from secret custody and backend enforcement.
Practitioner guidance
- Replace embedded API keys with attestation-gated secret delivery Issue secrets only after a runtime trust decision succeeds, and keep them short-lived so the app binary never contains reusable backend credentials.
- Unify mobile trust policy across supported platforms Create one backend policy layer that consumes Android, iOS, and HarmonyOS attestation outputs instead of maintaining separate verdict handling in each integration path.
- Define explicit fallback rules for unsupported or low-assurance devices Document whether the app blocks, degrades, or uses an alternate verification path when GMS is absent, a TEE is unavailable, or the attestation tier is weak.
Bottom line: Native attestation improves confidence in mobile app requests, but it does not eliminate the need for secret custody, backend policy, and runtime validation.
Glossary terms: Device Attestation, Software Attestation, Attestation-Gated Secret Delivery, Certificate Pinning
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
23/10/2026 12:48 am
Mobile app trust has become a layered identity problem, not a device-only problem. Native attestation is useful evidence, but it is not equivalent to continuous application identity or backend trust. Once secrets, certificates, and tokens are distributed to mobile clients, the security question becomes how the backend decides whether to honour them. Practitioners should therefore treat app trust as a governed control plane spanning app, device, and API.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: What is the difference between hardware attestation and software attestation in mobile security?
A: Hardware attestation checks platform-backed device signals such as TEE-backed integrity evidence, while software attestation checks the running app instance, often by analysing live memory and code state. Hardware evidence is useful but easier to fragment across ecosystems. Software attestation helps close the gap when the device signal is spoofed or unavailable.
👉 Read our full editorial: Native app attestation still leaves mobile API gaps exposed
This post was modified 3 days ago by NHI Mgmt Group