An OEM device security integration with Otukan rests on three kinds of authority: access to the firmware build for each model, control over how system images and updates are signed, and agreement from the ODM and chipset vendor on who changes and supports each layer. Otukan works inside that authority. Protection is built into your firmware under your change control, signed only through your process, and delivered in five stages with a sign-off at each. The work covers Android-based devices whose system image the OEM or its ODM builds.
Integration authority
A mobile device is built by several parties, and embedded protection touches the layers each of them controls. Otukan agrees each party’s part in a written responsibility matrix before engineering starts.
| Party | Usually controls | What Otukan agrees with them |
|---|---|---|
| OEM | Product definition, system image, release decisions, signing keys | Build access for each model, a named owner for signing, approval of each release |
| ODM | Hardware design, board bring-up, often the day-to-day firmware build | Access to the build environment, change control, test devices |
| Chipset vendor | Boot chain, board support package, trusted execution environment, hardware security features | Documentation of what the chipset provides, and which layers may be changed |
| Institution (where it is the buyer) | Device policy, data handling, acceptance testing | Requirements, acceptance criteria, and who operates devices after delivery |
Protection that relies on hardware, such as hardware-backed keys and attestation, is built on chipsets that provide a trusted execution environment or secure element. Apple builds and signs the firmware for iOS devices, so OEM firmware integration applies to Android-based devices.
Delivery stages
Otukan delivers every programme in five stages. Each ends with a deliverable both sides sign off, so the work stays predictable from first build to last update.
- Qualification. You name the models, chipsets and operating system versions in scope, and confirm who holds build access and signing authority. Deliverable: a scope statement per model and a responsibility matrix.
- Design. Otukan agrees the device threat model with your engineers and maps each control to its layer: boot chain, system image, system services or management interfaces. Deliverable: a control list per model.
- Integration. Otukan builds the controls into your firmware under your change control. Nothing is signed outside your own signing process. Deliverable: integration builds for test devices.
- Testing. Each control is tested on the physical models in scope, including update, rollback and factory reset paths. Deliverable: a test report against the acceptance criteria agreed in qualification.
- Release and maintenance. Otukan rebuilds and retests the protection with each firmware release, alongside your security patches and key rotation. Deliverable: a maintenance plan with named owners and an end-of-support date.
Commercial boundary
Otukan separates reusable device protection from custom OS engineering at the start, so you know what carries across your range and what belongs to one device.
| Reusable device protection | Custom OS engineering |
|---|---|
| Controls designed to carry across models that share an architecture | Changes to a vendor’s boot chain or board support package for one device |
| A common approach to signing, update and patch ownership | Porting to a new chipset or a new operating system version |
| Shared test plans and acceptance criteria | Drivers, hardware bring-up and custom system services |
| Documented responsibilities per model | Features outside security, such as product customisation |
Where a programme needs custom OS engineering, it runs as its own piece of work with its own owner, so the reusable protection stays clean and maintainable across your models.
Signing and update ownership is covered on Android secure firmware updates. How to test a device programme is covered on mobile device security evaluation. Hardware-rooted features are covered on hardware-backed mobile security. The OEM device security evaluation guide lists the questions to settle before a programme starts. For the product overview, see mobile device security.