The End of Ship and Forget:
EU Cyber Resilience Act and IoT

By: Josh Cox

For most of the history of connected devices, the important date was the ship date. You designed to a cost, you hit a launch window, and security was something you added if the schedule allowed. Once the product was in the field, it was largely someone else's problem. The customer's, the operator's, the integrator's. That model is now ending in the largest single market in the world, and the change runs deeper than the compliance headlines suggest.

The EU Cyber Resilience Act turns the entire life of a connected product into a commitment the manufacturer makes before it ever leaves the factory. The paperwork is the easy part.

The EU Cyber Resilience Act entered into force in December 2024. Its reporting obligations begin to apply in September 2026, and the full set of requirements takes effect in December 2027. It covers what the text calls products with digital elements, which in plain language means almost anything with software in it that gets sold into the European Union, from gateways and routers to sensors, meters, modules, and network equipment. If it connects and it computes, it is in scope.

The penalties are large enough to get a board's attention. The most serious violations can draw fines of up to fifteen million euros or two and a half percent of worldwide annual turnover, whichever is higher. The philosophy the regulation encodes matters more than the fines. It asks manufacturers to change the way they build products, not the way they file paperwork about them.

The Cyber Resilience Act moves the center of gravity from the point of sale to the entire supported life of the product.

Under the old model, a device was finished when it shipped. Under the new one, shipping is the beginning of an obligation. Manufacturers have to design for security from the start rather than add it at the end. They have to run a real risk assessment across the whole lifecycle of the product. They have to handle vulnerabilities as they are discovered, which means having a way to actually find them, fix them, and deliver the fix to devices already in the field. And they have to commit to a support period during which all of that continues. The regulation sets a floor of at least five years, or the expected use time of the product if that is shorter.

Five years does not sound like much until you consider how this hardware actually lives. A great deal of connected infrastructure is designed to sit in a wall, a basement, a utility cabinet, or a cell site for a decade or more. The support clock in the regulation is tied to how long a product is reasonably expected to be in use, and for a lot of communications and IoT equipment that expectation is long. The company whose name is on the declaration of conformity is now responsible for keeping that equipment secure for as long as the market reasonably expects it to run. That is a very different promise from the one most device programs were built to keep.

Keeping that promise is an engineering problem before it is a legal one. Consider what it actually takes to push a security fix to a device six years after it left the production line. You need to know exactly what went into that device, down to the third party libraries and components buried inside it, because a vulnerability in any one of them is now yours to answer for. You need a way to reach the device in the field, which means an update mechanism that was designed in from the beginning and still works on hardware you have not touched in years. You need the build environment, the signing keys, and the institutional memory to produce a trustworthy update long after the original team has moved on. None of that happens by accident. All of it has to be a design input on day one.

This is why the requirement to document what is inside a product matters more than it first appears. You cannot patch what you cannot see. A manufacturer without a clear, current inventory of the software and components in its own devices has no way to answer the basic question the regulation will ask, which is whether a newly disclosed vulnerability affects anything it has shipped. Building that inventory and keeping it accurate is unglamorous work. It is also the difference between a fast, confident response and a scramble.