21 Secure OTA Updates
Signed Manifests, Safe Install Slots, and Rollout Evidence
IoT OTA updates, secure firmware update, signed update manifest, rollback protection, update recovery, staged rollout
21.1 Start With the Update That Does Not Install
Imagine a fleet update arriving overnight. Most devices accept it, but one device sees a wrong target, a bad signature, or a version lower than policy allows. The important security story is not only the successful install. It is whether the device refuses the bad candidate, keeps the current working firmware, records the reason, and gives the operator enough evidence to act.
Start simple: track one firmware package from release approval to device decision. The signed manifest says what the package is, the inactive slot keeps the old image safe, the first boot health check decides whether to accept or revert, and the rollout record explains what happened. Without that chain, “OTA is secure” is only a slogan.
21.2 Overview: An Update Is Only as Safe as Its Path
Over-the-air updates are a security control only when the update path is itself controlled. A device should not install new firmware merely because it was downloaded from the expected service. It should verify that the update is meant for that device class, that the package matches the signed manifest, that the version policy allows it, and that recovery remains possible if the candidate firmware fails its first health checks.
The review goal is practical: can another reviewer trace an update from release approval to device acceptance and then find evidence that the device either accepted the update safely or rejected it without losing the last known working firmware?
If you only need the intuition, this layer is enough: secure OTA needs both authenticity (the right, signed, targeted firmware) and recovery (a way back to known-good firmware if the update fails). Authenticity without recovery can still leave a device unusable.
An OTA update crosses several boundaries: build approval, signing, storage, delivery, device verification, installation, restart, and reporting. A protected transport path helps, but it does not prove the update is authorized, targeted to the correct device class, or safe to install. The package store can make files available, but the signed manifest and device-side verification decide whether a package is accepted.
The best review evidence covers both success and refusal. A release team should be able to show a normal update, a bad-signature rejection, a wrong-target rejection, a rollback-policy rejection, and a recovery decision after a failed health check.
21.2.1 The One-Minute View
Verify, do not trust the source
The delivery path is not the root of trust; the device verifies a signed manifest before writing any firmware.
Preserve known-good
Install into an inactive slot so the last working firmware survives an interrupted or faulty update.
Prove the outcome
Record accept, reject, revert, retry, and pause decisions, not just that a download completed.
21.2.2 Beginner Examples
- A device that installs firmware just because the download finished has trusted the path, not the firmware.
- A device that rejects a bad package but overwrote its working slot first may be left unusable.
- “The update is secure because it is signed” omits targeting, version policy, recovery, and rollout evidence.
21.2.3 Overview Knowledge Check
If you can state why authenticity and recovery are both required, you can stop here. Continue to Practitioner to review a real update flow.
21.3 Practitioner: Review a Candidate Update End to End
A secure OTA design normally separates the manifest from the firmware package. The manifest is small enough to verify first and should describe everything the device needs to decide before installing anything.
21.3.1 Walkthrough: From Manifest to Decision
- Name the scope. Device class, firmware line, release reason, and expected management path.
- Verify the signed manifest. Before trusting the package at all.
- Check the package. Confirm the hash, target device class, and version policy.
- Install to the candidate slot. Keep the known-good firmware until health checks pass.
- Decide on evidence. Accept, reject, revert, retry, or pause based on results.
- Record assumptions and retest triggers. Signing keys, manifest format, boot logic, storage, or health checks.
21.3.2 What a Signed Manifest Should Bind
A useful manifest review asks whether the signed metadata includes the target device class or hardware revision, the candidate version and the minimum version policy, a cryptographic hash of the package, the signing authority and key identity, locally checkable install requirements, and a clear rejection behavior when any check fails. The package can move over an ordinary delivery path, but the device compares it with the signed manifest before writing it to an install slot. Transport protection still matters, but it is a separate control, not a replacement for manifest and package verification.
When this evidence is missing, reviewers should avoid accepting vague phrases such as “released by the cloud” or “downloaded securely.” The device is the final enforcement point, so the record must show what the device checked locally before it changed the boot choice. Record timestamps make that enforcement auditable.
21.3.3 Install Slots and Recovery
Current slot preserved
The known working firmware remains intact while the candidate slot is written.
Boot only after verify
The boot choice changes only after the candidate passes signature, hash, and version checks.
Revert on failure
A failed health check returns to the known working slot when recovery is allowed, and the result is reported.
21.3.4 Rollback Policy: Two Different Cases
Recovery revert returns to the last known working slot because the candidate failed health checks; this is desirable. Downgrade attack installs an older signed firmware to reopen a fixed weakness; this must be blocked. A sound policy allows defined recovery while blocking unsafe downgrade, and the minimum accepted version should be device-enforced rather than only checked by a service.
21.3.5 Worked Review
A gateway receives a firmware update through a management service. A weak review says “the update is secure because it is signed.” A stronger review separates the claim into manifest, install, and rollout evidence.
21.3.6 Practitioner Knowledge Check
If you can review manifest, install, and rollout evidence, you can stop here. Continue to Under the Hood for install-state vocabulary and negative-case testing.
21.4 Under the Hood: Install-State Vocabulary and Negative Tests
The deeper layer makes the rollout reviewable across systems. Secure OTA review does not end at signature verification: a release can be authentic and still fail health checks, so the device, gateway, and update service must describe the same states with the same names.
21.4.1 Install-State Labels
The exact naming varies by system, but a consistent vocabulary lets reviewers confirm that the update service, gateway logs, and device reports use matching state names.
If state names vary between the update service, gateway records, and device logs, a review gap exists: a reviewer cannot tell which state the device was in when a failure occurred.
21.4.2 Require a Negative-Case Test
Require at least one controlled negative-case test: a deliberately invalid package, tampered hash, or version-policy violation that the device should reject before install. Without a rejection record, the verification claim is supported only for the allowed case. The same logic applies to recovery: a tested revert after a failed health check is what supports the availability claim.
21.4.3 Rollout and Monitoring Evidence
A rollout should provide evidence for acceptance, rejection, revert, retry, and pause decisions, including the manifest signature and package-hash results, the target and version-policy results, the slot-write and boot-choice results, the health-check result after startup, the device or gateway status report, a monitor signal that can pause rollout when rejection or revert behavior is abnormal, and a retest trigger for changes to signing keys, manifest format, boot logic, storage, or health checks. Avoid accepting a rollout claim that reports only download completion.
21.4.4 Common Mistakes
- Treating download success as update success. Delivery is not acceptance.
- Trusting the package store instead of a signed manifest. The store makes files available; it is not the root of trust.
- Checking a signature but not target, version, or hash. All four are part of acceptance.
- Confusing recovery revert with permission to install older vulnerable firmware. They are different decisions.
- Reporting only final success. Reject, revert, and retry cases need enough evidence to diagnose.
21.4.5 Under-the-Hood Knowledge Check
At this depth, secure OTA is a traceable record: a signed manifest verified before trust, a package checked against it, a candidate installed without destroying the known-good image, named install states shared across systems, a tested rejection and a tested revert, and rollout evidence for every decision.
21.5 Summary
- OTA update security depends on signed manifests, package integrity checks, version policy, safe install behavior, and reviewable evidence.
- A protected delivery path is useful, but it does not replace device-side manifest and package verification.
- Candidate install slots preserve a known working firmware while the update is tested.
- Recovery revert and downgrade prevention are different controls and should be reviewed separately.
- Consistent install-state names across service, gateway, and device let a reviewer tell which state a failure left the device in.
- A negative-case test and a tested revert are what support the verification and availability claims.
OTA security depends on signed, targeted packages verified on the device, safe candidate-slot installation, device-enforced rollback policy, rollout telemetry, and a tested recovery path for failed updates, not on download success alone.
21.6 See Also
See how startup verification reinforces firmware trust after an update is installed.
IoT Security Network Segmentation
Limit how update and management paths are exposed across the network.
IoT Security Intrusion Detection
Monitor failed update checks and unexpected management behavior.