AmbiOTA — updates that cannot be forged, from a key that never touches a build server.
Secure OTA is mandated in every relevant regime — TEC 31318 for IoT, UNECE R156 for vehicles, AIS-230 for Indian V2X on-board units, and the TRAI consultation's cybersecurity direction. The hard part is not the delivery pipeline. It is that in most implementations the firmware signing key sits on a build server, and everyone on the engineering team can reach it.
Five stages, and the first one is where the difference is.
| Step | Stage | Detail |
|---|---|---|
| 1 | Sign firmware | Ed25519 or ECDSA key held in the AmbiSEC secure element — no private key touches a build system or a developer workstation |
| 2 | Create delta package | Only changed bytes transmitted, minimising bandwidth for constrained fleets |
| 3 | Notify | Push notification explaining what the update fixes, before download begins |
| 4 | Verify and apply | Signature verified by AmbiSEC on-device; automatic rollback on any failed update |
| 5 | Audit log | Every event logged with device ID, timestamp and firmware hash — formatted for CERT-In submission |
AmbiOTA is an SDK plus a managed cloud service. It works standalone, or as the OTA layer on any AmbiSEC-equipped device.
A signed pipeline with the key on a build server has moved the attack, not removed it.
Everyone who can reach the CI pipeline can sign firmware. Every backup of that server contains the key. Every credential leak reaches it. The build system is usually the softer target.
Keeping the signing key inside a secure element on the build side means the build system can request a signature and never possess the ability to produce one independently. That is the same architectural move as on the device, applied one level up — and it is the reason the same secure-element technology sits on both ends of the pipeline. The device-side argument →
Secure OTA is mandated in every relevant regime.
TEC 31318 for IoT; UNECE R156 for vehicles, which requires a certified Software Update Management System and provides the legal basis for over-the-air updates; AIS-230 for Indian V2X on-board units; and the TRAI consultation's cybersecurity direction. The Indian standards architecture → · R155 and R156 in the EU →
On the V2X side specifically, the update path and the certificate-delivery path share the same cellular link. A vehicle whose network side is not working eventually cannot sign messages either. Why the Uu path is part of the safety function →
Bandwidth is the constraint that decides whether a fleet actually updates.
A full firmware image over a metered cellular link, multiplied by a fleet, is the reason security updates get deferred. Transmitting only the changed bytes changes the economics: an update that costs a few kilobytes per device is one an operator will authorise on a normal cadence rather than saving for an incident.
That matters more in V2X than in most embedded work, because the update path and the credential path share a link. The same cellular connection that delivers firmware delivers certificate batches, trust-list updates and revocation material, and a device that cannot afford to talk is a device that will eventually stop being able to sign. The workloads on that link →
The update that matters is the one that fails.
Verification happens on the device, by the secure element, before anything is committed. A signature that does not verify is not installed; an installation that does not complete rolls back to the previous image. Neither decision is taken by application firmware, which is the point — an attacker who controls the host cannot approve their own image.
Every event is logged with the device identifier, a timestamp and the firmware hash, in a form that can be submitted to CERT-In. For an operator that is the difference between asserting a fleet is patched and being able to show it, which is what a Software Update Management System under UNECE R156 has to demonstrate. R155 and R156 →