Deep Dive: CRA Requirement (h) – Resilience and Availability

Requirement (h) of the Cyber Resilience Act introduces the obligation to protect the availability and ensure resilience against Distributed Denial-of-Service (DDoS) attacks:

“Protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks.”

This requirement addresses the third pillar of the CIA security triad: availability. Products must remain functional and provide their core services even when incidents occur.

The scope of availability can include recovery after disruptions, resilience to attacks such as denial-of-service, and the ability to keep essential functions running under degraded conditions. The CRA makes clear that outages are not just operational issues anymore, they are potential compliance issues.

What This Requirement Means

Imagine a hospital ventilator. Its job is to keep a patient breathing. Even if the data it processes is secure and unaltered, the device is useless if it shuts down during a power fluctuation or fails under high load. The risks are varied: a fan motor could overheat, the software could crash, or the network connection could be overwhelmed. Some of these issues are technical, others physical, but all could stop the ventilator from fulfilling its essential function.

This illustrates what the CRA expects manufacturers to address under Requirement (h). Availability is not just about the software stack, it is about analysing the product as a whole and asking what could cause it to stop providing its core services. The CRA risk assessment should cover every relevant function of the device, not only code and communication but also hardware and operating conditions. The outcome defines which resilience measures are necessary and how the system should respond to keep essential functionality running.

To meet this requirement, products must be designed to withstand incidents, degrade gracefully under stress, and recover quickly after disruption. Outages are not just costly, they can also compromise safety and compliance. Practical measures include redundancy and failover to avoid single points of failure, resource management to resist overload, and protection against denial-of-service attacks. Devices should also be able to detect when they are under stress, switch to safe modes, and log incidents in a way that allows operators to react effectively.

In some cases, availability is a shared responsibility. A software component or cloud service may not represent the full end product but still plays a critical role in availability. Here, responsibility must be coordinated between the solution provider and the manufacturer of the final product. It is advisable for hardware or software component providers to engage with their customers to clarify expectations around resilience and availability. While not mandated by the CRA, this dialogue helps align responsibilities and can position a product more clearly in the market.

Relevant Standards and Guidelines

While harmonised CRA standards are under development, several existing frameworks already provide guidance for resilience and availability:

• ISO/IEC 27001 and 27002 (general IT): Include controls for availability, business continuity, and resilience.

• EN IEC 62443-3-3 (industrial systems): Specifies security requirements for systems, including availability, redundancy, and recovery.

• EN IEC 62443-4-2 (industrial components): Specifies component-level resilience measures and availability protections.

• ETSI EN 303 645 (consumer IoT): Requires resilience to DoS attacks and continuity of critical services.

• ISO/IEC 22301 (business continuity): Focuses on resilience planning and recovery after incidents.

Gaps remain, most standards emphasise organisational continuity planning or high-level availability principles. They provide less detail on how embedded or resource-constrained IoT devices should ensure resilience under DoS conditions. Similarly, there is limited guidance on how to balance availability and safety in OT systems (where failing safe may conflict with staying online). CRA requirement (h) highlights the need for harmonised standards that define practical resilience mechanisms for IoT and OT environments.

How to Approach Implementation

Start by identifying which functions of your product are essential and basic. Then, design them so they remain operational under stress or can recover quickly after incidents.

Key capabilities to consider include:

• Resource and load management to prevent DoS from exhausting capacity

• Detection and throttling of abnormal traffic patterns

• Redundancy and failover mechanisms for critical components

• Graceful degradation to keep core functions running even if secondary features fail

• Logging, monitoring, and alerting to detect and respond to availability incidents

• Recovery procedures to restore normal operation after disruption

In industrial IoT and OT systems, availability is often the most critical property. Safety controllers, process automation, and energy systems must continue operating even under attack. This may require network segmentation to isolate critical assets, redundant communication paths, and gateways that can absorb or filter DoS traffic before it reaches other components. Balancing availability with safety is essential: systems must fail safe, but they must not fail silently.

For embedded IoT devices, constraints make resilience harder to achieve. Many devices have limited processing power and cannot absorb large volumes of traffic. Lightweight DoS protections, rate limiting, and use of hardware watchdogs are necessary. Secure boot and recovery partitions ensure that devices can restart into a functional state after disruption.

Compliance and Strategic Considerations

From a compliance perspective, Annex VII requires manufacturers to document how availability is ensured, which functions are classified as essential or basic, and what resilience measures are implemented. Annex II requires that the user guide explains relevant configuration options and how changing them may affect resilience and availability.

When evaluating in-house versus vendor solutions, consider complexity and dependencies. Building resilience internally offers control but requires deep expertise in error tolerance, redundancy, and DoS mitigation. Vendor solutions may accelerate deployment but must be carefully evaluated for CRA alignment and support for IoT/OT specifics.

Strategically, requirement (h) signals a shift: downtime is no longer only a business or operational issue, it is a regulated compliance matter. How complex this requirement is to implement depends heavily on the functions a product serves. In some cases, protections can be added with relatively simple measures, such as deploying tools to filter or mitigate denial-of-service attacks. In other cases, resilience has to be built deeply into the product itself, for example, through embedded failover mechanisms or safe-mode operations. This is why it is advisable to start the risk assessment as early as possible. Gaining clarity sooner rather than later helps avoid costly re-engineering if resilience is treated as an afterthought.

In our next post, we will explore Requirement (i): No harm to connected systems, which defines how products must be designed to minimise the negative impact on connected systems.

Previous Blog CRA Requirement (g): https://www.tributech.io/blog/cra-requirement-g-data-minimisationNext Blog CRA Requirement (i):https://www.tributech.io/blog/cra-requirement-i-no-harm-to-connected-systems