# OTA update Source: https://ordergroup.co/glossary/ota-update/ Last updated: 2026-10-10 > OTA and FOTA updates for teams that ship devices - signing, A/B slots, full and incremental packages, staged rollouts and what the update backend must do. [IoT & Devices](https://ordergroup.co/glossary/iot/) 5 min read # OTA update Over-the-air update Also known as: over-the-air update, FOTA, firmware over the air, staged rollout Definition An OTA (over-the-air) update is a software or firmware update that a device downloads and installs over a network, with no cable or service visit. FOTA is the firmware case. The package must be signed, verified on the device and recoverable when the installation fails. Cite this entry Text "OTA update". Order Group, Software glossary, 10 October 2026. https://ordergroup.co/glossary/ota-update/ HTML `OTA update - Order Group` Reviewed by [Maciej Sułek](https://ordergroup.co/authors/maciej-sulek/), Co-founder & CTO Last reviewed 10 October 2026 ## How OTA updates work An OTA update moves a new software image from the manufacturer to a device in the field over a network. RFC 9019, the IETF architecture for IoT firmware updates, splits the job into roles. The author builds the image. A status tracker announces that a new version exists, reports what hardware and software each device runs and triggers the update. The firmware consumer on the device parses and verifies the manifest and stores the image. The manifest carries a sequence number, and RFC 9019 states that a device presented with an old but valid manifest must not be tricked into installing that firmware, because old versions can contain known vulnerabilities. Android, the base for most custom phone and terminal systems, shows the same chain in detail. An OTA package must be signed with one of the keys the system expects, or installation rejects it. On non-A/B devices, packages received by the main system are usually verified twice: once by the system against keys in otacerts.zip and once more by recovery. Builds are signed with test keys by default, and the AOSP documentation warns that test keys are publicly known, so any released image needs its own release keys. There are two kinds of package. A full package contains the entire final state of the device and installs regardless of what the device runs now. An incremental package contains binary patches against the files already on the device. It is smaller, but it installs only on the exact source build it was made from; on any other build the installation fails and the device keeps running the old system. On current Android devices the installation itself uses A/B slots. The update_engine daemon writes the new version to the unused slot in the background while the user keeps working, and the bootloader switches slots on the next reboot. If the new slot fails to boot, the device falls back to the old one. The new slot is marked successful only after it boots and passes its checks. Virtual A/B has been the scheme since Android 11, and non-A/B updates are deprecated as of Android 15. ## What OTA updates mean for your software Most of the work behind OTA sits in the backend and the release procedure, and they decide whether a new version reaches the fleet or leaves devices that no longer boot. Requirements for a system that ships updates to a fleet: - Signing keys are production infrastructure. Release keys live apart from test keys, outside developer laptops and CI logs, with a named owner. Whoever holds the key can ship code to every device. - The version graph is data. For each target version the backend stores the full package, the source versions that have an incremental package, and the package URLs. Each source-to-target pair is unique, and the database enforces it. - Every dimension of a build is explicit: region, signed or unsigned, user or userdebug variant. An incremental package built for the wrong variant fails on every device that receives it, so the backend validates that source and target match before publishing. - The device falls back to the full package when an incremental installation fails, logs the error code, and reports which type of update it attempted. - Releases are staged. A version goes to a test group first, then to growing percentages of each device group on a schedule, with pause and stop. A pause must also stop the schedule, and a device that already started installing must be able to finish. - Devices report status back. Without per-device version and error codes the operator cannot tell a slow rollout from a failed one. - Migrating release data is as risky as a release. Rollout states, group assignments and build variants have to survive a move to a new backend, and the move needs its own test pass. - Old versions stay blocked. The backend and the device both refuse downgrades to a version with known vulnerabilities. Writing the specification? Add OTA update to your requirements checklist Collect the terms your project touches and get their system requirements in one e-mail, ready for an RFP. Update mechanisms and what the backend must track MechanismWhat it doesConstraintWhat the backend tracks Full OTA packageContains the entire final state of the deviceLarge downloadOne package per target version, region and variantIncremental OTA packageBinary patches against the files on the deviceInstalls only on the exact source buildSource-to-target pairs, fallback to the full packageA/B (Virtual A/B) slotsWrites the update to the unused slot, old slot stays bootableDevice storage and partition layoutBoot success and failure reportsStaged rolloutReleases to a growing share of devices over timeNeeds device groups and random selectionPhase schedule, pause and stop state, devices reachedAnti-rollbackRefuses older versionsNeeds a version or sequence number in the manifestMinimum allowed version per device line ## Rules and standards In the EU, the Cyber Resilience Act, Regulation (EU) 2024/2847, turns update capability into a legal requirement for products with digital elements. Under Annex I, vulnerabilities must be addressable through security updates, including, where applicable, automatic security updates enabled by default with a clear opt-out, notification of available updates and the option to postpone them. Manufacturers must provide mechanisms to distribute updates securely, and security updates for identified issues must go out without delay and, unless agreed otherwise for a tailor-made product, free of charge. Annex I, Part II, point 2 requires that, where technically feasible, new security updates are provided separately from functionality updates. Article 13(8) sets the support period at a minimum of five years; when the product is expected to be in use for less than five years, the support period matches the expected use time. The regulation applies from December 11, 2027; the reporting obligations of Article 14 have applied since September 11, 2026. RFC 9019 is an informational IETF document; it sets out the architecture and motivates a transport-agnostic manifest format for describing and protecting updates. ## From our projects In the [Raw Control OS project](https://ordergroup.co/case-studies/raw-cyber-custom-android-os/), update work started in 2019 with a test environment for analyzing and assessing the security of the Android updates published by Google before they went into the system. The production version of the system was prepared together with an OTA test and handed to the client for verification, and later OTA builds were issued on the client's request. A backend OTA service was drafted in 2021 but not completed in that project. For Mudita, in 2026 we are building the second stage of the OTA platform behind its phones, including a new admin dashboard. We did not build Mudita's operating system. The scope covers publishing incremental updates, with a full package always available as the fallback and a unique link between each version and its predecessor; automatic generation of incremental packages in the build pipeline, with file names that encode region, version, signing, build variant and source version; validation of previous versions when a new one is configured; and staged rollout scenarios. A scenario has 1 to 10 phases, each set as hours after release (0 to 720) and a percentage of the group, with the last phase at 100%. One example is 5% at once, 20% after 48 hours, 50% after 120, 75% after 168 and 100% after 240. Devices in each phase are chosen at random. In September 2026, the test migration to the new dashboard left all rollouts of published versions stopped; on production this would have blocked every update. That was fixed. A security audit of the platform's frontend and backend is in progress. From our projects [RAW Cyber - Secure Custom Android Operating System How Order Group and RAW Cyber built a secure mobile operating system: a custom Android-based OS hardened with CopperheadOS for secure communications.](https://ordergroup.co/case-studies/raw-cyber-custom-android-os/) ## Related terms - [Deep packet inspection](https://ordergroup.co/glossary/deep-packet-inspection/) Deep packet inspection (DPI) is a method of network traffic analysis that reads packet contents, not only IP addresses and ports, to identify the protocol or application behind a flow, extract fields such as host names, and allow, block or log the traffic by policy. - [MDM](https://ordergroup.co/glossary/mdm/) Mobile device management Mobile device management (MDM) is software that lets an organization enroll, configure, monitor, lock and wipe phones, tablets and other devices from a central console, by sending policies to an agent or to the management interface of each device's operating system. ## Sources 1. [A/B (seamless) system updates](https://source.android.com/docs/core/ota/ab) - Android Open Source Project 2. [Build OTA packages](https://source.android.com/docs/core/ota/tools) - Android Open Source Project 3. [Sign builds for release](https://source.android.com/docs/core/ota/sign_builds) - Android Open Source Project 4. [RFC 9019: A Firmware Update Architecture for Internet of Things](https://www.rfc-editor.org/rfc/rfc9019.html) - IETF 5. [Regulation (EU) 2024/2847 (Cyber Resilience Act)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng) - EUR-Lex Maciej Sułek reviewed this entry. Ask how it applies to your project. [Ask an engineer](https://ordergroup.co/contact-us/) ## FAQ ![Maciej Sułek](https://ordergroup.co/media/images/T02DHCC1Z-U04AVB19V-45105f88ff4a-512.format-webp.webp) Maciej Sułek Co-founder & CTO [Talk to an engineer](https://ordergroup.co/contact-us/) ### What is the difference between OTA and FOTA? FOTA is OTA applied to firmware. OTA also covers operating systems, apps and configuration. The requirements are the same: a signed package, verification on the device, recovery when the installation fails, and a backend that knows which device runs what. ### Should every update be incremental? No. An incremental package installs only on the exact build it was made from, so keep a full package for every version and fall back to it automatically. Incremental packages save download size for the devices that are on the expected version. ### Do our devices need A/B partitions? On Android, non-A/B updates are deprecated as of Android 15, so new devices should use Virtual A/B. On microcontroller devices, RFC 9019 describes two ways to recover from a bad image: switch to another valid image or download a new one. Both need room in flash for more than one image. ### Does the Cyber Resilience Act require automatic updates? Where applicable, yes: Annex I of the CRA calls for automatic security updates enabled by default, with a clear opt-out and the option to postpone. The regulation applies from December 11, 2027, so devices designed now will be sold under it. Building a system that depends on OTA update? See how we build software for this domain, with case studies and the stack we use. [See IoT & Device Software Development Services](https://ordergroup.co/iot-software-development/) Requirements checklist For each term we send the definition and what it requires from your software. Free, no sales call needed. Your checklist is empty. Use the plus next to a term to add it.