A device with several processors should send one signed report at each check-in listing what every part is running. The server compares that report with its inventory, works out which updates apply, and respects dependencies and conflicts between images. The Uptane standard describes this pattern for vehicles, and it fits other multi-part devices too.
The pattern in plain words
Uptane is a security framework for over the air updates of vehicle computers, called ECUs. It names a Director repository that decides what each ECU should install, and an Image repository that holds the signed images and metadata. The key input to that decision is the vehicle version manifest, which a Primary ECU builds and sends to the Director. The standard lists it as the first of seven steps a Primary performs: construct and send the manifest, then check time, verify metadata, verify images, and pass time, metadata, and images to Secondaries.
The Director extracts the installed images from the manifest. It determines whether the vehicle is already up to date and, if not, which images could be installed. The standard says the Director shall take into account dependencies and conflicts between images. It also advises checking a nonce or counter in each report so a replayed report is dropped.
What this means for a fleet owner
You can copy the shape without using the full framework.
- Give each component an identity: hardware model, serial, and slot.
- Make the device collect the current version and hash of every component.
- Sign or authenticate the report with a per-device key.
- Include a counter or nonce so an old report cannot be replayed.
- Let the server, not the device, decide the target set, using a compatibility table.
- Store the report. It is strong evidence of what was in the field on a given day.
What goes in the report
| Field | Why it matters |
|---|---|
| Component ID and hardware model | Targeting and compatibility |
| Installed image hash | Proves exactly what runs |
| Version string | Human readable |
| Update state | Pending, installed, rolled back |
| Counter or nonce | Replay defense |
| Time of report | Freshness for the inventory |
Why the server should decide
If each part decides alone, you can end up with valid but incompatible versions across components. Uptane names this a mix and match attack: a bundle where each image is valid, yet some do not work together. A central view of the whole device avoids it, and so does a compatibility table kept with the releases.
The report also feeds your component inventory. Safeguard can take the SBOMs that map to those reported versions and match them against new advisories. Try gold.safeguard.sh/scan on one SBOM to see the output.
Pitfalls
Reports can be wrong. A component may fail to read its own version, or a cached value may be stale. Prefer the hash of what is actually installed over a label in a text file. Keep reports small, since constrained links make large check-ins costly. And decide what the server does with a device that reports nothing for one component: treat it as unknown, flag it, and avoid sending an update that assumes a version you have not seen.
Quick check
Does my device need the full Uptane framework?
Not necessarily. The version report, central decision, and replay protection can be adopted on their own.
Why include a counter in the report?
The Uptane standard advises checking a nonce or counter so a replayed report can be dropped.
Sources
Last reviewed: 19 October 2026.
