Should repairable hardware permit owner-signed firmware after support ends?

I’m broadly in favor of cryptographic firmware signing: a router or laptop should not accept arbitrary code just because someone can reach its recovery interface. Verified boot can also block rollback to vulnerable versions. But a locked signing chain becomes a different problem when the vendor stops supporting hardware. If the update server disappears, the key is lost, or the bootloader rejects anything outside the vendor pipeline, ownership starts looking like a time-limited service.

For a router, should the manufacturer provide a documented local recovery path, reproducible firmware builds, an escrowed signing process, or a physically initiated owner-unlock mode? My instinct is to keep verification and rollback protection on by default, with prominent warnings and a deliberate unlock step. But who accepts responsibility if modified firmware damages equipment or exposes a network?

I’d like disagreement, repair experiences, or a safer technical standard than my rough proposal.

The owner-unlock mode should be physically initiated and irreversible without another physical action. Otherwise malware that gains administrative access can silently downgrade the trust model. I would treat this as a separate boot state with a clear warning, not as a hidden developer switch.

I’d separate three things: signature enforcement, rollback policy, and key custody. A vendor can publish signed images locally without keeping an update server alive. Reproducible builds help auditors, but they do not by themselves create a trusted signing key.

The responsibility question is probably the least settled part. A warning screen may clarify user choice, but it does not magically resolve product-liability or network-harm questions. I’d want vendors to state exactly what remains supported after unlock, rather than implying the device is simply “free” afterward.

A recovery image sitting on a vendor website is not a durable plan. Mirrors, printed recovery instructions, and a bootloader that accepts signed files from storage seem less fragile. The boring part is usually the part that survives.

The commercial objection is understandable: testing every third-party image is impossible. But that argues for a clear support boundary, not for making the hardware unrepairable. “We won’t troubleshoot unlocked firmware” is a much cleaner promise than “you may not install it.”

I’m not convinced escrowed vendor keys are safe. An escrow system creates another high-value target and another institution whose failure matters. I’d prefer a documented owner key enrolled during manufacturing or purchase, with revocation and recovery rules designed before the device ships.

The local path matters even if nobody uses it today. A signed image on removable storage, a documented recovery procedure, and build instructions preserve a future option without requiring the default device to become permissive.

Please don’t make the unlock experience a frightening legal wall of text. Show the exact tradeoff: signature checks disabled or changed, rollback protection status, lost vendor support, and how to return to the locked state. Good consent is part of the security design.

For organizations, an owner-controlled unlock could complicate asset governance. That is manageable if the device exposes its trust state clearly and logs changes locally. Procurement teams can require locked mode; independent owners can choose otherwise.

Reproducibility is valuable, but “same source produces the same bits” still leaves toolchains, hardware assumptions, and signing policy. I’d want a small, boring recovery verifier whose behavior is documented and testable, not a giant opaque update stack.

For an inexpensive router, replacing it may cost less than maintaining a secure firmware fork. That still doesn’t justify vendor lock-in; it just means the technical standard should make community maintenance cheap enough to be realistic.

Recovery procedures need a support matrix. “Works on this model and bootloader revision” is much safer than a generic flashing guide that turns a bad file into a brick. Documentation quality is an operational control, not decoration.

I’d be careful with the word “escrow.” If it means a third party can sign arbitrary firmware, that weakens the threat model. If it means a controlled succession mechanism for the trust root, the design needs explicit access rules, auditing, and revocation.

The underlying incentive is awkward: vendors benefit from a closed chain while selling the object as durable hardware. A standard owner-unlock mode could make the boundary visible at sale time. I don’t expect it to solve every liability issue, but it would reduce the surprise.