Cloud Availability and Product Security Under the CRA

Availability Is an Express CRA Cybersecurity Requirement

Annex I Part I expressly addresses availability. Based on the cybersecurity risk assessment and where applicable, a product must protect the availability of essential and basic functions, including after an incident. The Regulation specifically refers to resilience and mitigation measures against denial-of-service attacks. Cloud-connected products therefore need to treat availability as part of cybersecurity architecture rather than only as a service-level management issue.

• Availability is part of Annex I.
• The requirement is risk based.
• Essential and basic functions matter.
• Post-incident availability matters.
• Denial-of-service resilience is expressly referenced.

CRA Availability Is Not an Absolute Uptime Guarantee

The CRA requirement should not be rewritten as a guarantee that cloud services can never be unavailable. Annex I addresses cybersecurity protection of essential and basic functions according to risk. Ordinary maintenance, infrastructure failure and other non-security downtime can raise operational or contractual issues without automatically proving that Annex I has been breached. The manufacturer should instead show that relevant cybersecurity availability risks were assessed and addressed appropriately.

• The CRA is not a universal 100 percent uptime rule.
• Cybersecurity risk drives the requirement.
• Ordinary downtime and cybersecurity failure are not identical.
• Evidence should focus on risk and appropriate controls.

Remote Data Processing Creates an Important Availability Dependency

Article 3(2) itself uses functional dependency to define remote data processing. If removing the manufacturer-controlled remote service prevents the product from performing one of its functions, the service can form part of the CRA product. This dependency also provides an important input to availability risk analysis because disruption of that remote service can directly remove product functionality.

• Identify cloud-dependent product functions.
• Identify which functions are essential or basic.
• Assess consequences of remote-service loss.
• Connect Article 3 scope to Annex I risk analysis.

Denial-of-Service Attacks Need Explicit Consideration

Annex I specifically names resilience and mitigation against denial-of-service attacks. Cloud products can face volumetric attacks, application-layer exhaustion, authentication abuse, request floods or resource depletion. The CRA does not mandate one technical architecture, so manufacturers should select measures appropriate to the product, deployment model and consequences of lost availability.

• Consider network-level denial of service.
• Consider application-level exhaustion.
• Consider authentication-service overload.
• Consider rate and resource abuse.
• Select proportionate mitigation.

Essential and Basic Functions Should Be Identified Explicitly

Availability controls are easier to justify when the manufacturer has identified which functions are essential or basic for the product. A product can contain convenience features whose temporary loss has limited security significance alongside functions whose loss exposes users or connected systems to material risk. The cybersecurity risk assessment should distinguish those functions rather than assigning every cloud feature the same availability objective.

Local Fallback Can Be One Resilience Measure

For some connected products, selected functions can continue locally when remote processing is unavailable. Local fallback, cached configuration or safe offline operation can reduce the impact of cloud disruption. The CRA does not impose a universal requirement that every cloud-connected product work offline, so fallback should be selected when appropriate to the product's cybersecurity risks and intended functionality.

• Consider safe local fallback.
• Consider cached operation where appropriate.
• Preserve security during degraded modes.
• Do not weaken authentication merely to maintain availability.

Graceful Degradation Should Remain Secure

A product can retain limited functions during a cloud incident without attempting full normal operation. That degraded mode should not introduce an easier path for unauthorised access, disable integrity controls or expose sensitive data simply to preserve availability. Availability and other Annex I properties need to be balanced through the cybersecurity risk assessment.

• Define safe degraded behaviour.
• Do not bypass access controls.
• Preserve integrity protections.
• Protect sensitive data during fallback.

Third-Party Cloud Outages Remain Relevant to Product Risk

A third-party provider can remain outside the manufacturer's RDPS while still being a critical external dependency. If loss of the provider affects the product, the manufacturer should consider that dependency in the cybersecurity risk assessment. Relevant controls can include architecture choices, provider assurance, redundancy, recovery arrangements or product-level fallback depending on the identified risks.

• Assess external provider outages.
• Identify product consequences.
• Consider provider assurance.
• Consider proportionate resilience measures.

Availability of Other Devices and Networks Also Matters

Annex I Part I point 2(i) requires products to minimise their negative impact, or that of connected devices, on the availability of services provided by other devices or networks. A cloud-connected product should therefore not only defend its own availability. Manufacturers should also consider whether compromised or malfunctioning products could generate excessive traffic, abusive requests or other behaviour that reduces availability elsewhere.

• Consider outbound abuse.
• Consider excessive traffic.
• Consider cascading availability effects.
• Design product behaviour to limit external impact.

Availability Controls Should Be Tested

Annex I Part II requires effective and regular tests and reviews of product security. Availability controls therefore should not exist only in architecture documents. Manufacturers can test behaviour under service loss, resource exhaustion, dependency failure, recovery and degraded operation in a manner proportionate to product risk. Testing should verify both continued function and continued security.

• Test service-loss behaviour.
• Test recovery.
• Test degraded modes.
• Test relevant resource-exhaustion scenarios.
• Verify security controls remain effective.

Cloud Incidents Should Feed Back Into Product Risk Management

Where a cloud incident exposes an availability weakness, manufacturers should document the cybersecurity relevance and update the product risk assessment where applicable. Article 13 requires cybersecurity risks to be considered throughout planning, development, delivery and maintenance rather than only before first market placement. Repeated provider outages or new denial-of-service patterns can therefore justify changed controls.

• Record security-relevant cloud incidents.
• Review root causes.
• Update risk assessment where applicable.
• Improve resilience controls when needed.

Document Availability Assumptions in the Product Architecture

The product architecture should identify which cloud services support essential or basic functions, which services are manufacturer RDPS and which are external dependencies. Document key assumptions such as required connectivity, provider reliance, fallback behaviour and recovery expectations. This makes it easier to demonstrate why the selected availability measures are proportionate to the product's risks.

• Map cloud-dependent functions.
• Identify RDPS.
• Identify external providers.
• Record fallback behaviour.
• Record important availability assumptions.

Maintain a Cloud Availability Risk Register

For important remote services, maintain an availability risk record identifying the service, supported product functions, importance of those functions, likely cybersecurity failure modes, denial-of-service exposure, provider dependency, fallback behaviour, resilience controls, testing evidence and recovery approach. Review the record when product functionality or cloud architecture changes.

• Identify the remote service.
• Identify affected product functions.
• Record availability risks.
• Record resilience controls.
• Record tests.
• Review after architecture changes.