Other systems can act on device security evidence when every signal says where it came from, how fresh it is and what it cannot prove. Otukan delivers device integrity signals with exactly that context. Each signal is defined in a written dictionary, marked as attested by hardware or reported by the operating system, and bound to a fresh challenge. Your apps, your device management and your backend receive only the fields their decisions need, under an integration contract you approve. This page covers Android-based devices in an Otukan device programme, per model and chipset.
Signal semantics
A signal is only as useful as its definition. Otukan documents three properties for every signal in your programme.
Origin
Where the value was produced decides how far it can be trusted.
| Signal group | Produced by | Signed by | Suitable for |
|---|---|---|---|
| Boot state and bootloader lock | Bootloader | Hardware-backed key store, on supported chipsets | Access decisions on sensitive services |
| Security patch level | System and vendor images | Hardware-backed key store, on supported chipsets | Access decisions and update planning |
| Access control mode and build type | Running operating system | Not hardware-signed | Supporting context and fleet reporting |
| Verification verdict | Your verification server | Server key, with custody agreed in writing | Consumption by apps, device management and backend |
Freshness
A report proves the device state at the moment it was produced. Otukan binds each report to a challenge issued by the verification server and records when it was created. Consumers that make access decisions ask for fresh evidence; consumers that report on the fleet read the stored result together with its age.
Reliability limits
Every signal has limits, and the dictionary states them. A value reported by a running system can be misreported if that system is compromised, which is why Otukan labels it as reported. Hardware-backed attestation depends on the chipset and on keys provisioned for the device. A clean verdict shows the device matched your approved values at that moment; it says nothing about the apps or the person using it.
When a signal is missing
Absence is also information. A device that fails to answer a challenge, returns a malformed report or reports from a chipset without a hardware-backed key store does not receive a passing verdict by default. The dictionary gives each consumer an explicit rule for missing or partial evidence, so an outage or an older model does not turn silently into a pass. Your security team sees these cases in their own category, separate from devices that reported and failed.
Consumers and decision authority
Several systems read device evidence, and each owns a different decision. Otukan writes this split into the integration contract, so no consumer acts beyond its role.
| Consumer | Decides | Typical action |
|---|---|---|
| Application on the device | What the app itself allows | Hide a sensitive feature or ask the user to update |
| Device management | Fleet policy for the device | Move the device to a restricted group or schedule an update |
| Backend service | Access to data and transactions | Allow, step up or refuse a request |
| Security team | Investigation and exceptions | Review a mismatch and approve or reject an exception |
An app should not decide on its own that a device is compromised, and a backend should not push fleet policy. Each consumer receives the verdict and the fields behind it, applies its own rule and records its own decision. How management tools consume these signals is covered on MDM security integration.
Data handling
Device evidence contains identifiers, so Otukan treats it as data to be governed, not only as a technical feed.
- Transport. Reports and verdicts travel over protected, authenticated channels between the device, the verification server and each consumer.
- Access. Each consumer has its own credentials and sees only the fields named in its contract. Security teams see the full record; an app sees what its features need.
- Retained identifiers. Otukan lists every identifier in the evidence, such as attestation certificate details and device serials, and agrees which are kept, where and for how long. Where a consumer does not need a hardware identifier, Otukan gives it a programme-specific reference instead.
- Change control. The dictionary and contract carry a version. A firmware release that adds or changes a signal updates both before devices report the new value.
Step-by-step integration is covered on how to integrate device security signals. The firmware evidence behind these signals is covered on Android firmware integrity. For the full device programme, see mobile device security.