Secure firmware OTA update design, explained

An OTA pipeline that only asks "is this image signed" is checking one control out of several that have to hold together. NIST SP 800-193 and the IETF's SUIT architecture (RFC 9019) describe largely the same set, organized slightly differently:

A device that only checks "is this image validly signed" will happily reinstall an old firmware version — one the vendor already patched a known vulnerability in — because an old, legitimately signed image is still a validly signed image. RFC 9124 closes that gap by requiring every SUIT manifest to carry a monotonically increasing sequence number specifically "to prevent malicious actors from reverting a firmware update against the policies of the relevant authority," which "must not wrap around." On the device side, the update agent compares that number to the one in the currently installed manifest and refuses to apply anything that does not strictly increase it. NIST SP 800-193 frames the attacker motive directly: unauthorized rollback "could allow an attacker to restore a vulnerable firmware image, which in turn could allow the attacker to damage the device or inject malware" — and it explicitly does not forbid rollback outright, since a legitimate rollback path is sometimes the only way to recover from a bad update. It requires that path to carry its own authorization (physical presence, in SP 800-193's own examples) rather than being the update agent's default behavior for any validly signed image.

TLS on the download connection authenticates the server and encrypts the pipe; it does not authenticate the firmware. RFC 9019 is explicit that a firmware update's end-to-end security rests on three separately-stated properties — authentication of "the author(s) creating firmware images and manifests," integrity protection so "no third party can modify the manifest or the firmware image," and, optionally, confidentiality — all of which the architecture roots in signatures verified by the device itself, not in whatever transport carried the bytes. The practical consequence: a compromised update server, a malicious CDN edge, or a man-in-the-middle holding a trusted-but-wrong certificate can each terminate TLS perfectly correctly while serving firmware the device's actual owner never authorized. RFC 9019 names the real stakes bluntly — "an update is essentially authorized remote code execution, so any security problems in the update process expose that remote code execution system" — which is why a signed manifest, verified offline against a key the device itself holds, has to be the control that actually gates installation, with TLS as defense-in-depth around it, not a substitute for it.

• No anti-rollback check at all — any validly signed image installs, including an old one with a known, public CVE.
• A single online signing key with no compromise plan. The Update Framework's own threat model flags this directly: a design should survive "an attacker who is able to compromise a single key or less than a given threshold of keys" without compromising clients fleet-wide; a lone online key is the opposite of that.
• No manifest expiry/freshness check — TUF calls the resulting gap a "freeze attack," where a device keeps accepting stale metadata and never learns a critical update exists.
• Verification happening after the image is already written to the active flash region, rather than, per NIST SP 800-193 §4.2.1.1, "prior to the non-volatile storage completion of the update process" — by the time a late check fails, the bad image may already be what the bootloader runs next.
• A bypassable update path — a diagnostic UART, JTAG header, or legacy unauthenticated update mode left reachable in production that skips the signed-update flow entirely.
• No automatic or manual recovery from a failed/corrupted update. ISO 24089's software-update-engineering process and NIST SP 800-193's Root of Trust for Recovery both exist because "verify, then refuse to boot" with no recovery path turns a detected attack (or just a bad update) into a bricked fleet.
• No record of which update-stack components (TLS library, manifest parser, signature-verification routine) shipped in a given build. ENISA's 2019 secure-SDLC report lists "secure remote (over-the-air) update delivery" as an ongoing Maintenance and Disposal obligation, not a one-time launch task — which only works if a team still knows what is running in that update path on an already-shipped device; this is exactly the gap a firmware SBOM is built to close.

SoftWSP's firmware analysis identifies the update-related components actually present in a shipped image — the TLS library, manifest/signature-verification library, and update-agent binary — and records them in the device's firmware SBOM, the same way it inventories every other component. From there, AI-assisted analysis matches each identified component and version against known CVE data, the same CVE-matching step used across the rest of a scan, so a known vulnerability in, say, an outdated mbedTLS or a bundled signature-verification library in the update path is flagged like any other component-level finding. Where a firmware image appears to implement its own update-installation logic but no recognizable signature-verification library or routine is present in that code path, that absence is flagged as a finding for an engineer to confirm — not treated as proof the update mechanism is insecure, since verification can also be implemented in a way static analysis does not recognize (a vendor-specific routine, or logic in a separate secure bootloader image outside the scanned file). An engineer reviews every flagged finding before it reaches a report; SoftWSP does not claim to test whether a device's anti-rollback check or signing key management is actually enforced correctly at runtime, only what the static evidence in the firmware image shows.

Secure boot and a hardware root of trust is the mechanism an OTA update's signature check ultimately has to be anchored in — without it, the verification code that checks a new image's signature is itself just more software an attacker who controls storage could replace. For the testing methodology used to independently verify boot-chain and update claims rather than take a vendor's word for them, see OWASP's firmware security testing methodology.

SoftWSP's Device & Firmware Security service reviews an update pipeline's signing, manifest and anti-rollback design against the device's actual constraints, and flags update-stack components with known CVEs in the resulting firmware SBOM: see Device & Firmware Security.

This guide draws on NIST's and the IETF's published technical documents, the cited ENISA report, and the publicly available TUF specification, cross-checked against each primary source directly. It is not a substitute for those documents' own text, or for an engineer's assessment of a specific device's update architecture.