Change:
The following entities are used: <del> Author: The author is the entity that creates the firmware image, signs and/or encrypts it.  The author is most likely a developer using a set of tools. </del> <ins> Author: The author is the entity that creates the firmware image. There may be multiple authors in a system either when a device consists of multiple micro-controllers or when the the final firmware image consists of software components from multiple companies. </ins> Device: The device is the recipient of the firmware image and the <del> manifest.  The goal is to update the firmware of the device. Untrusted Storage: Firmware images and manifests may be stored on untrusted fileservers or cloud storage infrastructure.  Some deployments may require storage of the firmware images/manifests to be stored on various entities before they reach the device. </del> <ins> manifest.  The goal is to update the firmware of the device.  A single device may need to obtain more than one firmware image and manifest to succesfully perform an update. Communicator: The communicator component of the device interacts with the firmware update server.  It receives firmware images and triggers an update, if needed.  The communicator either polls a firmware update server for the most recent manifest/firmware or manifests/firmware images are pushed to it.  Note that the firmware update process may involve multiple stages since one or multiple manifests may need to be downloaded before the communicator can fetch one or multiple firmware images/software components. Status Tracker: The status tracker offers device management functionality that includes keep track of the firmware update process.  This includes fine-grained monitoring of changes at the device, for example, what state of the firmware update cycle the device is currently in. Firmware Server: Entity that stores firmware images and manifests. Some deployments may require storage of the firmware images/ manifests on more than one entities before they reach the device. Device Operator: The actor responsible for the day-to-day operation of a fleet of IoT devices. Network Operator: The actor responsible for the operation of a network to which IoT devices connect. In addition to the entities in the list above there is an orthogonal infrastructure with a Trust Provisioning Authority (TPA) distributing trust anchors and authorization permissions to various entities in the system.  The TPA may also delegate rights to install, update, enhance, or delete trust anchors and authorization permissions to other parties in the system.  This infrastructure overlaps the communication architecture and different deployments may empower certain entities while other deployments may not.  For example, in some cases, the Original Design Manufacturer (ODM), which is a company that designs and manufactures a product, may act as a TPA and may decide to remain in full control over the firmware update process of their products. The terms 'trust anchor' and 'trust anchor store' are defined in RFC6024: "A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative." "A trust anchor store is a set of one or more trust anchors stored in a device.  A device may have more than one trust anchor store, each of which may be used by one or more applications." Furthermore, the following abbreviations are used in this document: Microcontroller (MCU for microcontroller unit) is a small computer on a single integrated circuit, which is often used for mass volumne IoT devices. System on Chip (SoC) is an integrated circuit that integrates all components of a computer, such as CPU, memory, input/output ports, secondary storage, etc. Homogeneous Storage Architecture (HoSA): A device that stores all firmware components in the same way, for example in a file system or in flash memory. Heterogeneous Storage Architecture (HeSA): A device that stores at least one firmware component differently from the rest, for example a device with an external, updatable radio, or a device with internal and external flash memory. </ins> 3.

Discussion:
Added David Brown as co-author Added further terms Updated text about permissions Re-wrote text about operating modes Editorial changes (including formatting) Revised section about claims Added new architecture figure Reworked security description Included device firmware update examples provided by David. Updated example flow (and included bootloader)