Search every question across sub-FAQs

When remote processing qualifies as RDPS, it is part of the product with digital elements for CRA assessment. The manufacturer's cybersecurity risk assessment must cover the whole product, including in-scope RDPS and supporting functions.

The manufacturer should still avoid over-scoping. The draft guidance says conformity assessment should focus on the parts of the remote system where data necessary for product functions is stored or processed, while risks from surrounding infrastructure and third-party cloud services should be assessed and mitigated at product level.

Where relevant, the technical documentation should identify whether the product has RDPS or relies on third-party cloud solutions and describe those solutions. If the same RDPS supports multiple products, it should still be declared in each product's documentation.

The documentation should connect the remote solution to the product function, explain whether it is manufacturer-designed or a third-party dependency, identify the parts of the system assessed for conformity, and record the risk assessment and mitigations for RDPS, third-party cloud reliance, and surrounding infrastructure.

Article 13(18) requires products to be accompanied by Annex II information and instructions that are clear, understandable, intelligible, legible, and sufficient for secure installation, operation, and use. If RDPS, cloud connectivity, account services, or backend assumptions are needed for secure use, the user information should make those conditions understandable.

Annex II is especially relevant where remote dependencies affect intended purpose, essential functions, security properties, significant cybersecurity risks, secure commissioning and use, security updates, support-period information, decommissioning, or secure removal of user data.

No. Contracts, SLAs, and provider assurances can support risk mitigation and due diligence, but the CRA product obligation remains with the manufacturer placing the product with digital elements on the market.

The draft guidance says manufacturers should combine product-level security controls with verification of provider security measures. SLAs can help when they include security guarantees such as vulnerability-handling assurances and change-notification commitments from third-party cloud providers.

Not automatically. The draft guidance says major changes in third-party cloud solutions should not by themselves qualify as substantial modification of the product where those solutions are not under the manufacturer's responsibility.

The manufacturer still has to manage resulting risk. Change notice, reassessment, updated mitigations, and documentation may be needed where the provider change affects product security, product functions, or assumptions recorded in the risk assessment.

Manufacturers must report two categories once Article 14 applies: any actively exploited vulnerability contained in the product with digital elements, and any severe incident having an impact on the security of that product.

The duty applies from 11 September 2026. It is not limited to newly launched products: Article 69(3) extends Article 14 to in-scope products placed on the market before 11 December 2027.

The CRA definition requires reliable evidence that a malicious actor exploited the vulnerability in a system without the system owner's permission.

A vulnerability is therefore not reportable under Article 14 just because it exists, is serious, or has no patch yet. The Commission FAQ says zero-days discovered by ethical hackers, bug-bounty participants, or assessment laboratories are not mandatory Article 14 reports unless there is evidence of previous malicious exploitation. They may still be reported voluntarily under Article 15.

A severe incident is an incident affecting the security of the product with digital elements where either condition in Article 14(5) is met.

The first condition is a negative effect, or a capability to negatively affect, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions. The second is that the incident has led, or is capable of leading, to malicious code being introduced or executed in the product or in the user's network and information systems.

Recital 68 also links severe incidents to compromises of the manufacturer's processes when those compromises affect the product's security, so investigation should not be limited to deployed product telemetry.

The legal clock runs from when the manufacturer becomes aware of the actively exploited vulnerability or severe incident.

The draft Commission guidance says awareness follows an initial assessment: the manufacturer is regarded as aware when it has a reasonable degree of certainty that a vulnerability in its product is being actively exploited, or that a severe incident occurred and compromised the product's security. Teams should therefore record when the suspicious signal arrived, what initial assessment was performed, and when the assessment reached that threshold.

No. The Commission FAQ says Article 14 does not prescribe how a manufacturer becomes aware of an actively exploited vulnerability or severe incident.

The FAQ gives examples: customer or partner reports, threat intelligence, security researchers, government cybersecurity agencies, ethical hackers, telemetry, honeypots, internal scanning, and dark-web monitoring. Those examples do not create a duty to monitor every channel, but they are useful for designing intake and triage routes.

Article 14(2) creates three stages.

- Early warning: without undue delay and in any event within 24 hours of becoming aware.

- Vulnerability notification: without undue delay and in any event within 72 hours of becoming aware, unless the information was already provided.

- Final report: no later than 14 days after a corrective or mitigating measure is available.

The 24-hour and 72-hour deadlines do not wait for a patch. The final-report clock is tied to availability of a corrective or mitigating measure.

Article 14(4) also creates three stages.

- Early warning: without undue delay and in any event within 24 hours of becoming aware.

- Incident notification: without undue delay and in any event within 72 hours of becoming aware, unless the information was already provided.

- Final report: within one month after submission of the incident notification.

The severe-incident final report is therefore keyed to the 72-hour incident notification, not to patch availability.

For an actively exploited vulnerability, the early warning indicates, where applicable, the Member States where the manufacturer knows the product has been made available. The 72-hour vulnerability notification adds available information about the product, the general nature of the exploit and vulnerability, corrective or mitigating measures already taken, measures users can take, and the sensitivity of the notified information where applicable.

For a severe incident, the early warning must at least say whether the incident is suspected of being caused by unlawful or malicious acts, and where applicable identify Member States where the product has been made available. The 72-hour incident notification adds available information about the incident's nature, an initial assessment, corrective or mitigating measures already taken, user measures, and sensitivity.

For an actively exploited vulnerability, the final report must include a description of the vulnerability, its severity and impact, information about the malicious actor where available, and details of the security update or other corrective measures made available.

For a severe incident, the final report must include a detailed incident description, severity and impact, the likely threat type or root cause, and applied and ongoing mitigation measures.

The manufacturer files via the single reporting platform established by ENISA, using the electronic notification endpoint of the relevant CSIRT designated as coordinator. ENISA receives simultaneous access through that mechanism.

A direct ENISA-only notification is not the Article 14 route for mandatory reports. The route is CSIRT coordinator endpoint plus simultaneous ENISA access through the single reporting platform.

If the manufacturer has a main establishment in the Union, the relevant CSIRT is in the Member State where decisions related to product cybersecurity are predominantly taken. If that cannot be determined, it is the Member State where the manufacturer has the establishment with the highest number of employees in the Union.

If the manufacturer has no main establishment in the Union, Article 14(7) uses a fallback order based on the authorised representative, importer, distributor, and finally the Member State with the highest number of users. If the user-location fallback is used, later related reports may be sent to the same CSIRT coordinator.

The CSIRT coordinator that initially receives the notification disseminates it through the single reporting platform to the CSIRTs for Member States where the manufacturer indicated the product has been made available. CSIRTs designated as coordinators also provide national market surveillance authorities with notified information needed for CRA tasks.

The initially receiving CSIRT may request intermediate status updates. ENISA manages and maintains the platform, can receive relevant information for EU-level crisis coordination, prepares trend reports from notifications, and adds publicly known notified vulnerabilities to the European vulnerability database after a security update or other corrective or mitigating measure is available and in agreement with the manufacturer.

Yes, but the CRA frames this as an exceptional dissemination control after notification, not as extra time for the manufacturer to file.

Article 16 allows the initially receiving CSIRT to delay dissemination on justified cybersecurity-related grounds for only the period strictly necessary, including coordinated vulnerability disclosure cases. Article 16 also has a narrower exceptional process for actively exploited vulnerabilities where immediate wider dissemination would conflict with specified essential interests or create imminent high cybersecurity risk.

If no corrective or mitigating measure is available, ENISA and the CSIRTs network must provide procedures so information is shared under strict security protocols and on a need-to-know basis.

Yes. After becoming aware of an actively exploited vulnerability or severe incident, the manufacturer must inform impacted users and, where appropriate, all users. The notice must include any risk-mitigation and corrective measures users can deploy where necessary, and where appropriate must be structured, machine-readable, and easily automatically processable.

The Commission FAQ confirms this Article 14(8) user-notice duty also matters for older in-scope products placed on the market before 11 December 2027.

No. The draft Commission guidance says Article 14(8) should be applied in a risk-based and proportionate way. It does not require public or indiscriminate disclosure in every case.

Detailed information may be limited to affected users or customers where appropriate, especially for products used in sensitive or essential environments where public technical detail could increase cybersecurity risk or facilitate further exploitation. If the manufacturer does not inform users in time, the notified CSIRTs may inform users when proportionate and necessary to prevent or mitigate impact. For severe incidents, Article 17(2) also allows public information or a requirement that the manufacturer inform the public where public awareness is necessary or in the public interest.