CRA availability is broader than keeping a service online during normal operation. Manufacturers should identify essential and basic functions, assess how cybersecurity incidents and resource-exhaustion attacks could disrupt them, design appropriate resilience and recovery behaviour, and consider whether the product itself could impair other devices or networks. Evidence should show that availability controls have been verified under realistic failure and attack conditions.
Annex I Protects Essential and Basic Product Functions
Annex I Part I point 2(h) requires products with digital elements, on the basis of the cybersecurity risk assessment and where applicable, to protect the availability of essential and basic functions, including after an incident. The requirement makes availability part of product cybersecurity rather than only a reliability or service-level concern. Manufacturers should identify which functions matter for the intended purpose and which failures could create significant cybersecurity consequences. The required level of resilience depends on the product and risk. The CRA does not require every function to remain available under every conceivable condition, but the manufacturer should be able to explain how essential and basic functions are protected against relevant cybersecurity disruptions.
- Identify essential product functions.
- Identify basic functions needed for safe or secure operation.
- Assess cybersecurity causes of loss of availability.
- Define appropriate resilience objectives.
- Verify behaviour during and after incidents.
Availability Must Be Considered After a Security Incident
Point 2(h) expressly refers to availability after an incident. Product architecture should therefore consider degraded operation, restart, recovery and restoration rather than only preventing the initial disruption. A compromised component should not necessarily force every unrelated function to fail if the architecture can isolate the affected area. Where a product stores critical state, recovery design should consider whether that state remains trustworthy after compromise. Restart behaviour, dependency recovery and recovery credentials can also create security risks. Manufacturers should define what successful recovery means for the product and verify that the process returns the product to an appropriate security state rather than merely making it reachable again.
- Define post-incident operating states.
- Isolate failures where appropriate.
- Protect recovery mechanisms.
- Validate security-relevant state before restoration.
- Test recovery to a trustworthy configuration.
Denial-of-Service Mitigation Is Explicitly Included
Annex I point 2(h) specifically refers to resilience and mitigation measures against denial-of-service attacks. The appropriate controls depend on the architecture and threat model. Relevant techniques can include request throttling, connection limits, queue management, workload isolation, resource quotas, graceful degradation, caching, back-pressure, circuit breakers, redundant components or external mitigation services. The requirement should not be interpreted as a guarantee that no denial-of-service attack can succeed. The manufacturer should identify credible resource-exhaustion and service-disruption scenarios and use controls that are proportionate to the product's cybersecurity risks and intended environment.
- Identify resource-exhaustion paths.
- Assess unauthenticated and low-cost attack paths.
- Limit expensive operations where appropriate.
- Protect critical workloads from less important workloads.
- Test behaviour under abnormal demand.
Dependencies Can Determine Product Availability
A product may depend on cloud APIs, identity services, update infrastructure, DNS, certificate services, databases, message brokers, networks or connected hardware. A failure in one dependency can remove an essential product function even if the product's own process remains healthy. Manufacturers should map these dependencies and determine whether the product fails securely when they are unavailable. Depending on the risk, useful design choices can include caching, offline modes, redundancy, local fallback, retry limits or clear degraded states. Unbounded retries and reconnect loops can make an outage worse by increasing load on a failing dependency.
- Inventory availability-critical dependencies.
- Define dependency failure behaviour.
- Avoid uncontrolled retry storms.
- Provide secure fallback where appropriate.
- Document assumptions outside the product boundary.
Point 2(i) Protects the Availability of Other Services
Annex I Part I point 2(i) addresses a different availability problem. Products should minimise their negative impact, or the impact of connected devices, on the availability of services provided by other devices or networks. This matters where a compromised or malfunctioning product could generate excessive traffic, repeated requests, broadcast storms, resource exhaustion or other behaviour that impairs surrounding systems. The manufacturer should consider not only whether its own product remains available but whether its design can become a source of wider service disruption. Rate controls, bounded retry behaviour, protocol validation and safe failure modes can help reduce this risk where applicable.
- Assess whether the product can overload other services.
- Limit uncontrolled traffic generation.
- Bound retry and reconnection behaviour.
- Consider compromised connected-device behaviour.
- Test failure interactions with external systems.
Resilience Is Not the Same as General Reliability
Traditional reliability engineering and cybersecurity resilience overlap, but their threat assumptions differ. Reliability often considers accidental component failure, load and environmental conditions. CRA cybersecurity resilience also needs to consider deliberate adversarial behaviour. An attacker may intentionally create malformed requests, exhaust scarce resources, trigger expensive operations or repeatedly force recovery paths. Existing reliability controls can therefore support CRA evidence, but manufacturers should verify them against security abuse cases rather than assume that conventional uptime testing covers the requirement. The cybersecurity risk assessment should identify intentional availability threats alongside relevant accidental failure conditions.
- Reuse reliability engineering evidence where relevant.
- Add adversarial availability scenarios.
- Test malformed and abusive inputs.
- Consider attacker-controlled timing and repetition.
- Connect resilience results to cybersecurity risk.
Graceful Degradation Can Preserve Essential Functions
Some products cannot maintain every feature during an incident or severe resource shortage. Graceful degradation can provide a controlled way to preserve the most important functions while suspending lower-priority capabilities. The correct priority depends on the product's intended purpose and cybersecurity risks. Degraded modes should themselves be secure. A product should not disable authentication, integrity checking or other essential security controls simply to remain available unless the risk analysis clearly supports that behaviour. Teams should define the functions that remain available, the conditions that trigger degradation and the process for returning to normal operation.
- Prioritise essential and basic functions.
- Define secure degraded modes.
- Avoid removing critical protections solely for availability.
- Control transition back to normal operation.
- Test degraded-state behaviour.
Availability Controls Need Abuse-Oriented Verification
Availability evidence should go beyond ordinary functional testing. Depending on the product, useful verification can include load tests, connection exhaustion, request floods, malformed input, queue saturation, memory or storage pressure, dependency failure, repeated authentication attempts and recovery tests. The objective is to determine whether the product's controls behave as designed under cybersecurity-relevant pressure. Testing should identify the product version, configuration and environment because capacity-related results can change materially between deployments. Where external mitigation services are relied on, that dependency should be documented rather than treated as an invisible assumption.
- Test resource exhaustion.
- Test service and dependency failure.
- Test rate controls and quotas.
- Test recovery after disruption.
- Record version and environment.
Evidence for CRA Availability and Resilience
Evidence can include essential-function inventories, dependency maps, availability threat models, denial-of-service mitigations, capacity assumptions, recovery designs, degraded-mode specifications and resilience test results. For point 2(i), teams can also document how the product limits traffic, retries or other behaviour that could negatively affect surrounding services. The strongest evidence connects a specific availability risk to the selected control and verification result. Product changes that introduce new dependencies, interfaces or workloads should trigger review because they can alter both the product's own resilience and its impact on other systems.
- Essential and basic function inventory.
- Availability threat model.
- Critical dependency map.
- Denial-of-service mitigation design.
- Recovery and degraded-mode evidence.
- Resilience verification results.
- External-service impact analysis.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.