CRA Shared-Responsibility Models for Cloud-Connected Products

Shared Responsibility Is a Technical Model, Not a Transfer of CRA Duties

Cloud providers commonly divide technical responsibilities between provider and customer. The provider might secure physical infrastructure while the customer configures identities, networks and applications. That allocation is useful for engineering, but it does not change who is the manufacturer of the CRA-covered product. The manufacturer remains responsible for ensuring its product complies with applicable CRA requirements.

• Separate technical responsibility from legal product responsibility.
• Use provider responsibility models as engineering input.
• Keep CRA product ownership explicit.
• Do not treat outsourcing as a conformity transfer.

IaaS Leaves Significant Product Security With the Manufacturer

With Infrastructure as a Service, the provider generally controls physical infrastructure and virtualisation layers while the customer controls substantial portions of operating-system configuration, applications and product logic. Manufacturer-developed software on that infrastructure can still qualify as remote data processing. The manufacturer's responsibility therefore includes securing its application and appropriately configuring the cloud resources it controls.

• Provider secures underlying infrastructure according to its service model.
• Manufacturer secures its product software.
• Manufacturer configures customer-controlled cloud resources.
• RDPS status remains possible.

PaaS Changes the Technical Boundary but Not the CRA Principle

Platform as a Service moves more technical responsibility to the provider because the provider can operate runtime environments, databases or platform services. The manufacturer can still design and develop the application that delivers product functionality. Commission guidance confirms that manufacturer software deployed on PaaS can remain within the remote data processing analysis where the statutory conditions are satisfied.

• Identify provider-managed platform controls.
• Identify manufacturer application controls.
• Assess manufacturer-developed product logic.
• Apply Article 3(2) to the relevant software.

Third-Party SaaS Can Place More Application Security With the Provider

In a standard third-party SaaS model, the provider designs and operates the complete application while the manufacturer primarily configures or integrates it. That makes the manufacturer-responsibility limb of Article 3(2) less likely to be satisfied for the SaaS application itself. The service can still be an important external dependency whose integration, configuration and product-security consequences remain the manufacturer's responsibility.

• Distinguish provider application responsibility.
• Assess manufacturer configuration responsibility.
• Treat product integration risk separately.
• Do not assume SaaS is manufacturer RDPS.

Manufacturer-Controlled Configuration Can Create Security Responsibility

Even where the provider operates a technical control, the manufacturer can remain responsible for configuring how its product uses that control. Examples include network exposure, storage permissions, authentication settings, encryption options, API permissions and logging. A provider may supply a secure capability that becomes ineffective because the manufacturer's configuration is insecure.

• Identify customer-configurable controls.
• Apply secure configuration.
• Review default settings.
• Control configuration changes.
• Include configuration risk in the cybersecurity risk assessment.

Provider Security Controls Should Be Mapped to Product Risks

A shared-responsibility model becomes useful for CRA work when provider controls are mapped to the risks identified for the product. If product availability depends on a provider resilience control, or product confidentiality depends on a provider storage control, the manufacturer should understand what assurance exists and what product-level mitigation is needed if the provider control fails.

Provider Assurance Does Not Equal Product Conformity

Cloud certifications, audit reports and regulatory compliance statements can provide valuable evidence about provider controls. They do not establish that the manufacturer's own product satisfies the CRA. The conformity assessment concerns the product and the manufacturer's processes. Provider evidence should therefore be incorporated into the manufacturer's risk analysis rather than substituted for it.

• Use provider assurance as evidence.
• Verify assurance scope.
• Map evidence to product risks.
• Retain manufacturer conclusions.

Contracts Can Reinforce the Shared-Responsibility Model

Contracts can document responsibilities for security notifications, service changes, vulnerability information, incident support and other operational dependencies. The CRA does not prescribe a standard cloud contract. Contract terms should therefore support the manufacturer's actual product-security needs and should not be treated as substitutes for technical controls or the manufacturer's statutory responsibilities.

• Align contracts with product risk.
• Define notification expectations.
• Define relevant support arrangements.
• Do not rely on contract wording instead of security controls.

Incident Response Should Follow the Actual Control Boundary

A cloud incident can cross provider and manufacturer responsibilities. The provider might investigate infrastructure compromise while the manufacturer assesses product impact, rotates product credentials, changes configuration or communicates with users. Incident plans should therefore identify who performs each action while keeping the manufacturer responsible for assessing consequences for the CRA-covered product.

• Define provider incident contacts.
• Define manufacturer product-impact analysis.
• Define credential and configuration actions.
• Preserve CRA reporting analysis where relevant.

Provider Changes Can Shift the Shared-Responsibility Boundary

Cloud providers can change service architecture, managed features or configuration models. A manufacturer can also move from IaaS to PaaS or replace an internally managed database with a provider-managed service. These changes can move technical control ownership and alter product risk. The shared-responsibility map and cybersecurity risk assessment should therefore be reviewed after material architecture changes.

• Review service-model changes.
• Review new managed services.
• Review changed configuration ownership.
• Update security responsibilities.

Shared Responsibility Should Be Reflected in Technical Documentation

Where cloud responsibilities are material to product security, technical documentation should make those boundaries understandable. The manufacturer can identify which remote software it controls, which provider services it relies on, which security controls the provider operates and which controls the manufacturer configures or implements. This supports the system architecture and cybersecurity risk documentation required by Annex VII.

• Document manufacturer-controlled software.
• Document external provider layers.
• Document significant security-control dependencies.
• Connect responsibility to product risk.

Do Not Let Shared Responsibility Create Unowned Controls

The most dangerous shared-responsibility failure is a control that both parties assume the other owns. Examples can include patching a customer-managed operating system, rotating product secrets, configuring network access or reviewing security logs. Manufacturers should identify each security-relevant control and ensure responsibility is explicit rather than inferred from marketing material.

• Identify control ownership.
• Resolve ambiguous responsibility.
• Verify provider and manufacturer assumptions.
• Test critical operational processes.

Maintain a CRA Cloud Responsibility Matrix

Maintain a matrix listing product software, provider services and significant security controls. For each row, identify whether the element is RDPS or an external dependency, the responsible technical party, manufacturer configuration duties, relevant provider assurance, product risk, monitoring responsibility, incident responsibility and technical-documentation reference. Review the matrix whenever architecture or provider responsibilities materially change.

• List important cloud services.
• Record RDPS status.
• Record provider controls.
• Record manufacturer controls.
• Record configuration responsibility.
• Record product risk.
• Review after material changes.