Every smart device is three things wearing one plastic shell. It is hardware on a wall, a record in a cloud account, and a set of automations that reference it by an identifier nobody sees. Selling the house, ending a tenancy, or moving out touches all three, and the usual instruction, factory reset the device, touches only the first. What is left behind is a cloud record that still believes the device exists, a scene that still tries to switch a light that is now in a different postcode, and a new owner who cannot pair a device that looks perfectly normal.
Ownership is split three ways
The hardware belongs to whoever physically has it. The cloud record belongs to the account that paired it. The automations belong to the platform and are written against device identifiers that are meaningless outside that account. None of the three follows the others automatically, and this is why a handover done in the wrong order leaves orphans in both directions: devices that are physically reset but still listed online, and devices that were deleted from the app but never reset, so the next person can pair them and inherit the previous owner's local settings.
What a factory reset does not remove
A reset clears pairing keys, Wi-Fi credentials and local schedules held on the device. It does not delete the device's entry in the cloud account, it does not unbind it from the platform's device registry, and it does nothing to the automations that point at it. So the reset device sits in someone else's account as an offline ghost, and the new owner's pairing attempt is sometimes rejected because the platform still considers it claimed. On some platforms the ghost entry expires after a grace period. On others it sits there until someone with the old account manually removes it, which is a task that ends the moment the old account stops being maintained.
The tenant change: the case that actually happens
A rented flat changes occupants, the previous tenant takes their devices, and the landlord's next tenant cannot use the wall panel because it is still registered to an account nobody answers. The landlord's options are limited: find the old tenant, contact the vendor's support with proof of purchase, or replace the hardware. None of these is documented at the door. The honest fix is procedural, not technical: the tenancy agreement should list which devices are landlord property and which belong to the tenant, the landlord should hold the vendor accounts for landlord-owned devices, and the outgoing tenant should run the platform's own removal flow rather than a bare reset. For the landlord side, the simplest setup is to keep wall-mounted infrastructure dumb, panel and wiring, and let tenants bring their own removable smart layer that they take with them.
The second-hand case: a device you bought, someone else's history
Second-hand hardware is the mirror image of the tenant problem. A hub or camera bought second-hand may arrive factory-reset but still tied to a cloud account, and certain features, remote access, cloud recording, firmware updates, only come alive under the original account. Some vendors offer an ownership transfer with proof of purchase; many do not. Before buying used, check whether the vendor publishes a transfer process and whether the device id can be reassigned at all. If it cannot, the device is a local-only object no matter how capable its spec sheet looks, and you should price it accordingly.
The order that avoids most of the damage
Do the unbinding before the physical reset, and do the physical reset before the device leaves the building. Remove the device from the platform while it is still online, so the cloud entry and the device agree. Delete or archive the automations that referenced it, otherwise you discover them months later when a scene that ran fine starts throwing errors nobody can trace. Then reset the device, pair it fresh, and confirm the new pairing works before the old account is closed. Closing the old account last, after everything is confirmed, is what keeps you able to fix a missed step. Write the sequence down once; the same list works for selling, gifting, or moving.
What the vendor side should make easy
From the manufacturing side, handover is a product requirement, not a support ticket. Three design decisions decide whether a device can change hands cleanly: whether the app exposes an explicit transfer flow instead of delete-and-repair, whether a reset device is claimable by a new account within a bounded time rather than being recoverable only by the old one, and whether the hub distinguishes a landlord's persistent configuration from a tenant's personal one. Vendors who answer these three in their documentation are the ones facility managers and landlords can specify without dreading the move-out call. When comparing suppliers for a project, ask how ownership transfer works in their app and in their cloud, and treat the answer as a specification item, not a courtesy.
If you are specifying hubs and gateways for rented or managed properties, see our gateway range and the gateway and bridge manufacturer page for transfer-friendly pairing options, or the factory homepage and the contact form to discuss a multi-tenant deployment.
Top comments (0)