This is the blog post #8 in our human written series on the Cyber Resilience Act (CRA) essential requirements. Here we look at Part I requirements 2(h) and 2(i). They read “protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks” and “minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks”.
These requirements stand out: they are not directly about securing the digital product, but they acknowledge that products are part of a larger whole, and the integrity of the whole must be maintained. One of the key drivers of the CRA is protecting society and people from damage caused by cyber attacks. Core utilities, such as water, electricity and the Internet, run on millions of embedded digital products which control and monitor them. We have smart electronics and applications at home, and we would struggle without them. That is why the CRA expects manufacturers of digital products to make them resilient and well-behaved, even when facing cyber attacks.
Be available when needed
Requirement I.2(h) is about protecting the functionality of the product. The motivation is self-evident: we would like the product to keep doing whatever we acquired it to do. This may be a critical function, such as a smart lock or a surveillance camera, or a less critical one, let's say a toy or decorative lighting. The CRA does not directly define what is meant by essential and basic functions, but it expects you to define the intended purpose of the product, foresee its expected use, and describe its “essential functionalities” in the end-user documentation.
In practice, requirement I.2(h) means that a product should try to keep functioning even when, for example, it cannot reach its backend servers or it is under high load due to a denial-of-service attack. This may simply mean allowing manual use (toggling it on and off) or having a safe, limited operating mode when connectivity is down. The level of availability, and the technical means to achieve it, depend on the nature of the product.
“Defence in depth” is a cybersecurity principle where an attack is blocked or delayed even after the attacker has breached the outer protection layer. For example, even when an attacker can run code on a device due to a command injection vulnerability, internal partitioning prevents the attacker from completely “owning” the device.
Human users may not be the only ones your product serves. If your product has an API (or, these days, an MCP server), it can be a dependency for other systems. If a cyber attack makes your product unavailable or causes it to misbehave, those systems are affected, even when they are not part of the product.
The next step: be a good citizen
While the availability requirement is bread and butter in most security standards and regulations, requirement I.2(i) extends the scope to the surrounding networks and services. Here it shows that the CRA is an EU-wide regulation: it is concerned with the whole of society and its people, not just those who have purchased a particular product.
The core of the requirement is that a digital product should not enable cyber attacks on other systems. This could include being part of a botnet used to cause denial-of-service attacks, or acting as a beachhead for cyber attacks, where an attacker first compromises the product and then uses it for lateral movement within the local network. Thus, the CRA expects you to protect not only the users and systems depending on the product, but all users and systems reachable through it. This thinking has a lot of merit:
Even a product seen as “low value” can be an attractive target for attackers if it is in the same network as “high value” targets.
Even without APIs, a compromised and misbehaving product can disturb other systems by flooding them with malicious traffic or by trying to compromise their network services.
Users may share passwords between systems, so a breach in one system that exposes access credentials may allow attackers to compromise other, unrelated systems.
Large deployments of a digital product may cause disruption even without malicious intent, simply by generating a large volume of network traffic at the same time, e.g. for updates or when booting after a power outage.
Technically, this means that you cannot really skip hardening the product and implementing defence-in-depth protections by claiming that the product is “low value” or that it does not have APIs. If the product can be connected to a network, it can be the weakest link in that network.
Another aspect of good citizenship is being compatible with the security controls of the surrounding systems. Your customers may be regulated, e.g. by the NIS2 directive (2022/2555), and they must plan for supply chain security, attack detection, response and recovery. You should support this, not only to meet regulation but also to keep selling to these customers. For example, backup and restore should be supported, the network addresses and ports used should allow tight firewall rules, audit logs should be produced so that they can be stored in a SIEM (Security Information and Event Management) system, and so on.
Be better: how to avoid bad behaviour
So, what kind of behaviour should we try to avoid? You may easily think: “if the product is compromised, then the attacker owns it, so there is nothing we can do”. However, there are things you can do to meet requirements I.2(i) and I.2(h).
First, and obviously, all design choices and security controls put in place to protect the device itself make it harder for the attacker to succeed. Timely security updates, deployed automatically and securely, allow you to respond to emerging security threats. As always, do the basic things properly.
Even without a compromise, some network services may provide tools for an attacker. Open UDP services may amplify a small spoofed request into a large response directed at victims. Such services should only be in place when they are truly needed, as required by essential requirement I.2(j). Further, filtering and rate limiting should be in place for services which may be reachable by an attacker.
The principle of defence in depth should be applied. For example, network services should not run as root but as limited users, so that compromising a service does not give unlimited access to the device. Operating systems, compilers, container environments, etc. typically come with security features; you should familiarise yourself with them and use them to harden your system. A watchdog can observe the system state and restore it if it becomes unresponsive. Being able to reset to a known good state, as well as backup and restore, helps to recover from an incident. In more critical applications, such as industrial control systems, it may be best to isolate the network-facing part from the actual control system. The control system should keep providing the critical function even if the network-facing parts crash or are jammed.
We all want our products to sell in large numbers, but you should consider the security impact of your success. As said, not all devices should make network connections at the same time, to avoid overloading networks (and perhaps your own servers).
Finally, all the security functions should be tested. This may be somewhat challenging, as they should only trigger on special occasions, not during normal operation. Luckily, the security features of the platforms you use should already have been tested by their respective vendors. Testing a defence feature may require “attacking”, which requires some expertise, and your AI assistant may well refuse to help due to its security guardrails. You should reserve time and resources for security testing, perhaps getting external help as required.
Conflicting goals
Often there is a conflict or tension between the security and availability requirements of a product. Let's consider a smart lock: if it cannot validate access rights, e.g. due to a network outage, it should not open the door. However, this means that in an emergency, when networks are down, doors remain locked and people cannot leave or enter the house, which is a safety problem. A solution may be to always allow opening the door from the inside, and/or to resolve access locally based on cached data when the remote connection is not available.
Another example is locking an account after too many failed login attempts. It may thwart password-guessing attacks, but it also makes it easy to deny access to legitimate users, possibly leading to service unavailability. Rate-limiting logins may be better, although legitimate users may still be denied access while a brute-force attack is ongoing. Security updates may also cause downtime, and in some contexts, such as industrial control systems, they are best initiated manually during maintenance breaks.
When there is a conflict between security, availability and safety, the balance must be made based on the intended purpose, reasonably foreseeable use and misuse, and the risk assessment of the product, considering possible safety and other regulations.
Conclusions
As with all CRA product requirements, the security measures should be in proportion to the estimated risk: a decorative light and a smart lock have different risk profiles. However, for requirements I.2(h) and I.2(i), this is challenging, as the impact of a security breach may go beyond your device or its users.
In the end, meeting the requirements I.2(h) and I.2(i) is about properly implementing the basic security principles already demanded by the other essential requirements of the CRA. On top of those, you should consider the criticality of the service your product provides, how to ensure its continuity in case of cyber attacks, and the protection of society and the people around it.
