I had an interesting chat with a friend: he was reporting to me that his photovoltaic management app wasn’t working anymore. The vendor upgraded the Cloud API breaking compatibility with older products. I expect this more and more in the future.

How firms are developing API

I worked many years with developers. In my experience, once a project is started, developers start to analyze, choose the proper framework, build the software test it maybe with some CI/CD approach and everything is fine. But… sooner or later the framework will become obsolete, so the libraries, so the operating systems. And sooner or later new OS will not be compatible with the old version of the frameworks, and probably the code won’t be compatible with new versions of the framework too.

To me, this is a small form of “lock-in”: the developed software (of course) is bound to a specific version of a specific framework installable on a specific operating system. Sooner or later, upgrading the whole ecosystem will require a deep code review and update.

And that’s the problem.

Product lifecycle

What is missing from the beginning is the product lifecycle. It’s not about developers, it’s about product management and business strategy. If we are developing a new cloud-based game, we can assume that it will stand for a few years:

The cloud infrastructure, API, and software must be maintained, or the business will ve impacted: a data breach or an outage will impact the app’s reputation, the customers, and the revenues.

At some point, the app is retired, simply because revenues won’t cover major upgrades and infrastructures.

As we said, a game will stand for a few years, I guess no more than 3 years.

Sometimes we will see a new product replacing the old one, in that case, customers are usually migrated to the new products with some sort of special offers.

The IoT problem

With IoT, ICS/OT, medical devices, automotive, and building automation products… the playground changes: customers buy products that can be expensive, and those products are expected to stand for many years: 10 years is expected for consumer products, 20 years is expected for industrial/medical products and automotive.

How can we manage a 20 years product lifecycle based on a 5 years OS lifecycle?

Short story: we can’t.

Long story: the problem must be decoupled. We have the device and the cloud services. We could maintain the cloud services, with expensive major upgrades and maintain the API compatibility with legacy devices. That means we must carefully design our API and security from the beginning. We could maintain firmware for legacy devices, fixing security bugs even for 15 years old products. But we can’t stop the world: for example, security protocols will be replaced and we cannot influence that. If a security protocol (TLS 1.0) is deprecated secure communications won’t be permitted anymore unless we upgrade both devices and API services. But legacy devices probably won’t support larger firmware.

If you wonder how many SSL 3.0 enabled webservers are currently running on the Internet:

In the industrial sector, we know that we are facing unsupported systems and applications, and we can secure them by working on the perimeter. With consumer IoT and building automation, the story is different…

The revenues and the Ponzi method

Let’s focus again on consumer IoT devices. My friend made an interesting assumption:

It’s like a Ponzi scheme, in which the last users are paying for the whole infrastructure.

The consumer IoT business model is usually based on product selling. Nobody is willing to monthly pay for (example) remote air cooling management. But air cooling systems are expected to work for 10 years. So latter users, buying products, are paying the whole infrastructure.

Yes, the vendors are also acquiring data (telemetry) but I’m not sure the value of that data is paying for the whole infrastructure (servers, development, licenses, software, security assessments, audit, and compliance…).

A possible solution?

We know that:

• No software can stand for 10 years. That’s an assumption, but feel free to bring your experience.
• At some point infrastructure and development will require major antieconomic upgrades.
• Collected data (telemetry) are interesting but are not paying for the whole infrastructure.
• Infrastructure costs and the Ponzi scheme is not working.
• We are facing the same issue on ICS/OT.

And my solution involves a similar approach I’m using in ICS/OT: protect the perimeter. Right now there is no reason why some consumer devices need to be cloud-connected. Let’s open and document the API so home automation hubs can include and manage them. Hubs will be responsible to protect the home perimeter, without needing the cloud.

Yes, this is not covering all device types, but at least home devices can be managed and maintained without invasive cloud services.

Conclusions

Right now I’m 100% sure that any cloud-based IoT device can die in a few years. And also I’m worried about my data: I prefer to limit my home security perimeter avoiding cloud services. Moreover, I suspect that we are data-addicted: do we need to see our energy consumption anywhere and anytime?