Summary

  • RFC 9019 describes firmware updating as authorized remote code execution. A valid signature authenticates an author and protects the manifest, but the device must separately decide whether that author may perform the requested action.
  • The architecture separates author, device operator, network operator, user and Trust Provisioning Authority. RFC 9124 supports multiple signatures precisely because different parties can hold different permissions.
  • A local firmware change authorization receipt can connect manifest evidence to policy, rollout admission, activation and observed post-boot outcome. This is Daniel Kade’s editorial proposal, not a SUIT field or IETF requirement.

The green signature is real evidence. It says the protected manifest came from a holder of an accepted key and that the covered bytes have not changed. When the manifest binds a payload digest, the same evidence connects the received image to those instructions. Those are foundational properties for any secure update system.

They are still narrower than permission to execute code.

RFC 9019, published as an IETF Informational RFC in April 2021, is unusually direct about the distinction. It calls a firmware update “authorized remote code execution.” It says authenticated author identities can be inputs to the authorization process, that not every author has the same permissions, and that the device has to decide whether the requested action falls within the signer’s permission. The signature supplies an identity claim. Authorization policy supplies the scope.

That separation is not legal decoration added after the engineering. It is part of the engineering architecture. Firmware can replace executable behavior, alter configuration, load keys, change radio or safety logic, and redirect the device’s future trust decisions. Treating every accepted signer as a universal updater converts a narrow cryptographic trust relationship into control of the product.

The architecture has more than one principal

RFC 9019 distinguishes an author from a device operator, a network operator, a user and a Trust Provisioning Authority. The author creates the firmware image. The device operator runs the fleet day to day. The network operator controls the network to which the device connects. The user may own or interact with the device. The TPA distributes trust anchors and authorization policies and may delegate rights.

Those roles can coincide in a simple product. One manufacturer can create the image, provision the trust anchor, operate the service and decide when every device changes. In that case, one accepted signature may represent the entire configured authorization path. The architecture does not demand a ceremonial second approval where the deployment has deliberately assigned one principal full control.

But role coincidence is a deployment fact, not a property of a signature algorithm. Supply chains split. A component vendor may update a radio stack while an industrial operator controls the maintenance window. A network operator may provide a local delivery path without receiving permission to rewrite the application. A security team may approve emergency remediation while a safety owner controls activation. A customer may own the equipment after the original manufacturer stops supporting it.

The TPA’s policy is therefore the hidden constitution of the update path. It maps keys to roles, roles to components or commands, and sometimes roles to other roles they may delegate. If that mapping is stale, excessively broad or unavailable for inspection, signature verification can work perfectly while authorization fails institutionally.

A trust anchor answers “which key may present evidence?” It does not necessarily answer “which components may that key replace?”, “which devices are in scope?”, “may it change a bootloader?”, or “does it act alone?” The device needs those answers before treating authenticated instructions as executable authority.

Pre-authorization comes before the payload

The firmware consumer receives and parses the manifest, verifies protection and decides whether to fetch or process the referenced image. RFC 9019 names a pre-authorization step: the consumer determines whether the entity signing the manifest is authorized to perform an update. This matters operationally because an unauthorized request should be rejected before scarce bandwidth, energy and flash cycles are spent.

Pre-authorization is not just a key lookup. The requested action has structure. A signer might be authorized for one device class but not another, one component but not the bootloader, configuration data but not executable code, an emergency patch but not a feature change, or a bounded delegation that has expired. A digest can bind the proposed bytes without describing the legitimacy of that scope.

RFC 9019 gives the sharpest example in critical infrastructure. The firmware author may be authentic yet lack unilateral authority to install. The device can be configured to require both the author’s signature and the device operator’s authorization. The second approval does not dispute who wrote the software. It answers a different question: whether this operational principal accepts that change here.

RFC 9124 carries the distinction into the manifest information model. It requires a manifest format to support multiple signatures so authorizations from parties with different permissions can be required for installation. Its operator story is explicit: the operator wants express approval over changes to its devices and wants to ensure interoperability across the product family.

Counting signatures is not enough. Two signatures from keys mapped to the same “author” role do not satisfy a policy requiring author plus operator. Three signatures do not compensate for a missing safety authority. The verifier must evaluate roles, permissions, policy versions and the action covered by each approval. Cryptographic multiplicity becomes governance only when the policy states what each signature contributes.

Delivery, triggering and authority are different

The status tracker can announce an available release, collect characteristics from a device and remotely trigger the update process. RFC 9019 permits the tracker to be operated by an author, device operator, network operator or another suitable stakeholder. That flexibility is useful, but it creates another boundary: the ability to deliver or trigger is not automatically authority to author, approve or install.

A network-side service may tell a device to begin at 02:00 because it controls the maintenance schedule. It need not possess the author’s signing key. A firmware server may store the image and manifest without being allowed to modify either. A gateway can relay a detached manifest to devices that cannot reach the Internet. The transport path can change without changing the signer’s scope.

Conversely, the author’s signature does not decide every timing question. An authentic urgent patch can arrive while the device controls a physical process that cannot be interrupted safely. A valid feature release can exceed a site’s energy budget or break a certified operating configuration. An operator may need canary results, dependency readiness and a recovery image before admitting the update to the wider fleet.

This is why “available,” “downloaded,” “stored,” “authorized,” “installed” and “running” should not be one status. Each describes a transition with different owners and failure modes. A single green badge is convenient precisely because it hides those distinctions.

Sequence is not software progress

RFC 9124 requires a monotonically increasing manifest sequence number so an attacker cannot replay a lower-sequence valid manifest. But it carefully says that the sequence is not a firmware-version field. A new manifest with a higher sequence number can deliberately authorize an older firmware version.

That exception is not a loophole. It can be necessary when a new release fails in the field and the accountable authority chooses to return to a known version. The new policy decision is represented by the new manifest sequence even though the payload version moves backward. The anti-replay invariant remains intact because the authorization object is newer.

A dashboard that labels every lower firmware version “rollback attack” therefore overstates what it knows. The relevant questions are whether the manifest sequence is current, whether the signer or signer set had rollback authority, whether the precursor and target conditions match, and whether the operating risk justified the change. Version direction alone cannot answer them.

The reverse error is equally dangerous. A higher firmware version does not prove that the change is authorized. An attacker with an over-privileged signing key, or an authentic vendor acting beyond the operator’s policy, can present software whose version number increases. “Newest” is not a permission category.

Applicability is more than authenticity

Many IoT devices contain multiple microcontrollers. A complete change can require several images and manifests, dependencies across components, an expected precursor, a particular storage target and coordinated activation. RFC 9124 includes vendor, class and device identifiers, component identifiers, precursor digests, dependencies, payload formats, processing steps and installation instructions because an authentic blob can still be wrong for the current state.

A valid differential update fails if its precursor is not the image actually installed. A radio component can be authentic but intended for another hardware class. Two individually valid component updates can be incompatible when activated together. An image can be stored correctly yet leave the recovery partition unavailable. These are not signature failures.

The manifest can carry machine-readable conditions, but a condition only protects what the policy made explicit and the implementation checks. Site conditions may live elsewhere: controlled equipment must be stopped, backup power must be available, a dependent service must already be upgraded, or an operator must be present. RFC 9124 even allows additional installation instructions such as time windows and pre- or post-installation steps.

The governance task is not to move every operational fact into one universal manifest. It is to preserve the join between common authenticated instructions and local admission facts. The manifest can say what the update requires. The operator must still prove that those requirements and its own constraints were satisfied for the selected cohort.

Installed is not invoked, and invoked is not healthy

RFC 9019 separates the firmware consumer from the firmware verifier. The consumer handles the manifest and stores the image. The verifier, often a bootloader or another higher-trust component, checks the image before invocation. When a newly available image is invalid, the device needs a recovery strategy: select another valid image or obtain one.

That separation creates a temporal trap in status reporting. The RFC’s example flow includes a “Firmware Update Completed” message before the later reboot, secure-boot verification and activation of the new firmware. The message is not fraudulent. It reports completion of the update stage represented in that exchange. It simply cannot prove events that occur afterward.

After reboot, the bootloader may reject the image. The image may start but fail a health check. A multi-controller product may activate only part of the intended set. The device may boot and lose network access before sending confirmation. It may recover to the old image. A management server that saw the earlier completion event cannot infer which durable state won.

Running-code evidence begins where artifact evidence ends. The operator needs a bounded post-boot observation: selected image or measurement, component set, boot result, essential service health, recovery state and the time at which the evidence was collected. No single signal proves universal safety, but it can prove that the intended transition reached a defined operational checkpoint.

Attestation can contribute evidence about loaded components. It still does not replace authorization or business outcome. A measured image can be exactly the image that should not have been installed on this production line. Conversely, a locally authorized rollback can be correct even though it loads an older version. Measurement says what ran; governance records why it was permitted and what happened next.

Automatic updates still need an accountable policy

RFC 9019 correctly observes that constrained IoT devices often need unattended updates. They may have no interface, operate remotely, and remain deployed for years. Requiring a human to click every device can leave known vulnerabilities unpatched and make fleet security impossible at scale.

Unattended does not mean unauthorised. It means the authorization decision was expressed in advance as policy: which signers, actions, device classes, windows, emergency conditions and recovery behavior are acceptable. A device can execute that policy without a person present. The more automatic the change, the more important it is that the policy is bounded, versioned and observable.

The 2016 IoTSU workshop record, later published as RFC 8240, shows why the boundary exceeds cryptography. Participants raised ownership and control, user consent, recovery, end of support, long-lived devices and the need to determine whether an update succeeded. The report is not a standards-track mandate and does not turn every workshop view into an IAB position. It does preserve the design pressure that led to a role-aware architecture.

End of support is especially revealing. If the original vendor disappears, the old signing hierarchy may remain cryptographically valid while no one supplies fixes. A successor maintainer may be technically capable but lack a delegated key. Transferring authority safely requires more than accepting any new signature: it needs a legitimate local decision about who may inherit which update rights, how the previous authority is retired and how devices learn the change.

A firmware change authorization receipt

The practical repair is a local, minimized receipt that follows one proposed executable change from evidence to outcome. It does not replace the manifest, add a public inventory or instruct devices remotely. It records why this organization treated a particular authenticated proposal as authorized.

The first section binds the manifest hash, payload digest, manifest sequence, declared firmware version, device class, component and precursor or dependency state. It identifies the authorization-policy version and the trust-anchor or delegated-key references used. It records the role assigned to each signer and which required approval set was satisfied.

The second section records rollout admission: selected cohort, maintenance window, device or site prerequisites, canary evidence, recovery image or alternate path, responsible operator and the decision to proceed, defer or reject. Sensitive fleet identifiers, detailed topology, keys and vulnerability exposure should remain outside a broadly readable receipt. Hashes, scoped identifiers and access-controlled references are usually sufficient.

The third section records transition state. Was the payload downloaded and stored? Did installation complete? Which verifier accepted the image? Which components became active after reboot? Did the expected post-boot health checkpoint arrive? If recovery or an intentional rollback occurred, which higher-sequence authorization approved it and what final version remained in service?

The final section closes authority. It records expiry or retirement of temporary permissions, unresolved devices, quarantined cohorts, evidence retention and the owner of any follow-up. A fleet percentage is not a substitute for item-level exception ownership; nor should the receipt expose a public map of vulnerable devices.

This receipt is Daniel Kade’s editorial proposal. It is not a SUIT manifest element, an IETF requirement, a new signature, a TPA product or a claim that existing protocols are incomplete. Its purpose is to stop an organization from using the protocol’s strongest evidence to answer questions that the evidence was never designed to settle.

Keep every proposition honest

A mature update system can now tell a precise sequence. The manifest and image were authentic. The signer held the relevant permission under a named policy. The required co-authorizations were present. Device and component conditions matched. The local operator admitted a cohort at a recoverable time. Installation completed. The verifier invoked the intended image. Post-boot evidence showed the defined services running. Exceptions entered recovery and their authority was closed.

Any one proposition can fail while others remain true. A real author can exceed scope. An authorized change can arrive at a dangerous time. A correctly installed image can fail to boot. A successful boot can still degrade the physical system. A secure rollback can move to an older version under a newer authorization. A delivery service can perform its job without becoming a software sovereign.

Heng Lu’s distinction among minimum specification, localized decision, voluntary adoption, running execution and observed outcome keeps these states from collapsing. RFC 9019 and RFC 9124 give independent systems a disciplined language for authenticated update instructions. They do not remove the operator’s duty to decide, observe and recover.

The signature should stay green when it verifies. The installation decision deserves its own state.

Sources