Deep Dive: CRA Requirement (i) – No Harm to Connected Systems

Requirement (i) of the Cyber Resilience Act addresses how products and connected devices must interact with their surrounding environment.

“minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks”

This requirement is closely related to Requirement (h), which obliges manufacturers to ensure their own products remain available even under attack or after an incident. The difference is that a requirement (i) shifts the focus outward: it is about ensuring your product does not compromise the availability of other devices or the wider network. In other words, Requirement (h) protects the availability of your own product, while Requirement (i) ensures your product does not become a threat to the availability of others.

This distinction is critical. A device that continues to function during an incident (Requirement h) may still generate traffic storms, misbehave when compromised, or otherwise degrade shared resources. The CRA makes it clear that products must be designed to minimise such collateral damage.

What This Requirement Means

Imagine a smart doorbell connected to a home network. On its own, it seems harmless – if it fails, nobody would consider this a critical issue. But if that doorbell is hijacked and used to overload the same network where a household battery storage system or an electric vehicle charging station is connected, the impact is no longer trivial. The uncritical device becomes the entry point that undermines the availability of critical energy infrastructure.

This is why attackers often target IoT devices. They may not be valuable individually, but when thousands or even millions of similar devices are compromised, they can be coordinated into large-scale attacks. This is what is known as a distributed denial-of-service (DDoS) attack: a flood of malicious traffic generated by a fleet of hijacked devices, overwhelming services or networks until they can no longer respond.

Requirement (i) is about ensuring that connected products do not become part of such problems. Products must be designed so that they do not overload networks, interfere with other devices, or create excessive dependencies. If they fail, they should fail in ways that are contained rather than disruptive. This applies to communication behaviour, resource consumption, and interactions with external services.

Relevant Standards and Guidelines

While harmonised CRA standards are still to come, several existing frameworks touch on the principles behind Requirement (i):

• ETSI EN 303 645 (consumer IoT): Requires mechanisms to prevent devices from being used in large-scale attacks, including rate limiting and network hygiene.

• EN IEC 62443-4-2 (industrial components): Includes controls for communication integrity and limiting the impact of compromised devices in industrial systems.

• ISO/IEC 27001 and 27002 (general IT): Provide high-level controls for protecting the availability of systems and networks from misuse.

• NIST SP 800-53 (general IT): Covers resource consumption controls and denial-of-service protections.

Current standards provide guidance on individual controls, such as rate limiting or intrusion detection, but offer limited direction on how to design IoT and OT products that minimise their collective impact when deployed in large numbers. There is also little support for constrained devices, which often lack the capacity for advanced traffic management yet can still generate disruptive loads.

How to Approach Implementation

Manufacturers should start by asking: If my product misbehaves, what effect could it have on the network or other devices? Addressing this question early helps prevent designs that inadvertently spread problems outward.

Key capabilities to consider include:

• Rate limiting and traffic shaping to prevent overload or flooding

• Resource usage controls to avoid consuming excessive bandwidth or processing capacity

• Secure update and patching to reduce the risk of compromise and misuse in attacks

• Fail-safe behaviour that contains faults locally rather than cascading across systems

• Logging and reporting mechanisms to detect unusual communication or excessive resource use

In industrial IoT and OT systems, this requirement is particularly relevant for gateways and controllers that sit at the edge of networks. If compromised or misconfigured, they can propagate errors or generate disruptive traffic that affects entire production lines. Isolating critical components, applying segmentation, and designing clear traffic rules help minimise such risks.

For embedded IoT devices, the challenge is that even small devices can create large problems when deployed at scale. A fleet of sensors that each generates excessive traffic can easily overwhelm gateways or backend systems. Lightweight rate limiting and strict communication policies are necessary, even for minimal devices.

The critical consideration is that compliance with the requirement (i) is not just about protecting the product itself but about protecting the ecosystem around it. Minimisation of impact should therefore be part of the design phase, not an afterthought.

Compliance and Strategic Considerations

From a compliance perspective, Annex VII requires that the technical documentation explains how the product’s behaviour is controlled to prevent negative impact on networks or other devices. Annex II requires that the user guide describes relevant configuration options and how changes could influence communication patterns or resource usage.

When it comes to network-level protections, the safest and most effective choice is to rely on established tools and services. Mature solutions already exist for filtering, traffic shaping, and denial-of-service mitigation. Re-implementing such capabilities in-house is rarely cost-effective and often results in weaker protection than what is available off the shelf.

In contrast, the IoT and OT stack is more product-specific. Here, vendors need to be evaluated carefully, because their platforms cannot cover every scenario or anticipate the unique behaviours of each device. Complementary measures may need to be added directly into the product’s own logic, for example, to contain faults locally or to enforce communication rules that are specific to a given use case. When selecting an IoT or OT platform, it is therefore critical to analyse what is included, where the gaps are, and what must be implemented by the manufacturer. Assuming a vendor can provide complete coverage will almost always leave important responsibilities unaddressed.

Requirement (i) reflects a broader shift: regulators expect every connected product to play a role in protecting the stability of digital infrastructure. Companies that demonstrate proactive design choices — limiting unnecessary traffic, preventing misuse, and containing failures — will not only reduce compliance risks but also strengthen their reputation as responsible players in the IoT and OT ecosystem.

In our next post, we will explore Requirement (j): Limited attack surface, which defines how products must be secured by reducing the attack surface.

Previous Blog CRA Requirement (h): https://www.tributech.io/blog/cra-requirement-h-resilience-and-availabilityNext Blog CRA Requirement (j):https://www.tributech.io/blog/cra-requirement-j-limiting-attack-surfaces