{"id":70006,"date":"2026-09-02T13:12:00","date_gmt":"2026-09-02T11:12:00","guid":{"rendered":"https:\/\/www.usd.de\/?p=70006"},"modified":"2026-09-22T15:30:09","modified_gmt":"2026-09-22T13:30:09","slug":"cyber-resilience-act-iot-and-ot-products","status":"publish","type":"post","link":"https:\/\/www.usd.de\/en\/cyber-resilience-act-iot-and-ot-products\/","title":{"rendered":"Cyber Resilience Act: What Manufacturers of IoT and OT Products Need to Know Now"},"content":{"rendered":"\n

The Cyber Resilience Act (CRA)<\/a> makes cybersecurity a mandatory requirement for many products with digital components for the first time. In the future, manufacturers must be able to demonstrate that security requirements were taken into account during development, operation, and vulnerability management. As a result, cybersecurity is no longer merely a matter of technical quality, but a central component of product conformity and market access in the EU.<\/p>\n\n\n\n

This particularly affects manufacturers of IoT solutions, embedded devices, industrial control systems, and OT components. Their products often consist of complex hardware and software environments, long supply chains, and multi-year operating cycles. It is precisely these factors that present companies with the challenge of ensuring security measures and providing evidence of compliance throughout the entire product lifecycle.<\/p>\n\n\n\n

In this article, we examine the CRA<\/a> requirements for IoT and OT products, the vulnerabilities and process gaps organizations should be addressing today, and how a CRA-focused assessment can help highlight areas requiring action at an early stage.<\/p>\n\n\n\n

<\/div>\n\n\n\n

What Is the Cyber Resilience Act?<\/h2>\n\n\n\n

The CRA is an EU regulation for \u201cproducts with digital elements.\u201d This includes hardware and software products that can be connected, directly or indirectly, to other devices or networks. The scope of the regulation is intentionally broad: it ranges from consumer IoT and smart home devices to apps and software components, as well as industrial control systems, gateways, and embedded firmware<\/a>.<\/p>\n\n\n\n

However, the CRA is not aimed solely at the manufacturers of these products. Importers and distributors are also held accountable when they make products available on the European market. For manufacturers, however, the focus is particularly clear: whether a product can be developed, delivered, and operated safely throughout its expected service life.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Why Are IoT and OT Products Particularly Affected by the CRA?<\/h2>\n\n\n\n

IoT and OT products are rarely simple, standalone products. They often consist of hardware, firmware, backend systems, mobile applications, and cloud services. Added to this are long lifecycles and complex supply chains. It is precisely this combination that makes them challenging from a CRA perspective. A vulnerability is not always limited to the device itself. It can also lie in a library being used, an insecure update function, a poorly secured interface, or a lack of processes for handling reported vulnerabilities.<\/p>\n\n\n\n

For companies, this means it is not enough to have a product technically tested shortly before release. The CRA requires a robust security assessment that spans architecture, development, operations, updates, and vulnerability management. Cybersecurity must therefore be considered from the very beginning and in such a way that manufacturers can later demonstrate what they have done.<\/p>\n\n\n\n

<\/div>\n\n\n\n

What Must Manufacturers Be Able to Demonstrate in the Future?<\/h2>\n\n\n\n

Rather than providing a simple checklist of controls, the CRA instead specifies the level of security that products must achieve. This includes taking security risks into account as early as the design and development phases. In practice, this might involve, for example, threat modeling during the architectural phase to systematically analyze attack surfaces and identify vulnerabilities early on.<\/p>\n\n\n\n

Another key point is updatability. Manufacturers must be able to reliably provide security updates and roll them out in a traceable manner. This is particularly crucial for devices that are already in operation: If updates are not verified or devices lack a viable patching strategy, the update infrastructure itself becomes a risk.<\/p>\n\n\n\n

Organizational processes are also becoming more important. Manufacturers need clear lines of responsibility for handling vulnerabilities, for example, through a Product Security Incident Response Team (PSIRT), as well as defined escalation procedures and a public contact channel for security reports. In addition, software components must be documented in a traceable manner, such as through a Software Bill of Materials (SBOM).<\/p>\n\n\n\n

The need for a PSIRT becomes particularly clear in light of the CRA\u2019s reporting requirements. The regulation requires that actively exploited security vulnerabilities be reported within 24 hours of discovery via the Single Reporting Platform of the European Union Agency for Cybersecurity (ENISA)<\/a>. For more information on the CRA\u2019s reporting obligations, see our blog post \u201cCRA Reporting Obligations from September 2026: Have You Considered Them?\u201d<\/a><\/p>\n\n\n\n

<\/div>\n\n\n\n

Where Do Products Fall Short?<\/h2>\n\n\n\n

Our security analyses<\/a> often reveal very quickly where the gap between regulatory requirements and the current state of a product is particularly wide. Many vulnerabilities arise not from a single error, but from the interplay of legacy technical issues and missing processes:<\/p>\n\n\n\n