Manufacturing an IoT device has traditionally been treated as a hardware project: electronics, enclosure, power supply, EMC, firmware, production testing, documentation and then sales.

A connected product, however, does not stay the same after it has been delivered. New vulnerabilities emerge in the manufacturer’s own code, in the libraries it uses, in the operating system or in the communication components. The threat landscape can change while the product keeps running at the same site for years.

The European Union’s Cyber Resilience Act turns this lifecycle risk into a manufacturer’s obligation.

Where do things stand in September 2026?

The CRA, Regulation (EU) 2024/2847, entered into force on 10 December 2024.

The main product requirements apply from 11 December 2027. The reporting obligations, however, have already applied since 11 September 2026. This means that preparation is not a distant project starting at the end of 2027.

The Regulation covers hardware and software products with digital elements, and every manufacturer has to determine the exact scope, product category and conformity assessment route for its own product.

An industrial IoT gateway, a meter capable of network communication, a smart controller or related software is quite likely to belong to a product landscape that needs a deliberate review because of the CRA.

Security by design is no longer a slogan

The Regulation sets mandatory cybersecurity requirements for design, development, production and maintenance. Security therefore cannot be “bolted on” to a finished product with a penetration test at the end of the project.

Decisions are needed as early as the architecture stage, including:

  • which services are available by default;
  • how each device is uniquely identified;
  • whether there are factory-default, shared or easily guessable credentials;
  • how data is protected in transit and at rest;
  • how access can be restricted;
  • how security events can be logged;
  • what happens in the case of faulty or manipulated input;
  • how a secure state can be restored.

The principle of minimal attack surface means that anything not required for the product to function should not be available by default.

Updatability is a product feature

It is not enough to design a connected device so that it appears secure on the day it is sold. It must also be securely updatable.

This may require:

  • digitally signed, integrity-checked firmware;
  • a secure update channel;
  • version and compatibility management;
  • recovery after a failed update;
  • large-scale yet controlled device management;
  • an update log and installation status;
  • clear communication of the support period.

OTA updates do not in themselves provide security. Without signature verification, access control, rollback or proof of installation, the update mechanism itself can become an attack surface.

Vulnerability handling throughout the support period

One of the key changes introduced by the CRA is that it treats product security as a process. Manufacturers must be able to receive, assess, remediate and communicate vulnerabilities.

This requires a working internal procedure as well:

  • who receives security reports;
  • how severity and impact are assessed;
  • which product versions are affected;
  • which component causes the problem;
  • how the fix is developed and tested;
  • how it reaches customers;
  • how closure can be documented.

An email address on its own is not a vulnerability handling process.

You need to know what is in the firmware

Modern firmware and software are rarely built entirely from in-house code. Open-source libraries, operating system components, network stacks and vendor SDKs are layered on top of one another.

If any of these becomes vulnerable, the manufacturer must know which products and versions are affected. This requires an orderly register of dependencies and components. A software bill of materials (SBOM) can be an important tool here.

An SBOM, however, is only an inventory. It adds value when it is linked to version control, vulnerability information, the affected installed base and the update process.

Reporting obligations require detection capability

From 11 September 2026, manufacturers are subject to reporting obligations for certain actively exploited vulnerabilities and severe security incidents. Manufacturers must follow the detailed procedure and current guidance from the authorities according to their own role and product.

From a practical point of view, however, one thing is certain: an organisation cannot report on time what it is unable to detect, escalate internally and link to product versions.

The prerequisites for the reporting process are therefore:

  • a product and version register;
  • a security point of contact;
  • incident classification;
  • rules for decisions and approvals;
  • customer communication;
  • a verifiable event log.

Development evidence will stand behind the CE marking

Under the CRA, the CE marking of compliant products will also indicate that they meet the cybersecurity requirements. Depending on the product’s risk classification, different conformity assessment procedures may be needed, involving a notified body for certain categories.

This calls for a documented development process. The risk assessment, architectural decisions, test results, component information, vulnerability handling and release evidence must all be retained.

It is very difficult to credibly reconstruct, after the fact, why a security decision was made years earlier. Documentation must therefore be built alongside development.

What does this mean for an OrigSmart-type development?

Given OrigSmart’s hardware, gateway and platform capabilities, security cannot stop at the device enclosure. The entire system lifecycle has to be managed as a whole:

  • custom hardware and firmware;
  • field communication;
  • device identity and configuration;
  • secure updates;
  • platform-side access rights;
  • event logging and monitoring;
  • incident and vulnerability handling;
  • operating processes on the customer side.

Covering the full value chain is both a responsibility and a competitive advantage. A manufacturer and integrator that links hardware, software, operations and verifiable security processes from the product design stage onwards will not be scrambling to produce compliance documents at the end of 2027.

The essence of the CRA is not to put more paperwork next to the IoT device. It is to ensure that the digital product remains a manageable cybersecurity risk throughout its entire supported lifecycle.

Let’s discuss your project

Sources

Note: this article is general professional information and does not constitute legal or compliance advice.