Cloud Vulnerabilities Affecting CRA-Covered Products

Start by Identifying Where the Vulnerability Exists

The first question is whether the vulnerability exists in manufacturer-controlled remote software that forms part of the product, in an integrated third-party component, or solely within an independently supplied cloud service. These situations can produce different CRA obligations. Product security teams should therefore classify the affected layer before deciding what remediation and reporting rules apply.

• Identify the affected software.
• Identify who controls its development.
• Determine whether it is RDPS.
• Identify external providers separately.

A Vulnerability in RDPS Is a Product Vulnerability

Article 3 treats qualifying remote data processing as part of the product with digital elements. A vulnerability in manufacturer-controlled RDPS should therefore be handled as a vulnerability in the product rather than as an unrelated cloud operations issue. Article 13 and Annex I Part II require manufacturers to maintain effective vulnerability handling throughout the support period.

• Include RDPS in vulnerability monitoring.
• Include RDPS in product security testing.
• Remediate backend vulnerabilities.
• Maintain evidence throughout the support period.

Article 13 Requires Systematic Vulnerability Documentation

Article 13(7) requires manufacturers to systematically document relevant cybersecurity aspects in a manner proportionate to the nature and cybersecurity risks of the product. This includes vulnerabilities of which they become aware and relevant information provided by third parties. A cloud provider security advisory can therefore be important even when the provider's service is outside the RDPS product boundary.

• Document known vulnerabilities.
• Record relevant provider advisories.
• Record product impact conclusions.
• Update the cybersecurity risk assessment where applicable.

External Cloud Vulnerabilities Still Need Product Impact Assessment

A vulnerability in an external IaaS, PaaS, SaaS or identity provider should not be dismissed simply because the provider service is not manufacturer RDPS. The manufacturer should determine whether exploitation could affect confidentiality, integrity, availability, authentication, remote commands or other cybersecurity properties of the product. Product-level mitigation can be necessary even while the provider develops its own fix.

• Assess exposure to the provider vulnerability.
• Identify affected product functions.
• Identify compensating controls.
• Monitor provider remediation.
• Document the conclusion.

Provider Advisories Are Inputs, Not Final Product Conclusions

A provider can publish a security bulletin describing a vulnerability and affected service versions, but the manufacturer still needs to determine whether its own product is affected. Configuration, region, service tier, architecture and product-level safeguards can change exposure. Conversely, a provider may classify a vulnerability as moderate while the manufacturer's use creates significant product consequences. Product impact analysis should therefore remain manufacturer-specific.

Article 13(8) Extends Vulnerability Handling Through the Support Period

Article 13(8) requires manufacturers to ensure during the support period that vulnerabilities of the product, including its components, are handled effectively in accordance with Annex I Part II. For cloud-connected products, vulnerability operations should therefore continue after initial market placement and include remote software that remains part of the product. Continuous backend deployment does not remove the obligation to maintain effective vulnerability processes.

• Monitor vulnerabilities throughout the support period.
• Include remote product software.
• Maintain remediation processes.
• Keep vulnerability evidence current.

Annex I Requires Vulnerabilities to Be Remediated Without Delay in Relation to Risk

Annex I Part II requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks posed to the product. A backend vulnerability can sometimes be remediated server-side without requiring the user to install a new local application version. The manufacturer still needs appropriate testing, controlled deployment and evidence that the product risk has been addressed.

• Prioritise according to product risk.
• Patch manufacturer-controlled backend software.
• Test remediation.
• Deploy fixes securely.
• Preserve remediation evidence.

Cloud Fixes Do Not Always Look Like Traditional Product Updates

A remote data processing vulnerability can be corrected through a backend deployment, configuration change, credential rotation, service isolation or another server-side action. The CRA's vulnerability-handling requirements should be applied to the actual architecture rather than assuming every remediation is a downloadable user patch. Where a user-facing security update is necessary, the applicable Annex I update requirements remain relevant.

• Recognise server-side remediation.
• Control backend deployments.
• Record configuration fixes.
• Use user security updates where required by the architecture.

Not Every Cloud Vulnerability Is an Article 14 Report

Article 14 does not require a manufacturer to report every vulnerability it learns about. Mandatory vulnerability reporting concerns actively exploited vulnerabilities contained in the product with digital elements. A vulnerability solely within an independently supplied cloud service is therefore not automatically a reportable actively exploited vulnerability contained in the manufacturer's product. The manufacturer still needs to assess whether its own product contains the vulnerability or is otherwise affected.

• Do not report merely because a provider published a CVE.
• Determine whether the vulnerability is contained in the product.
• Determine whether active exploitation is known.
• Apply the Article 14 trigger to the facts.

A Cloud Event Can Still Become a Severe Product-Security Incident

Article 14 also covers severe incidents having an impact on the security of the product with digital elements. A compromise at an external cloud provider can therefore require Article 14 incident analysis if it negatively affects or is capable of negatively affecting the product's ability to protect relevant data or functions and the statutory severity conditions are met. External-provider status does not by itself prevent an event from becoming a product-security incident.

• Assess impact on product security.
• Assess confidentiality, integrity and availability consequences.
• Assess the Article 14 severity conditions.
• Document the reporting decision.

Third-Party Component Vulnerabilities Have an Additional Upstream Rule

Where the affected item is actually an integrated third-party component, Article 13(6) applies. A manufacturer that identifies a vulnerability in such a component must report it to the person or entity manufacturing or maintaining the component and address and remediate the vulnerability. This rule should not be automatically extended to every independently supplied cloud service simply by calling that service a component. The architecture and legal relationship should first be identified correctly.

• Identify whether the affected dependency is a component.
• Apply Article 13(6) where it is.
• Notify the component manufacturer or maintainer.
• Keep external cloud-service analysis distinct where appropriate.

Security Testing Should Include Product-Facing Cloud Software

Annex I Part II requires effective and regular tests and reviews of product security. Where cloud APIs, authentication systems, databases or remote processing modules form part of the product, they should be represented in the manufacturer's testing programme. Testing should focus on the actual risks and interfaces rather than treating only the locally installed software as the product.

• Test product-facing APIs.
• Test remote authentication.
• Review backend configuration.
• Review cloud interfaces.
• Retest after significant changes.

Maintain a Cloud Vulnerability Decision Record

For material cloud vulnerabilities, record the affected service, provider or manufacturer-controlled module, RDPS status, affected product versions or functions, exploitation status, severity, available mitigations, provider response, manufacturer remediation, Article 14 analysis and risk-assessment updates. This creates a repeatable process for distinguishing ordinary provider advisories from vulnerabilities or incidents requiring direct CRA action.

• Identify the affected layer.
• Record product impact.
• Record exploitation status.
• Record mitigation and remediation.
• Record Article 14 analysis.
• Update risk evidence where applicable.