A mobile security team evaluates application and MDM interfaces by asking three things of each one: which party owns it on the device, what device-level evidence it passes upward, and who keeps it stable when firmware changes. Otukan defines these interfaces for Android-based devices carrying its firmware-level protection. Apps get a narrow, permissioned way to ask about device state. Management gets policy hooks and integrity reports it can act on. Each interface is documented, versioned per model and retested with each release. Apple defines its own management and attestation model, so iPhone and iPad sit outside this page.
Integration boundary
An interface between device protection and the software above it crosses several owners. The OEM ships it in the system image, the ODM builds it, the chipset decides whether its answers can be hardware-signed, and the institution decides who may use it. Otukan agrees these points per interface before building anything.
| Interface | Used by | Owned on the device by | What Otukan agrees |
|---|---|---|---|
| Device state query | Your apps and apps you approve | OEM system image | Which apps may call it, what they receive, how access is granted |
| Management policy hooks | Your management system or Otukan device management | OEM, with the institution setting policy | Which controls management may switch and which stay fixed in firmware |
| Integrity reports | Your verification server, management and security monitoring | Otukan protection, keyed per device where the chipset allows | Report fields, freshness rule and recipients |
| First-boot provisioning | Your enrolment service | ODM factory process and OEM | Which settings are in place before the user first sees the device |
Who may call what
Access to each interface is granted through Android permissions declared in the system image. An app outside the approved list cannot reach the interface even when a user installs it. The caller permission map names each approved app, the permission it holds and the reason it needs it, so a reviewer can check the list line by line.
When the buyer is not the builder
When an institution buys devices from an OEM, the OEM builds the interfaces and the institution chooses which management service and which apps are authorised to use them. Otukan records both decisions, so a later change to the approved callers goes through the institution, not only the OEM.
Control scope
An interface is only as trustworthy as the protection beneath it. Otukan maps the dependencies of each interface before it is published to your developers.
| Dependency | Why the interface relies on it | Behaviour when it is absent |
|---|---|---|
| Firmware integrity | An answer about device state means little if the image beneath it is not the approved one | Reports mark the state as unverified rather than trusted |
| Hardware-backed keys | Your server can confirm a report came from that device | Reports are labelled as software-signed so consumers apply their own lower-trust rule |
| Telemetry path | Reports reach management and your backend | The last verified state is kept with its time, and the device is listed as silent |
| Lifecycle state | Enrolment, factory reset, repair and retirement change what the device should answer | Behaviour for each state is written into the contract in advance |
Clear lines between consumers
Each interface does one job. Apps can read device state but cannot change device policy. Management can switch permitted controls but cannot read app data through the security interface. No interface exposes keys. These lines keep a compromise of one consumer from spreading to another, and they make each interface simple to test.
Qualification
Before your team builds apps or management workflows on these interfaces, Otukan provides the evidence that they will hold for the models you ship.
| Question to settle | Evidence Otukan provides |
|---|---|
| Which models expose which interfaces | An interface matrix per model and firmware build |
| Who may change an interface | A change control record naming the OEM approver and, where relevant, the institution |
| How consumers learn of changes | A versioned contract, with change notes issued ahead of each release |
| How long an interface version is maintained | A period agreed per model in the maintenance plan, running to the model’s end of support |
Interface versions follow the firmware, not the calendar. When a release changes an answer or adds a field, the version rises and the change notes explain what app and management teams need to adjust. A release that would break a published contract is flagged to the OEM before it is signed.
How device evidence is labelled and consumed is covered on device integrity signals. How management acts on security findings is covered on MDM security integration. For the parent topic, see OEM device security integration. For the management product, see mobile device management.