Manufacturers should separate cloud layers instead of treating a provider relationship as one legal object. Product-facing software under manufacturer responsibility, provider-controlled infrastructure and independent SaaS dependencies can occupy different CRA positions while all remaining relevant to the security of the finished product.
Third-Party Cloud Use Does Not Transfer CRA Product Responsibility
A manufacturer remains responsible for the product with digital elements it places on the market even when substantial parts of its technical architecture rely on cloud suppliers. Contracting for infrastructure, platforms or software services does not make the provider the manufacturer of the customer's product. The manufacturer must understand how the selected cloud services affect its own product security and implement the controls needed to satisfy applicable CRA requirements.
- The manufacturer remains responsible for its product.
- Cloud outsourcing does not outsource CRA manufacturer status.
- Provider controls can support compliance.
- Product-level security decisions remain with the manufacturer.
Separate Manufacturer Software From Provider Infrastructure
The 2026 Commission guidance uses IaaS and PaaS to explain why cloud architecture needs a layer-by-layer analysis. Manufacturer-developed applications can remain under manufacturer responsibility even when they run on provider-controlled infrastructure or execution environments. The application software can therefore qualify as RDPS where Article 3(2) is satisfied while the provider's underlying infrastructure remains an external dependency.
- Identify manufacturer-controlled application software.
- Identify provider-controlled infrastructure.
- Identify provider platform services.
- Apply Article 3(2) to the relevant manufacturer software.
Independent Third-Party Cloud Services Are Not Automatically RDPS
Recital 12 and the Commission guidance distinguish cloud services designed and developed outside the responsibility of the manufacturer. A standard third-party SaaS or other independently supplied service therefore does not automatically become the manufacturer's remote data processing solution simply because the product depends on it. Manufacturer responsibility for design and development remains part of the Article 3(2) definition.
- Functional dependency alone does not decide RDPS status.
- Manufacturer development responsibility is also required.
- Independent SaaS can remain an external service.
- Document the legal and technical boundary.
External Cloud Dependencies Can Still Affect CRA Product Security
A remote service can sit outside the RDPS definition while still creating material cybersecurity risk for the product. The Commission guidance makes clear that relevant risks from third-party remote solutions should be considered in the cybersecurity risk assessment. A provider outage, compromised account, insecure API, configuration weakness or supply-chain incident can affect the manufacturer's product even where the provider service itself is not part of the CRA product boundary.
- Out of RDPS does not mean out of risk.
- Assess external cloud dependencies.
- Identify security consequences for product functions.
- Implement product-level mitigations.
Use Proportionate Due Diligence for Security-Relevant Cloud Providers
Article 13(5) expressly addresses third-party components, while the Commission guidance indicates that security-relevant third-party remote solutions should be considered similarly when evaluating product cybersecurity. The manufacturer should therefore perform proportionate due diligence appropriate to the role and risk of the service. The depth of review for a critical authentication dependency can reasonably differ from the review for a low-impact ancillary service.
Provider Certifications Can Support but Not Replace Product Assessment
Cloud providers can offer certifications, audit reports, regulatory assurances and security documentation. These materials can reduce duplicated assessment effort and help the manufacturer understand provider controls. They do not by themselves demonstrate that the manufacturer's finished product complies with the CRA. The manufacturer still needs to assess the integration, configuration, product architecture and risks arising from its own use of the service.
- Reuse credible provider assurance where appropriate.
- Check assurance scope.
- Check whether the relevant service is covered.
- Do not treat provider certification as CRA product conformity.
Cloud Shared-Responsibility Models Are Technical Inputs
IaaS, PaaS and SaaS providers commonly publish shared-responsibility models showing which security controls belong to the provider and which belong to the customer. These models are valuable engineering inputs, but they do not rewrite CRA manufacturer obligations. A control assigned to the provider still needs to be understood by the manufacturer where failure of that control could compromise the CRA-covered product.
- Use the provider's responsibility matrix.
- Map provider controls to product risks.
- Identify manufacturer configuration duties.
- Do not confuse technical delegation with legal responsibility.
Cloud Contracts Should Support Security Operations
Cloud contracts and service terms can support CRA operations by giving manufacturers access to incident information, security notifications, vulnerability information, provider change notices and appropriate technical support. The CRA does not prescribe one cloud contract template, so contractual measures should reflect the risks and importance of the service. Contract language should complement rather than substitute technical safeguards.
- Consider security notification mechanisms.
- Consider provider change notifications.
- Consider incident communication.
- Consider vulnerability information access.
- Align contractual expectations with product risk.
Provider Changes Should Feed Back Into the Risk Assessment
Cloud services change frequently. The provider can alter infrastructure, platform features, identity systems, regions, APIs or security controls without changing the manufacturer's local product code. Manufacturers should therefore monitor material provider changes and update their cybersecurity risk assessment where those changes alter product risk. A provider change should not be ignored merely because the external service remains outside the RDPS boundary.
- Monitor material provider changes.
- Review changed security controls.
- Review changed interfaces.
- Update risk analysis where applicable.
Technical Documentation Should Identify Important Cloud Dependencies
The Commission guidance recommends documenting whether a product has remote data processing solutions or relies on third-party remote services. For material cloud dependencies, technical documentation should make the architecture understandable enough to distinguish manufacturer-controlled product software from important external services. The record can include the service role, provider, interfaces, dependent product functions and relevant security assumptions.
- Describe manufacturer RDPS.
- Describe material external cloud dependencies.
- Identify product functions that depend on them.
- Record important security assumptions.
Plan for Provider Failure and Provider Exit
A cloud dependency can become unavailable because of an incident, commercial termination, provider shutdown or architectural migration. Where that dependency supports important product functions, the manufacturer should understand how it would preserve security and product support. Exit planning can include data portability, alternative infrastructure, controlled service shutdown, product fallback or customer communication according to the actual product risks.
- Identify critical provider dependencies.
- Consider provider failure scenarios.
- Consider secure migration.
- Consider product fallback.
- Consider support-period consequences.
Maintain a Third-Party Cloud Dependency Register
Maintain a register for significant cloud providers and services. Record the provider, service model, software layer, manufacturer responsibility, RDPS status, dependent product functions, security importance, provider assurance, due-diligence evidence, change-notification mechanism and exit considerations. This creates a repeatable CRA record without treating every cloud service as though it has the same legal or technical significance.
- Identify provider and service.
- Record IaaS, PaaS or SaaS role.
- Record RDPS conclusion.
- Record dependent product functions.
- Record due-diligence evidence.
- Record change and exit arrangements.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.