A mobile security team evaluates integration responsibilities by checking that each decision in a device programme has exactly one owner: who may change each firmware layer, who signs, who answers when something fails in the field, and who keeps devices safe until end of support. Otukan writes these decisions down per model before engineering starts and keeps the record current through releases, supplier changes and incidents. The OEM, ODM, chipset vendor and institution each hold duties Otukan does not take over, and Otukan holds its own. This page covers Android-based device programmes; Apple carries firmware responsibility for iOS devices.
Integration boundary
Most programmes can list their parties. Fewer can say who decides. Otukan builds the record around decisions, because a task with two owners tends to end up with none.
The decision matrix
Each row is a decision; each column a party. A marks the one party accountable, R the party doing the work, C a party consulted before the decision, and I a party informed after it.
| Decision | OEM | ODM | Chipset vendor | Institution | Otukan |
|---|---|---|---|---|---|
| Which layers Otukan’s protection may change | A | C | C | I | R |
| Build and change control for each release | A | R | I | I | C |
| Release signing | A, R | I | – | I | I |
| Hardware security features used per chipset | C | C | A, R | – | C |
| Device policy and acceptance testing | C | – | – | A, R | C |
| Protection behaviour and the tests that show it | C | C | – | C | A, R |
The exact letters change between programmes. An institution that buys finished devices is consulted on less of the build and accountable for more of the policy. An OEM that builds in-house may hold both the OEM and ODM columns. What stays fixed is the rule: one A per row. How a device maker’s own build layers divide is covered on device security for device manufacturers.
When a party changes
Suppliers change during the life of a model. When an ODM, chipset or service provider joins or leaves, the supplier change record lists each duty that moves, the party taking it and what must be handed over: build environment access, test devices, open findings and release history. Otukan keeps its own duties across the change and helps you confirm the handover before the old supplier exits.
Control scope
Each kind of control depends on something another party provides. The record names that party and the duty they accept.
| Dependency | Duty it creates | Typical holder | What Otukan records |
|---|---|---|---|
| Firmware build | Include Otukan’s protection in each release under change control | ODM or OEM build team | Build owner per model and the change control route |
| Hardware trust | Provision device keys and certificates during manufacture | OEM factory with the chipset vendor | Where keys are provisioned and who handles a revoked batch |
| Telemetry | Operate the server that receives device reports and decide what it may store | Institution or OEM service team | Server owner, data retention rule and who reads the reports |
| Lifecycle | Handle repair, factory reset, resale and retirement | OEM service network and institution | Which state each event leaves the device in and who confirms it |
Duties that stay with you
Some duties belong with you by design. Otukan never holds your signing keys, never approves a release on your behalf and never sets policy for your fleet. Keeping these with you keeps authority where accountability sits, and it means Otukan’s access can be reviewed and withdrawn like any supplier’s.
Qualification
Before you commit to a model, the responsibility record should answer three questions in writing.
- Supported models. Each model and hardware revision in scope has a named build owner and a named update owner.
- Update authority. The record states who approves, signs and publishes each release, and who can act if the usual signer is unavailable.
- Long-term maintenance. Each party’s ongoing duties are listed with an end date agreed per model.
Events that test the record
A responsibility record proves itself when something goes wrong. The escalation map covers the events Otukan plans for from the start.
| Event | Acts first | Decides | Informed |
|---|---|---|---|
| Security finding in Otukan’s protection | Otukan | OEM, on the fixing release | Institution |
| Flaw in the chipset layer | Chipset vendor, with Otukan triaging impact | OEM | Institution and ODM |
| Suspected key exposure | OEM | OEM, under the agreed replacement plan | Otukan and institution |
| Release missing its planned date | Build owner | OEM | Institution |
| Model reaching end of support | Institution and OEM | Institution, on what devices may still reach | Otukan |
Who maintains each control after rollout is covered on device security deployment and control. The practical steps to prepare for integration are listed on the integration prerequisites implementation guide. For the parent topic, see OEM device security integration.