CRA Availability and Resilience Requirements Guide

The Cyber Resilience Act (CRA) makes availability and resilience part of product cybersecurity, but it does not impose a universal uptime percentage or a generic service-level agreement. Annex I Part I instead requires manufacturers, on the basis of the cybersecurity risk assessment and where applicable, to protect the availability of a product's essential and basic functions, including after an incident, and to use resilience and mitigation measures against denial-of-service attacks.

A second requirement matters just as much for connected products: the product should minimise its own negative impact, or that of connected devices, on the availability of services provided by other devices or networks. For engineering teams, this turns availability into a product-security design, testing and evidence problem rather than a single operational metric.

The CRA's main obligations apply from 11 December 2027. The useful preparation work now is to identify the functions whose availability matters, understand what can exhaust or disable them, build proportionate resilience controls, and retain evidence showing how the released product behaves under stress and failure.

Start with the exact Annex I requirements

Annex I Part I point 2(h) requires products with digital elements, where applicable and based on the cybersecurity risk assessment, to protect the availability of essential and basic functions, also after an incident. The Regulation explicitly mentions resilience and mitigation measures against denial-of-service attacks.

Point 2(i) then requires products to minimise the negative impact caused by the products themselves or connected devices on the availability of services provided by other devices or networks.

These are related but different objectives:

2(h) is about preserving the product's own essential and basic functions;
2(i) is about preventing the product or its connected environment from becoming a source of availability harm to other systems.

Treating both requirements as one generic "high availability" statement makes the engineering scope too vague. A useful implementation separates the product functions that need protection from the external services and networks that the product could affect.

Define essential and basic functions for the actual product

The legal text does not provide a universal list of essential or basic functions for every product category. Teams need to derive the relevant scope from the product's intended purpose, architecture and cybersecurity risk assessment.

Start with a function inventory. For each function, ask:

what user or system outcome depends on it;
whether loss of the function creates a cybersecurity consequence;
whether the function is necessary to recover or maintain secure operation;
which local and remote components it depends on;
whether a degraded mode is possible;
what state must remain available after an incident; and
how the product indicates loss, degradation or recovery.

For one product, authentication or secure update may be an essential function. For another, local control, safety-adjacent monitoring, configuration recovery or access to security logs may be more important. The important point is not the label but the documented risk-based reasoning.

Avoid declaring every feature essential. If everything is critical, the classification stops helping engineering teams prioritise resilience and test effort.

Map the availability dependency chain

Availability failures frequently originate outside the function that users see. A product function can depend on storage, memory, CPU, network connectivity, DNS, identity services, remote APIs, databases, message queues, certificates, clocks, update infrastructure or another device.

Create a dependency map for each relevant function and record at least:

required local processes and services;
required persistent state;
external service and network dependencies;
resource constraints and expected operating ranges;
timeouts, retries and fallback paths;
single points of failure;
recovery dependencies; and
assumptions about connected devices.

This map helps distinguish ordinary reliability problems from cybersecurity-relevant availability risks. It also makes denial-of-service analysis concrete: teams can identify where an attacker or malformed peer could consume a constrained resource, trigger expensive work, block a queue or keep a dependency permanently busy.

Model denial-of-service as resource exhaustion and control-flow abuse

Denial of service is broader than volumetric network flooding. For products with digital elements, availability can be lost through any attacker-controlled path that exhausts a finite resource or prevents useful work from progressing.

Depending on the architecture, relevant cases can include:

connection or session exhaustion;
CPU-intensive requests or parsing paths;
memory exhaustion;
unbounded queues or event backlogs;
file, database or log-storage exhaustion;
repeated authentication or cryptographic work;
retry storms against unavailable dependencies;
lock contention or deadlock triggered by malformed sequences;
excessive device discovery or broadcast traffic;
repeated restart or crash loops; and
dependency calls with missing or ineffective timeouts.

Threat modelling should identify which externally influenced operations are expensive, which resources are finite, and what happens when demand exceeds the expected range.

Use proportionate resilience controls

The CRA states the objective; it does not prescribe one architecture. Controls should follow from the cybersecurity risk assessment and product context.

Typical engineering measures can include:

bounded queues and memory use;
rate limiting or request shaping;
quotas per client, identity or function;
timeouts and circuit breakers for remote dependencies;
backpressure rather than unlimited buffering;
prioritisation of essential work over optional work;
isolation between high-risk interfaces and core functions;
watchdog or supervised restart mechanisms where appropriate;
graceful degradation with explicit recovery behaviour;
retry limits with jitter and exponential backoff;
protection against log or storage exhaustion;
redundant components where justified by risk; and
safe local operation when remote services are unavailable, where the product architecture supports it.

ENISA's Secure by Design and Default Playbook connects defence in depth with Annex I point 2(h), emphasising multiple layers of protection rather than dependence on one control. The same playbook also links attack-surface limitation, logging and monitoring, and configuration management to broader CRA security objectives. These practices are useful ways to structure resilience engineering, but the Regulation and the product-specific risk assessment remain the basis for the legal requirement.

Design graceful degradation deliberately

Resilience does not always mean maintaining full functionality. In many architectures, the safer response to overload or dependency failure is a controlled degraded mode that preserves the most important functions while temporarily limiting optional work.

Define degradation behaviour before implementation. Document:

which functions continue;
which functions are suspended;
what users are told;
whether security controls remain active;
what data can still be written safely;
how queued work is handled;
how the system decides that normal operation can resume; and
whether manual intervention is required.

A degraded mode that disables authentication, stops security logging, silently accepts stale authorisation state or creates uncontrolled retry traffic can solve one availability problem while creating another security problem.

Protect other devices and networks from the product itself

Annex I point 2(i) shifts attention from the product's own uptime to the wider environment. A product should not become the mechanism that reduces availability elsewhere.

Connected products can cause external availability problems through aggressive retries, uncontrolled scanning, broadcast or multicast floods, excessive telemetry, repeated failed authentication, malformed protocol behaviour, or a compromised component that generates disproportionate traffic.

Product teams should test failure behaviour, not only normal behaviour. When a cloud endpoint becomes unavailable, a thousand deployed devices should not all reconnect as fast as possible. When a peer stops responding, queues should not grow without bound. When an update service fails, clients should not generate a synchronised request storm.

Useful evidence includes retry policies, rate controls, network-load tests, dependency-failure tests and architecture decisions explaining how the product limits its effect on shared services.

Test incident survival, not only peak performance

A conventional performance test can show throughput under expected load, but Annex I point 2(h) also refers to availability after an incident. The test strategy should therefore include recovery and degraded-state behaviour.

A practical resilience test matrix can cover:

sustained high request or event volume;
short bursts above the expected operating range;
exhaustion of one constrained resource;
loss or slowdown of a remote dependency;
loss of network connectivity;
malformed or adversarial request patterns;
process crash or forced restart;
partial storage failure or full storage;
queue saturation;
dependency recovery after an extended outage; and
restoration of normal service after the incident condition ends.

For each test, record the expected essential functions, expected degraded behaviour, resource limits, recovery condition and pass criteria. The result should show what the product actually did, not merely that the test tool completed.

Define evidence around released product state

Availability and resilience evidence becomes weak when it cannot be tied to the exact product version that was assessed.

For each relevant release, retain enough context to answer:

which essential and basic functions were identified;
which risk-assessment findings drove resilience controls;
which architecture and dependency assumptions applied;
which denial-of-service scenarios were tested;
which resource limits and configurations were used;
which test build, firmware or software version was exercised;
what failed or degraded during the test;
how recovery was verified; and
which known limitations or residual risks were accepted.

This does not require keeping unnecessary raw data forever. It requires durable traceability between the requirement, the tested product state, the result and the decision made from that result.

Do not invent an uptime target that the CRA does not state

A common implementation mistake is to convert the CRA availability requirement into an arbitrary uptime percentage. The Regulation does not state that every product must achieve a particular number of nines, request latency, recovery-time objective or failover architecture.

Internal service objectives can still be useful engineering controls, but they should be justified by the product's intended purpose, risk assessment and architecture rather than presented as CRA-prescribed thresholds.

The same applies to redundancy. A high-risk product may justify redundant components or services, while another product may meet its resilience objective through bounded resource use, local fallback, fast recovery and controlled degradation. The evidence should explain why the chosen measures are appropriate for the identified risk.

Keep resilience current as the product changes

Availability assumptions can change without an obvious security-feature change. A new cloud dependency, telemetry client, database, protocol handler, authentication flow or background task can add resource contention and new failure modes.

Include availability and resilience in change review. Ask whether the change:

adds a new dependency to an essential function;
changes resource consumption or concurrency;
introduces new externally reachable work;
changes retry or timeout behaviour;
alters degraded-mode behaviour;
affects startup or recovery sequencing; or
changes the product's impact on connected services or networks.

Where the answer is yes, update the relevant tests and risk reasoning rather than assuming an earlier resilience result still applies.

Keep resilience evidence connected to lifecycle decisions

Resilience work often spans threat models, architecture records, performance tests, incident tests, release approvals and operational findings. If those records are stored independently, it becomes difficult to show which evidence supported a particular product or release decision.

AA-sec is designed around traceability between requirements, security evidence, decisions and exact product or lifecycle context. That model can help teams organise availability and resilience evidence alongside broader CRA-readiness work while existing engineering, CI/CD and testing systems continue to own implementation and execution.

Key takeaway

CRA availability requirements are risk-based product-security requirements, not a generic uptime SLA. Annex I Part I point 2(h) focuses on protecting essential and basic functions, including after an incident and against denial-of-service attacks, while point 2(i) requires products to limit their negative impact on the availability of services used by other devices or networks.

Define the functions that matter, map their dependencies and finite resources, design proportionate resilience and degradation controls, test overload and recovery behaviour, and keep the resulting evidence tied to the exact released product state. That creates a defensible engineering record without inventing thresholds that the Regulation does not prescribe.

Official sources

Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
ENISA Secure by Design and Default Playbook — ENISA
BSI TR-03183: Cyber Resilience Requirements for Manufacturers and Products — Federal Office for Information Security (BSI)
The Cyber Resilience Act — Summary of the legislative text — European Commission