How Long Should a Connected Product Be Supported?

Until recently, how long a connected product received security updates was a question nobody had to answer in public. That has changed in three jurisdictions at once: the UK's PSTI regime, the EU Cyber Resilience Act and the US Cyber Trust Mark criteria all expect a manufacturer to state a support period. Publishing a number is easy. Choosing one you can honour is the actual problem.

The temptation is to publish something short and safe. The trouble is that the number is also a sales document. A buyer comparing two thermostats will read two years against ten as a statement about which company expects to still exist, and in commercial and building products the procurement team will simply exclude the short one. So the number is bounded below by what the market accepts and above by what engineering can survive.

What it commits you to is more than patching your own code. A support period is a promise about the whole dependency tree: the RTOS, the TLS library, the Wi-Fi stack from the module vendor, the bootloader. If your silicon vendor stops issuing updates for its SDK in year four of a ten-year promise, you have inherited maintenance of a stack you did not write and may not be able to build. This is worth asking every vendor before selecting a part, in writing, because the answer rarely appears on a datasheet.

It is also a promise about being able to ship. A device that cannot be updated in year eight because the signing key was lost, the build environment no longer exists, or the toolchain will not run on any supported operating system is unsupported in practice regardless of what the label says. Keeping a build reproducible for a decade is an infrastructure commitment that has to be funded, and it is the part that quietly fails first.

A reasonable way to arrive at the number is to work backwards from the hardware. Estimate how long the product will physically remain installed, since that is how long it will remain attackable. Check the longest support commitment you can get in writing from your silicon and module vendors, because you cannot credibly promise past it. Then ask what your team can afford to maintain concurrently, remembering that in year five you will be supporting this product, its successor, and the one after that at the same time.

The honest answer is usually shorter than marketing wants and longer than engineering wants, and it should be written down with the reasoning attached. When the question returns in four years — and it will, from a customer, a regulator, or an auditor — the reasoning is what makes the number defensible rather than arbitrary.