Bring long offline devices current by offering an update path that works from any starting version, keeping the trust metadata they need valid, and moving them through any required intermediate steps. Until they check in, count them as unknown in your inventory, not as patched.
What breaks when a device is far behind
Three things commonly fail. A delta that expects a specific previous version will not apply. Signing metadata may have expired or been rotated while the device was away, so it rejects the update. And a release may assume a migration that an intermediate release performed, such as a data format change.
Plan the path
| Problem | Option |
|---|---|
| Version bound delta | Fall back to a full or adaptive update |
| Expired metadata | Allow a safe refresh path through keys the device already trusts |
| Missing migration | Use a stepping stone release that performs it |
| Storage too small for a big jump | Download in blocks, or install in stages |
RAUC describes adaptive updates as not needing a specific previous version: they carry information that lets the installer use data already on the system from any earlier version, or from an interrupted attempt. That fits devices returning from long absences.
Steps
- Keep a list of the oldest release you still support updating from.
- Test an update from that release at every release cycle, on real hardware or a close copy.
- Decide how long signing metadata lasts and what a device does after it lapses. Plan a rotation of keys so devices that miss one rotation can still catch up.
- Mark required stepping stone releases in the metadata, so the server can sequence them.
- After a device checks in, send the oldest needed step first, then the rest.
- Track returning devices as a group and watch their failure rate separately, because they fail differently.
Be honest in the inventory
A device offline since spring is running whatever it had in spring. If a vulnerable component was in that release, the device is exposed to whatever it can still reach. In your numbers, show three groups: updated, reachable and pending, and unreachable. Reporting the share updated without the unreachable group overstates how safe the fleet is.
For devices that stay unreachable, decide in advance what happens: remote disable where possible, a customer notice, or a recall. That decision is a business one, so write it down with an owner.
If the stored SBOMs for old releases exist, Safeguard can show which stale releases carry known vulnerable components so you know which sleeping devices matter most. Try gold.safeguard.sh/scan.
Communicate with owners
When a unit returns after a long absence, the owner may be surprised by a large update. Tell them what is happening, how long it takes, and what to do if it stalls. Offer a support route for devices that fail the catch up, and decide whether to replace instead of repair when a unit cannot recover. Keep notes on why each returning device failed, because patterns often point to one hardware batch or one release.
Quick check
Should offline devices count as patched?
No. Count them separately as unknown until they check in and report their release.
Why test updates from the oldest supported release?
That is the path most likely to break, and it is the one returning devices will take.
Sources
Last reviewed: 19 October 2026.
