Hardware-backed keys miss the app-layer trust gap in Android security

At a glance

What this is: This analysis argues that hardware-backed Android security protects keys well, but leaves a gap when TLS and app logic operate outside the hardware trust boundary.

Why it matters: It matters because IAM and security teams increasingly need to govern device trust, application attestation, and runtime identity signals, not just secret storage.

By the numbers:

• StrongBox is available on only 8.7% of premium-tier Android devices.
• StrongBox is available on only 7.2% of medium-tier Android devices.
• StrongBox is available on only 0.2% of low-tier Android devices.

👉 Read Arxan Technologies' analysis of Android hardware security and app-layer trust gaps

Context

Android hardware security protects keys well, but it does not automatically protect the application trust path that uses those keys. In practice, many mobile apps still rely on software TLS stacks, protocol logic that can be reverse engineered, and runtime environments that may never touch the hardware vault at all. That creates an identity and access problem at the app boundary, not just a secret storage problem.

For identity and security teams, the important question is whether the client can prove both device integrity and application integrity before it is allowed to act as a trusted caller. This is especially relevant where mobile apps function as non-human identities or as the front end for authenticated API access. The starting position described in the article is common rather than exceptional: strong hardware controls exist, but they often do not cover the full request path.

Key questions

Q: How should security teams govern mobile apps that sit inside identity workflows?

A: Treat mobile apps as part of the trust path, not just the user interface. Teams should verify which apps handle authentication, what data they collect, which SDKs they embed and where they send telemetry. That gives IAM, fraud and security teams the context needed to judge whether the application layer is weakening the identity control they think they have.

Q: Why do hardware-backed passkeys strengthen authentication in mobile environments?

A: Hardware-backed passkeys reduce phishing risk because the credential is cryptographically bound to the intended origin and cannot be replayed on a look-alike site. They also improve resistance to adversary-in-the-middle attacks when the client verifies the requesting browser or app before any signing occurs, limiting credential use to approved channels.

Q: What are the signs that app-layer trust controls are failing?

A: Look for legitimate-looking requests from modified clients, unexpected replay patterns, inconsistent device integrity results, and API calls that succeed even when the application binary has been tampered with. Those signals indicate the server is trusting device status more than it is validating the caller’s runtime integrity.

Q: What should teams do when device integrity and app integrity point to different risk levels?

A: Use the lower-confidence signal to cap trust, not the higher-confidence one to override it. If the device looks clean but the app is modified, the request should be stepped up, restricted, or denied. High-risk API access should require both device assurance and app assurance to align before trust is granted.

Technical breakdown

Why hardware-backed keys do not protect every Android request

StrongBox and TEE-backed keystores protect private keys by generating and using them inside secure hardware. That model works when the cryptographic operation itself is routed through the vault. But standard Android network stacks often use BoringSSL and Conscrypt in software for TLS, so session keys and handshake material exist in memory outside hardware protection. In other words, the secure vault protects the key, but not necessarily the protocol path that authenticates the session.

Practical implication: map which app flows actually use hardware-backed key operations and treat all software TLS paths as separately governed trust surfaces.

How reverse engineering shifts the attack from keys to protocol logic

If attackers cannot easily extract a key, they often target the app binary, disassemble it, and study how the client authenticates to the server. That exposes handshake structure, token handling, API sequencing, and replay assumptions. Once the protocol is understood, a modified client can mimic legitimate behaviour without ever touching the original device or hardware key store. The attack is no longer about breaking key protection. It is about reproducing the trusted client logic well enough for the server to accept it.

Practical implication: combine binary hardening, protocol binding, and request validation so server trust does not depend on client obscurity.

What app-layer attestation adds beyond device integrity checks

Device attestation tells you something about the device state, but it does not always tell you whether the app itself is modified or whether the request was replayed through a synthetic client. App-layer attestation is a stronger model for this problem because it binds cryptographic proof to protected app logic and runtime integrity. In identity terms, the server is not just checking a device. It is checking whether the caller is the expected application in the expected execution state.

Practical implication: require app-bound request proofs for high-risk APIs and use device attestation only as one input into the trust decision.

NHI Mgmt Group analysis

Hardware security is necessary, but it is not sufficient for mobile identity trust. The article exposes a familiar governance mistake: treating key protection as equivalent to client trust. In reality, the trust boundary for mobile applications includes the binary, the protocol, and the runtime environment, not just the vault. That distinction matters whenever a mobile app is acting as a caller into sensitive APIs or identity-bound services. Practitioners should treat hardware-backed key storage as one control in a larger client assurance model.

App-layer trust is the named control gap here. The article effectively defines a gap where secure hardware exists, yet the request path still permits forged clients, repackaged binaries, or replayed handshakes. That is a governance problem because the server is asked to trust a client identity that may not have been verified at the application layer. The practical lesson is that strong hardware does not remove the need for runtime integrity, request binding, and tamper detection.

Mobile applications increasingly behave like non-human identities and should be governed that way. When an app authenticates to a service, it is effectively presenting a machine identity with behavioural expectations. That makes the intersection with NHI governance real, not theoretical. Lifecycle control, attestation, revocation, and trust scoping all matter when the app can be modified or cloned. The right frame is not just mobile app security but governed client identity.

Fragmented hardware coverage changes the assurance strategy for Android populations. The article’s point about device variability means teams cannot assume uniform hardware trust across their user base. That makes architecture choices, not just tooling choices, the deciding factor. Programs that rely on StrongBox as the primary assurance layer will still need fallback controls, policy differentiation, and risk-based trust decisions. Practitioners should design for heterogeneous device assurance rather than a single hardware standard.

App protection and identity assurance are converging in API security. As more sensitive workflows move through mobile clients, the server-side decision is no longer just authentication versus no authentication. It is whether the client can prove it is genuine, unmodified, and executing expected protocol logic. That aligns with broader zero trust thinking and with NIST CSF and NIST SP 800-53 control families around access control, authentication, and system integrity. Teams should align client assurance with API risk, not with device marketing claims.

From our research:

• StrongBox is available on only 0.2% of low-tier Android devices, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why client-side trust assumptions keep failing in practice.
• For a broader identity control lens, see NHI Lifecycle Management Guide for lifecycle governance across provisioning, rotation, and offboarding.

What this signals

App-layer trust debt: Mobile programmes that rely on hardware security alone are accumulating an assurance gap between device posture and application integrity. Teams should expect more scrutiny of request binding, tamper resistance, and runtime proof before sensitive API calls are accepted.

The strategic shift is toward caller identity that can be continuously validated, not assumed at session start. That will force mobile, IAM, and API security teams to coordinate on revocation, attestation, and policy enforcement rather than leaving each control layer to operate in isolation.

For practitioners

• Inventory which mobile flows actually depend on hardware-backed keys Separate flows that use StrongBox or TEE-backed operations from flows that still rely on software TLS and ordinary keystore handling. That distinction tells you where hardware assurance ends and where additional controls must begin.
• Bind high-risk API requests to app integrity signals Require proof that the request came from an unmodified application, not only from a device with acceptable posture. Use nonce-based request binding, replay resistance, and server-side validation of app integrity where the business impact justifies it.
• Treat reverse engineering as a protocol risk Assume attackers can inspect the binary, learn the handshake, and replicate client behaviour. Harden protocol design, reduce static secrets in the client, and review whether the server trusts patterns that a modified app could reproduce.
• Use device attestation and app attestation together Do not let device integrity checks carry the whole assurance burden. Combine device posture with app-layer attestation so the trust decision reflects both the device and the application executing on it.

Key takeaways

• Hardware-backed key storage is valuable, but it does not secure every part of the mobile trust path.
• The real failure mode is app-layer impersonation, where modified clients can reproduce legitimate request patterns without touching the hardware vault.
• Security teams should align device attestation, app attestation, and API policy so trust follows the caller, not the marketing claim about the device.

Key terms

• StrongBox: StrongBox is a dedicated secure element that can store and use cryptographic keys outside the main processor. It offers stronger resistance to some extraction techniques than a trusted execution environment, but it is slower and more limited, so it is best reserved for the most sensitive keys.
• App-Layer Attestation: App-layer attestation is proof that a request originated from the expected application running in an expected state, not just from an acceptable device. It extends trust beyond device integrity by binding cryptographic assurance to application behaviour, binary integrity, and runtime conditions.
• API Reverse Engineering: API reverse engineering is the process of analysing an API to understand how it works, what endpoints it exposes, and how requests are structured. Attackers use it to bypass client applications, discover hidden functions, and find weaknesses in authentication, authorisation, or data handling.
• Metadata Trust Boundary: A metadata trust boundary is the line between tool content that can be safely consumed and tool content that must be validated before use. For agentic systems, descriptions, examples, and schemas are security-relevant inputs because they can influence decisions and trigger actions with real-world impact.

What's in the full article

Arxan Technologies' full analysis covers the operational detail this post intentionally leaves for the source:

• Specific Android call paths where StrongBox does and does not sit in the cryptographic path
• The nuanced comparison between device attestation, MEETS_STRONG_INTEGRITY, and app-layer proof
• Practical examples of how protocol reverse engineering enables forged client handshakes
• Additional compliance and implementation context, including regulated-industry considerations

👉 The full Arxan Technologies post explains the TLS path, reverse-engineering risk, and app-layer attestation detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives identity and security practitioners a structured way to govern callers, credentials, and lifecycle controls across modern environments.