How to integrate device security signals

Integrate a device security signal by proving where it came from before you act on it. On Android, the strongest proof is key attestation: the device generates a key in hardware-backed storage, and your server checks the certificate chain and the boot state, lock state and patch level it records. Then check that the observation is current, belongs to the right device and lifecycle, and is not a duplicate. Otukan Device Security supplies signals within an agreed model, chipset and integration scope. Managed Android, managed iOS and OEM firmware integrations each need their own scope record.

For the product context, see device integrity signals and Device Security.

Classify the source of each signal

Record which component observes the state, which transports it and which service decides what to do. A device identifier inside a message does not prove the message came from that device. An authenticated connection does not prove the observation inside it is true.

Keep these categories separate in your data. An app observation does not become hardware evidence because it is relabelled. iOS does not open its firmware to third parties, so managed iOS devices rely on management state and app-level evidence such as App Attest.

Verify Android device state with key attestation

Android Verified Boot builds a chain of trust from a hardware-protected root through the bootloader to the verified partitions. Key attestation lets your server read the result of that chain without trusting the operating system’s own report.

Generate an attested key

1. Your server issues a random, single-use challenge.
2. On the device, build a KeyGenParameterSpec with setAttestationChallenge(challenge) and generate the key in the Android Keystore. Request StrongBox with setIsStrongBoxBacked(true) where the device has it.
3. Read the chain with KeyStore.getCertificateChain(alias) and send every certificate to the server.

Check the chain on the server

1. Verify each certificate’s signature up to a Google hardware attestation root certificate published in the Android documentation. Keep that root list current.
2. Check every certificate against Google’s attestation revocation status list.
3. Parse the attestation extension (KeyDescription) in the leaf certificate. Confirm attestationChallenge equals the challenge you issued.
4. Require an attestationSecurityLevel and a KeyMint (Keymaster) security level of TrustedEnvironment or StrongBox. A Software level proves nothing about the hardware.
5. In the hardware-enforced list, read RootOfTrust:
   • verifiedBootState is Verified for a locked device running the manufacturer’s signed image. SelfSigned, Unverified or Failed mean a custom or broken boot chain.
   • deviceLocked shows whether the bootloader is locked.
   • verifiedBootKey identifies the key that signed the boot image; compare it with the values you expect for each model.
6. Check osVersion, osPatchLevel, vendorPatchLevel and bootPatchLevel against your minimum, and attestationApplicationId against your app’s package and signing certificate.

The result is a hardware-rooted statement about the device at the moment of attestation. Store it with the device record and a timestamp, and repeat it when the device boots, updates or reaches a sensitive operation.

Define the interface contract

1. Identify the models, chipsets, firmware builds and OS releases in the integration, and who may install or change each producer.
2. Obtain the versioned contract and a redacted example. Map each value into your consumer’s internal representation.
3. Specify the authenticated peer, trust roots, credential rotation and revocation. If payloads are signed, define verification and device binding separately from the transport.
4. Separate read-only monitoring from services allowed to restrict a device or an operation.
5. Reject malformed required data. Decide how unknown optional fields and unsupported versions are handled; never default them to healthy.

Process freshness, duplicates and errors

Test the receiver against fixtures first, then against the real producer. Fixtures prove your parser and decision logic; only a device proves detection.

1. Validate the connection and any payload signature before parsing.
2. Resolve the device binding and contract version. Send failures to a reviewable error state.
3. Judge observation age by receipt time and attestation time, not by an unverified device clock alone.
4. Deduplicate per the contract. Scope event keys to the producer and lifecycle; a reset or reassignment starts a new lifecycle.
5. Never let a delayed observation overwrite newer evidence.
6. Apply the agreed response only after these checks, and make repeated processing safe.

Keep a separate state for missing evidence. Lost connectivity, producer failure, revoked credentials and an unsupported control have different causes. None of them means “compromised”, and silence never means “trusted”. Set queue limits and an alert when delivery falls behind. Keep device identifiers out of broad application logs, and agree access, retention and deletion with fleet operations and privacy owners.

Test legitimate changes and adverse states

Pair each adverse scenario with a legitimate control on an authorised test device, and record the state change independently.

Repeat installation, update, authentication and the sensitive workflow after every integration change. Test restrictions and their removal, not only the presence of a signal in a log.

• Tested model, chipset, firmware and OS are recorded.
• Expected observations and actions are agreed before the run.
• Each decision traces back to an authenticated or attested source.
• Recovery restores service without reusing stale trust.

For related reading, see hardware-backed mobile security and Android bootloader integrity.

Further reading

• Verify hardware-backed key pairs with key attestation — Android Developers
• Key and ID attestation — Android Open Source Project
• Verified Boot — Android Open Source Project
• Boot flow — Android Open Source Project