Direct answer: An Android handheld having a Keystore API does not prove that a particular business-app key is hardware-backed. Specify the key operation and threat model, check the security level of a key created by the actual app on the exact device image, and, if remote proof is required, validate a fresh attestation on a trusted server. StrongBox is an optional, more constrained security level—not a universal requirement or an AIDC GO model claim.
This is a procurement question for teams that store device-bound credentials or sign transactions in an enterprise application. The handheld-terminal category identifies the product class; it does not certify the Keystore implementation of every configuration. Define the application and security requirements with Integration Support before selecting an exact model.
State what the key is meant to protect
Record whether the business app generates a signing key, protects a local secret, or needs a system-wide credential shared through Android KeyChain. These are different application designs. Android’s Keystore guidance distinguishes per-app Android Keystore keys from system-wide KeyChain credentials and explains that key use can be restricted by purpose or user authentication. A marketing line saying “secure Android” does not identify which path the deployed app uses.
Describe the adversary and the failure that matters: extraction of a private key from a lost device, unauthorized use while the device is unlocked, a forged device enrollment, or loss of access after a reset. Keystore can reduce extraction risk, but it does not by itself decide a business user’s permissions, prove an uploaded transaction was accepted, or replace server-side authorization. The enrollment guide addresses device ownership and provisioning; this guide addresses evidence for one app’s key.
Separate API availability, hardware security level and remote proof
For the exact app build, Android version, firmware and proposed model, generate or import a test key using the intended algorithm, size and key-use restrictions. Check what the app can actually do with that key. Android documents KeyInfo.getSecurityLevel() for apps targeting Android 10/API 29 or later and isInsideSecurityHardware() for older target SDKs. A reported TRUSTED_ENVIRONMENT or STRONGBOX level concerns that particular key, not every key or every business process on the device.
StrongBox may be present on Android 9/API 28 and later devices, but it is optional. Android documents a feature check with FEATURE_STRONGBOX_KEYSTORE, a request using setIsStrongBoxBacked(true), and an exception when the requested algorithm or key size is unavailable. The same guidance notes resource and performance trade-offs and says most apps do not need StrongBox. Ask for it only if the project’s threat model and app design justify it; do not silently fall back to a different level when the purchase requirement forbids that.
If an off-device verifier must distinguish a hardware-backed key from an untrusted claim made by the handset, key attestation is a separate requirement. Android’s attestation guidance calls for certificate-chain, trusted-root, signature and revocation checks on a separate trusted server, together with the attested security level. Applicability depends on the device’s attestation implementation and trust chain; a local screen displaying “hardware-backed” is not equivalent to that remote validation. Do not confuse key attestation with optional attestation of device identifiers.
An editorial acceptance scenario
Editorial example, not a customer deployment or device test: A maintenance app signs a work completion record with a device-bound private key. The security team requires that the signing key remain in a trusted execution environment, but does not require StrongBox. It also requires the server to reject a newly enrolled device if the attestation is invalid. The procurement sample is one specific handheld SKU, firmware image, Android release and app build.
- The app requests a fresh key with the approved signing algorithm and purpose. Record the requested restrictions and whether generation succeeds; do not export a private key as test evidence.
- Read the security level for that generated key. A TEE result may satisfy this stated requirement. A software result does not, even if the app can still sign; a StrongBox result is not needed solely because it is the highest named level.
- Have the trusted server validate a fresh attestation challenge and the applicable chain and revocation information. Record the server decision and its reason, not only a client-side success message.
- Sign one test record and verify the server associates it with the intended enrolled device and authorized business account. Then reject a record from an unenrolled device or mismatched account. The key proves a cryptographic operation; the application still enforces business identity and permissions.
If the chosen configuration cannot produce the required attestation or key algorithm, classify that as an unresolved compatibility condition, not a reason to weaken the test without the security owner’s approval. If StrongBox is a stated requirement, test the exact algorithm and concurrency pattern rather than inferring capability from the OS version.
Plan failure and replacement before ordering a fleet
A non-exportable device-bound private key is not a portable backup. Ask how the system revokes the old public-key association, enrolls a replacement device and reconciles unsent business work after loss, reset or service. Do not promise that restoring an app backup will restore its original Keystore key. The device-retirement guide covers data removal and reprovisioning order; this article adds the credential-binding acceptance question.
Separate a failure to create a key, a key created at an insufficient security level, a failed certificate validation and an application account rejection. Each requires a different owner and correction. A passing cryptographic test does not prove that offline work, scanner input or backend submission still functions. Include those normal tasks in the wider pilot validation.
What to request from the supplier and app team
For each offered device configuration, obtain the Android version, exact image and security-update plan, relevant Keystore or StrongBox documentation, supported app key operation, and the app team’s acceptance report. Record the target SDK and whether the evidence came from local KeyInfo, off-device attestation or both. Ask who owns credential replacement and how a lost device is blocked without deleting historical work records.
Do not purchase on “TPM-like,” “secure element,” or “Android Enterprise” wording alone. Those labels cannot establish that this app requested and received its required key. Send the key algorithm, target security level, attestation policy and replacement workflow through Contact for a configuration-specific discussion; no AIDC GO model is asserted here to include StrongBox or to pass a particular attestation policy.
Sources and scope
Android Developers’ Android Keystore system and hardware-backed key attestation guidance, plus the Android Open Source Project’s Key and ID attestation reference, were read on 2026-09-23. API and attestation behavior must be verified against the actual Android target SDK, device image, algorithm and server policy. The scenario is editorial and contains no measured device result.