In Uptane, full verification cross-checks metadata from both repositories and survives a key compromise on either side. Partial verification checks only the director's Targets metadata and the time. A primary unit must do full verification. A secondary should if it can, and must do at least partial.
What full verification checks
Full verification confirms that the director's Targets metadata matches the image repository's Targets metadata. That needs the Root, Timestamp, Snapshot and Targets metadata from both repositories. The cross check is what gives resilience: a compromised director cannot tell a unit to install something the image repository never signed.
What partial verification checks
Partial verification looks only at the director's Targets metadata and the time. It is the minimum allowed for secondary units that cannot do full verification. Implementers may add further checks.
The trade is plain. A partial verifier trusts the director more. If the director is compromised, a partial verifier has less to detect it with.
Why the split exists
Vehicles contain control units with very different resources. A powerful gateway can store and process several metadata files. A small unit managing a window motor may have little memory and no cryptographic accelerator. Forcing full checks on every unit could make adoption impossible, so the standard sets a floor for secondaries and a higher bar for the primary that carries the load.
A decision guide
Ask these questions for each secondary unit:
- What can it do if compromised? Units that affect safety or hold keys deserve full verification.
- Can it hold the metadata? If the memory is there, use full verification.
- Is it reachable only through the primary? A unit behind a gateway has a smaller attack surface, which lowers the need.
- Can you add checks to partial verification? Hardware identifiers and release counters in custom metadata add protection even if the director is compromised, according to the standard.
- Is the primary trustworthy enough to carry the work? A weak primary weakens everything below it.
Related protections
The standard requires version numbers, expiration times and signatures on metadata. Units must have a trustworthy source of time to detect freeze attacks, and signed version reports include nonces or counters to stop replays. These apply regardless of verification level, and a partial verifier still depends on a secure time source.
Recording the decision
Whichever level you pick for a unit, write down why. A short table listing each unit, its verification level, its memory limits and its compromise impact is enough. Auditors and new engineers both benefit, and the table shows quickly if a design change moves a unit into a riskier category than before.
One more practical point: verification level should be revisited when a unit gains new features. A unit that once only reported a sensor value may later accept commands, and that change can justify moving it from partial to full verification.
Quick check
Can a primary unit use partial verification?
No. The standard says a primary must perform full verification.
Does partial verification mean no verification?
No. It still checks signed director metadata and the time.
Sources
Last reviewed: 19 October 2026.
