Deactivation and disconnections: How will an IoT product die?

I get an email from a ghost every month. My Lux thermostat, which I removed from my wall sometime in 2018 after deactivating the app, sends me an email with the subject, “Your Wireless Thermostat Is Offline.” Technically, the thermostat isn’t sending me the email; a server controlled by Johnson Controls (Johnson Controls purchased Lux in 2018) sends it.

The ghost of that thermostat haunts my inbox because somewhere during the deactivation process, I missed a step. While writing about it today, I finally followed a link in the email to a web page, thanked my password manager for still knowing my password, and deleted the device, so maybe this will act as an exorcism. But the reason my thermostat ghost was on my mind in the first place is because it was yet another example of how so often with the internet of things companies don’t think about how their devices will die, disconnect, or get deactivated.

And that needs to change.

This isn’t just a consumer problem. In the industrial world, managing devices has spawned entire software companies, and as those devices get woven into systems that govern building comfort or factory automation, disentangling sensors or systems will become even more important.

For example, last month the Industrial Internet Consortium (IIC) issued a paper about building trustworthy software for a connected era in which it called out the need to have a plan for the end-of-life stage of software (it defined end of life as when the producer no longer supports the software). At that point, organizations that use the dying software do so at their own risk, and also can create risks throughout the system.

The current challenges faced by government agencies trying to update unemployment agencies that use 50-year-old code is an example of what can happen when you operate beyond a software’s end of life. With software in more products controlling more processes and things, the risks are higher, and the damage to an organization’s resiliency rises.

The IIC’s paper focuses on software, but since software is eating the world, and most connected devices have a huge software component, it’s worth broadening the scope to think about both the software and the hardware. Most companies building connected products need to do a better job of thinking about how these devices die, so I’ve come up with some ideas to start with. I’d love to hear more from y’all.

Connected devices often have a physical reset button (remember, for security purposes it should be hard to access), and most now let you delete a device from your user account. There are no standards here, but at a bare minimum devices should offer both of these abilities. I would go even further, however, to ask that companies let people delete their accounts and data associated with connected devices, and delete the data and reset devices remotely.

A remote deletion/deactivation should require multi-factor authentication and perhaps some sort of recovery code that’s kept in a document. This should help people avoid getting notifications about products that have been uninstalled or transferred to new owners. In an enterprise or industrial setting, these functions should be part of any management platform, and usually are.

But that’s only the beginning. Most connected devices are part of a system, which means that the death of a device can create a cascade of problems. Without a standard way for devices to share data, it’s tough to figure out how to let a departing device disconnect from an Amazon Alexa account or a SmartThings routine, but that’s what needs to happen.

A device should offer a proactive notification when you try to remove the device. The notification should remind you that it is connected to other services. At that point, a user may have to manually remove the device from those services, but it would be even better if it did it for them, as part of the deactivation. Something similar should occur in the enterprise world and should likely be managed by the IoT platform, or possibly flagged by security monitoring software, yielding a message along the lines of, “Device X has dropped off the network. Device X often shared data with Device X and Device Y.”

Most of this advice is focused on how a product interoperates with other devices on a local network. But there are cloud elements and mobile applications associated with connected devices. Any device death should happen in the local world, in apps, and on the cloud. If that had happened when I reset and deactivated my thermostat, somewhere a server would have gotten the memo that it no longer needed to send me a monthly email.

As we start cobbling together devices, software, and services to create smarter homes, offices, and factories, vendors must give as much consideration to the end of life as they do to device onboarding. Today, that isn’t happening. But it needs to.