CRA Requirements for Connected Device Cloud Services

Connected Device Cloud Scope Starts With Article 3(2)

The CRA does not create a special cloud rule only for IoT devices. The standard remote data processing test applies. Manufacturers should identify the remote software, determine whether that software is designed and developed by them or under their responsibility, and identify which device or application function would stop if that processing disappeared. Where all of those elements are satisfied, the remote software is part of the product with digital elements as remote data processing.

• Identify the remote software.
• Identify manufacturer responsibility.
• Identify the connected product function.
• Test behaviour when the remote service is absent.

Remote Control Is an Express CRA Example

Recital 12 specifically refers to cloud-enabled functionality provided by a smart-home device manufacturer that enables users to control the device remotely. The Commission's 2026 guidance develops the same concept through its smart thermostat example. Where remote control is a function offered by the product and manufacturer-controlled software provides the remote processing, the cloud application layer can qualify as RDPS even if the physical device retains manual controls.

• Remote control can be a product function.
• Manual local control does not automatically remove remote processing from scope.
• Manufacturer-controlled cloud logic can be RDPS.
• Map the mobile app and device to the backend.

The Smart Thermostat Example Separates Software From Infrastructure

The Commission guidance describes a smart thermostat and mobile application that exchange data and store user preferences using remote processing developed under the manufacturer's responsibility. That software runs on third-party IaaS. Because the product's smart functions depend on the remote processing and the software is manufacturer-controlled, the software qualifies as RDPS. The underlying third-party physical and virtual infrastructure remains a separate dependency rather than becoming manufacturer-developed RDPS.

Using Third-Party IaaS Does Not Remove Manufacturer Responsibility

The manufacturer can remain responsible for software even when it rents infrastructure from another provider. Under the Commission guidance, manufacturer-created operating systems or applications running on third-party IaaS can qualify as remote data processing where the remaining Article 3(2) conditions are satisfied. The legal product boundary should therefore distinguish the manufacturer's software layer from the provider's underlying hardware, hypervisor and general cloud infrastructure.

• Third-party hosting does not automatically remove RDPS status.
• Manufacturer application software can remain in scope.
• Underlying provider infrastructure can remain external.
• Document responsibility layer by layer.

PaaS Can Produce the Same Layered Result

The Commission guidance similarly explains that a manufacturer can deploy its own application on a third-party PaaS using provider programming languages and execution environments. The application remains designed and developed by or under the responsibility of the manufacturer and can qualify as RDPS where product functionality depends on it. The provider-controlled execution environment should be assessed separately as an external dependency.

• Manufacturer applications on PaaS can qualify as RDPS.
• Provider platform software is a separate layer.
• Functional dependency still needs to be established.
• Cloud model labels do not replace the Article 3(2) test.

The Manufacturer Must Include RDPS in the Cybersecurity Risk Assessment

The Commission guidance states that the manufacturer must consider the product as a whole, including qualifying RDPS, when demonstrating compliance with Annex I. This begins with the cybersecurity risk assessment under Article 13. Risks created by remote authentication, command channels, data storage, remote configuration, cloud APIs and backend availability therefore need to be considered as part of the product's cybersecurity risk profile.

• Include the RDPS in the Article 13 risk assessment.
• Assess remote command paths.
• Assess authentication and authorisation.
• Assess communication integrity.
• Assess backend compromise consequences.

Third-Party Cloud Services Still Create Product Risk

Not every cloud element qualifies as RDPS, but this does not mean non-RDPS services are irrelevant. Commission guidance says manufacturers should consider risks from third-party remote solutions and product environments as part of the cybersecurity risk assessment. Where a provider service is integrated into the product in a manner that affects security, the manufacturer should mitigate those risks through product-level controls and appropriate due diligence.

• Out-of-RDPS does not mean out-of-risk.
• Assess third-party cloud dependencies.
• Use product-level mitigations.
• Perform proportionate provider due diligence.

Technical Documentation Should Describe Both RDPS and External Cloud Reliance

The 2026 Commission guidance recommends that manufacturers indicate in technical documentation whether the product has RDPS or relies on third-party remote solutions and describe those solutions. In the smart thermostat example, the manufacturer documents both the qualifying RDPS and reliance on third-party IaaS, including details of the contracted service. This makes the product architecture and cloud dependency model visible during conformity assessment.

• Identify RDPS in technical documentation.
• Describe important third-party remote services.
• Document contracted cloud dependencies.
• Connect the description to the risk assessment.

Cloud Provider Assurance Can Support Manufacturer Due Diligence

The Commission guidance recognises that manufacturers can reuse relevant assurance evidence when evaluating third-party cloud services. Depending on the provider and service, evidence can include regulatory compliance, cybersecurity certification or recognised security standards. Such evidence supports but does not replace the manufacturer's own assessment of whether its product-level controls and selected provider are appropriate for the identified risks.

• Collect proportionate provider assurance.
• Consider applicable NIS2 evidence where relevant.
• Consider recognised security certifications.
• Do not treat provider certification as product conformity.

Shared Responsibility Does Not Transfer CRA Product Responsibility

Cloud providers commonly describe security through shared-responsibility models. Those models can help identify which technical controls are available to the manufacturer, but they do not transfer the manufacturer's CRA obligations for the product it places on the market. The manufacturer should configure available provider security functions, implement product-level controls and verify that provider measures remain sufficient for the risks identified.

• Use shared-responsibility models as technical input.
• Keep CRA manufacturer responsibility with the manufacturer.
• Configure provider security functions correctly.
• Implement compensating product-level controls where needed.

Cloud Provider Changes Should Trigger Risk Review

The Commission guidance encourages manufacturers to ensure third-party providers keep them adequately informed about significant changes. A provider change does not automatically become a substantial modification of the product where the third-party solution is outside the manufacturer's responsibility, but the manufacturer can still need to revise the cybersecurity risk assessment and determine whether existing product-level controls remain appropriate.

• Monitor important provider changes.
• Review the cybersecurity risk assessment.
• Reassess provider assurance.
• Update product-level mitigations where needed.

Maintain a Connected Cloud Responsibility Map

For each connected-device cloud architecture, maintain a responsibility map covering the device, firmware, mobile application, manufacturer-controlled backend, APIs, databases, IaaS or PaaS provider, identity services and other remote dependencies. Mark which software qualifies as RDPS, which services are external dependencies and which security controls belong to each layer. This avoids treating the cloud either as entirely inside or entirely outside the CRA product.

• Map device and application layers.
• Map manufacturer-controlled cloud software.
• Map third-party infrastructure.
• Identify RDPS explicitly.
• Identify external dependencies explicitly.
• Review the map after architecture changes.