Field updates fail in boring ways: power loss mid-write, mismatched version metadata, or a recovery image that was never tested after a schema change. When Desktop Leafpoint reviews an OTA design during an architecture assessment or advisory retainer, we keep the conversation on four questions.
1. What survives a cut power event?
Name the exact states. Dual bank, A/B with rollback, or a recovery partition — each has a different story when someone yanks USB mid-flash. If the answer is “we reboot and try again,” say what image runs after that reboot.
2. Who signs, and who can revoke?
Signing keys are a people problem as much as a crypto problem. Document who holds them, how staging differs from production, and what happens when a key must rotate while devices are already in the field.
3. How do you know the fleet accepted the build?
Telemetry is nice; manufacturing and warranty teams need a boring report: version, success/fail, and a way to pause a rollout. If your device is offline by design, describe the next physical touchpoint that can confirm the update.
4. What is deliberately not updatable?
Boot ROM assumptions, calibration data, and regulatory-locked parameters should be listed. Update designs that claim “everything is flexible” usually hide a landmine.
If your answers are fuzzy, that is useful data — it means the next hardware spin or release train still has room to harden the story before devices leave the factory.