A security team evaluating a device manufacturer should test three things: who holds each layer of the build, which protections live in the firmware rather than in apps, and whether every model is qualified on real hardware and maintained until its support ends. The same test applies when a manufacturer judges its own programme. Otukan builds firmware-level protection into the Android-based devices a manufacturer or its ODM produces, engineered per model and chipset, inside the manufacturer’s own build and signing process. It leaves the brand, the keys and the release decision with the manufacturer, and gives buyers evidence they can check. Apple devices sit outside this scope.
Integration boundary
A manufacturer rarely builds a device alone. An ODM may assemble the board and the system image, a chipset vendor supplies the silicon and its board support package, and an institutional buyer may set requirements of its own. Otukan names the owner of each layer in writing before any control is designed.
| Layer | Manufacturer | ODM | Chipset vendor | Institutional buyer | Otukan |
|---|---|---|---|---|---|
| Product definition | Sets models, variants and support periods | Proposes hardware options | – | States requirements | Advises on security impact per option |
| Board support package and bootloader | Approves versions | Integrates | Supplies and patches | – | Configures verified boot per model |
| System image build | Owns the release | Builds, where contracted | – | – | Engineers integrity controls into the build |
| Signing keys | Holds or names the holder | Signs only where authorised | – | May require its own verification keys | Never holds them |
| Release approval | Decides | Delivers candidates | – | Approves for its own fleet | Supplies test results |
| Device evidence | Hosts a verification service or delegates it | – | – | May host its own | Defines what is collected and verified |
Where an ODM builds the image, Otukan works with the ODM under the manufacturer’s authority, so the manufacturer stays the single point of accountability to its buyers. Where an institution specifies its own verification server, the table records that too, and devices for that buyer report there.
The boundary also decides what a manufacturer can promise. A statement about boot integrity is only as strong as the party that controls the bootloader. Writing the table first keeps sales claims aligned with engineering reality.
Control scope
Firmware-level controls depend on the layers beneath and around them. Otukan writes down each dependency for every model, so the security statement a manufacturer makes rests on named layers and named owners.
Firmware
Verified boot, system image integrity and rollback protection form the base. Otukan configures them against the manufacturer’s approved builds and reduces the privilege of preinstalled system apps, which are a frequent route to taking over a device. For the controls in detail, see Android firmware integrity.
Hardware trust
Keys and attestation are only as strong as where they live. Otukan anchors them in the chipset’s trusted execution environment or secure element where the hardware offers one, and states plainly on each model which protections are hardware-backed and which are not.
Telemetry
Each device reports signed evidence of its boot state, firmware version and patch level. The manufacturer decides where that evidence is verified, and an institutional buyer can run its own server. Otukan agrees what is collected, who may read it and how long it is kept, and keeps personal content out of it.
Lifecycle dependencies
Protection depends on patches arriving from the platform and the chipset vendor. Otukan tracks their security bulletins against each qualified model, so a manufacturer knows which models need a new release and when a supplier’s own support ends.
Qualification
Qualification turns a design into something a buyer can rely on. Otukan produces a written record per model, tested on physical units.
| Record field | What it states |
|---|---|
| Model and variants | The exact products the record covers |
| Chipset and board support package | The silicon and software versions tested |
| Firmware versions | Every release tested with the protection enabled |
| Enabled controls | Which protections ship, and which are hardware-backed |
| Update authority | Who builds, who signs and which channel delivers updates |
| Maintenance commitment | How patches are integrated and the end-of-support date |
A regional variant with identical hardware can reuse a record after a check. A chipset refresh, a new ODM or a different bootloader configuration is qualified as a new model. That discipline lets a manufacturer answer a tender with evidence for the exact device offered. How to test a model before you commit, with baseline and protected results, is described on mobile device security evaluation.
Long-term maintenance is part of the record, not an afterthought. Each firmware release is rebuilt with the protection and retested before it ships, and the manufacturer knows in advance how devices in the field will be handled once support ends.
For the questions to settle before starting, see the OEM device security evaluation guide. For the integration process itself, see OEM device security integration. Other scenarios are on use cases.