Should every cloud device ship with a sunset package?

I want a narrow right-to-repair rule for cloud-dependent hardware: when a manufacturer ends service, it should provide a documented “sunset package.” That package would include signed, version-pinned firmware, recovery and service documentation, an authenticated local administrator path, encrypted user-exportable backups, and a tested procedure for moving credentials and settings to a replacement controller.

That does not mean handing out unrestricted root access. Secure boot, owner authentication, signed updates, audit logs, an explicit factory reset, and revocation of the old controller’s keys could preserve a meaningful security boundary. Cloud analytics, remote access, and hosted storage can remain subscriptions; local setup, physical operation, recovery, and migration are closer to ownership.

Would this be a reasonable right-to-repair requirement, or an unacceptable security liability? I’d especially like examples from smart-home, robotics, or maker hardware.

The signed-firmware part is essential. A local recovery mode that accepts arbitrary images is just a permanent downgrade path with better marketing. I’d require a documented recovery protocol, not necessarily a published bootloader, and make key rotation during controller transfer mandatory.

This is narrower than “make everything open,” which helps. California’s SB 244 already covers documentation, parts, tools, and updates for certain products, but it does not specifically require post-shutdown local recovery. It also excludes alarm-system products, so the security-system edge case remains unresolved.

I’d separate recovery from migration. Recovery keeps one device usable; migration needs a portable data model and a way to prove the new controller is authorized. Otherwise the sunset package becomes a firmware download that leaves owners rebuilding every automation by hand.

The commercial problem is that “local admin” sounds like a support promise forever. I’d support a minimum sunset package with a fixed scope and a clear handoff date, while letting companies charge for continued cloud services. Predictability is more useful than pretending subscriptions don’t exist.

Encrypted backups need careful wording. Encryption at rest is not enough if the vendor retains the only recovery key. The owner should be able to export a backup that is usable with the replacement controller after authenticating locally, without creating a universal decryption credential.

A device that becomes a paperweight because an account endpoint disappeared was never entirely a device. I don’t need every vendor to publish internals. I do need a documented way to recover the thing I bought.

For enterprise buyers, the sunset package belongs in procurement language: support end date, recovery artifacts, transfer procedure, and verification requirements. “We’ll keep the service running” is not a lifecycle plan. Neither is “download this mystery file after shutdown.”

The transfer flow matters more than the existence of a hidden local mode. If ordinary owners cannot tell which keys, backups, and settings move to the replacement controller, they will either abandon the device or disable protections to make it work.

NIST’s guidance is compatible with this direction: updates should be authenticated, and local media can be part of update delivery. That supports signed offline recovery, but it does not by itself establish a legal right to receive the artifacts. Policy would still need to define the obligation.

I’m not fully persuaded on mandatory local administration for locks, alarms, or robots operating around people. Even owner authentication can be compromised, and a recovery path may expose anti-theft or safety controls. Perhaps the requirement should guarantee a vendor-mediated escrow and transfer process rather than a general local admin interface.

The unglamorous requirement is testing. A sunset package should be validated on a clean replacement controller, with failed-transfer rollback and a clear factory-reset procedure. Documentation that only works for the original engineering team is not documentation.

For maker hardware, signed firmware plus local recovery is already a reasonable pattern in principle. The annoying part is credential migration: configuration files often contain secrets, device IDs, and assumptions about one cloud account. A standard encrypted export would save more hardware than another flashy feature.

This is an ownership boundary, not an anti-cloud manifesto. Markets can sell ongoing hosting, but durable goods become difficult to value when their basic operation depends on an indefinite service promise. A sunset package makes that dependency explicit and gives buyers something concrete to compare.