Should homebrew gadgets ship with signed firmware by default?

I’m building a Raspberry Pi greenhouse sensor that will eventually accept updates over Wi-Fi, and I’ve changed my mind about unsigned firmware. If someone compromises the update path, they could feed me false temperature readings or quietly repurpose the device. For anything internet-connected—or controlling a door, heater, or robot—I think signed updates should be the default.

But I don’t want “secure” to mean the owner is locked out. Raspberry Pi’s secure-boot model can make configuration effectively irreversible, and losing the signing key can block trusted updates or recovery. My preferred compromise is an owner-generated key, a physical recovery switch, documented recovery images, dual-slot updates with automatic rollback, and a transparent way to inspect version and security status. Those are design goals, not features I’m assuming every Pi already has. Would that preserve the maker spirit, or are there better patterns? Share your designs, counterarguments, or examples from your own projects.

I agree with signed updates by default for anything exposed to a network. The important distinction is who controls authorization. A vendor key gives the vendor authority; an owner key gives the owner authority. For a personal gadget, I’d rather see the latter, even if setup is slightly less convenient.

The dual-slot idea is the practical center of this. Verification answers “who signed it?” Rollback answers “what happens when the signed update is broken?” I’d also want recovery to be boring and documented, not dependent on a cloud service that may disappear.

I’d make the recovery image available offline and keep it on removable media. If the device can only be repaired through an online account, it isn’t really owner-controlled. A physical recovery path also makes a better failure story than hoping the bootloader guesses correctly.

The research distinction matters here: authenticated updates and rollback are not opposites. NIST’s IoT baseline recommends both authorized updates and the ability to return to an earlier version. The unresolved policy question is who counts as authorized—the manufacturer, the current owner, or both.

User-controlled keys sound right, but key loss is a real usability failure, not just a security failure. I’d want a clearly documented key rotation and recovery ceremony before enabling secure boot. Otherwise people will choose “no security” because it is the only mode they understand.

I’m less convinced about a physical recovery switch on a household controller. If an intruder can reach the box, the switch may become an easy bypass. I’d prefer a deliberate recovery procedure requiring physical access plus a recovery secret, with the tradeoff explained plainly.

The interface around this may matter more than the cryptography. Tell the owner exactly what is locked, which key is in charge, whether rollback is allowed, and how to recover before provisioning burns anything permanent. “Are you sure?” is not documentation.

For a weekend robot, I’d leave it unsigned. For a Wi-Fi door controller, I’d sign it. “By default” is doing too much work here; the threat model should be printed on the setup page, not hidden in a security menu.

A/B images with automatic rollback are useful, but don’t confuse booting with correctness. A malicious image can be perfectly signed if the key is stolen, and a buggy image can pass verification. Keep logs and make the active slot easy to identify during recovery.