EU Cyber Resilience Act: Preparing for Vulnerability and Incident Reporting

1. Background

The CRA (Regulation (EU) 2024/2847) establishes mandatory minimum cybersecurity requirements for “products with digital elements”, which include many hardware and software products and their remote data processing solutions (see a high-level step-by-step guide on the CRA's material scope here).

The CRA entered into force on 10 December 2024 and generally applies from 11 December 2027. However, the reporting obligations under Art. 14 CRA apply more than a year earlier, from 11 September 2026 (Art. 71(2) CRA). For a broader overview of the 2026 CRA implementation timeline, see our previous blog posts key 2026 milestones toward CRA compliance, the CRA’s implications for companies and the Commission’s draft CRA guidance as well as our Digital Transformation Academy video.

Notably, the reporting obligations apply from 11 September 2026 to all products with digital elements within the CRA's scope that have been made available on the EU market before full CRA application (Art. 69(3) CRA). The early applicability of the reporting obligations has significant practical implications, as manufacturers must ensure that CRA reporting procedures cover not only upcoming product launches, but also legacy products. Ahead of this milestone, ENISA has published FAQ on the Single Reporting Platform ("SRP"), which provides initial details on how the SRP would operate in practice.

The reporting regime applies where the relevant product with digital elements falls within the CRA's scope, the relevant actor qualifies as a manufacturer under the CRA, and the manufacturer becomes aware of either an actively exploited vulnerability contained in the product or a severe incident having an impact on the security of the product (Art. 14(1), (3) CRA).

2. Who must report?

The primary reporting obligations apply to the manufacturer of an in-scope product with digital elements:

• A manufacturer includes any natural or legal person who develops or manufactures products with digital elements, or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetization or free of charge (Art. 3(13) CRA).
• The manufacturer role should be determined for each in-scope product. This is particularly relevant for corporate groups, white-label products, OEM arrangements, software components, and products developed by one entity but marketed by another. An importer or distributor will be treated as a manufacturer where it places a product with digital elements on the market under its own name or trademark or carries out a substantial modification (Art. 21 CRA). Another person carrying out a substantial modification and making the modified product available on the EU market is also treated as a manufacturer (Art. 22 CRA).

In addition, open-source software stewards have limited Art. 14-related obligations:

• Actively exploited vulnerabilities. The obligation to report actively exploited vulnerabilities extends to open-source software stewards insofar as they are involved in the development of these relevant products (Art. 24(3) CRA).
• Severe incidents and user notifications. The obligation to report severe incidents and to notify users of an actively exploited vulnerability or severe incident applies to the extent such incidents impact the network and information systems provided by the steward for the development of those products (Art. 24(3) CRA).

Importers and distributors of products with digital elements are not directly subject to the reporting obligations under Art. 14 CRA unless they are treated as manufacturers. From a practical perspective, however, they may receive vulnerability or incident information from customers, security researchers, or downstream users and should be able to escalate that information to the relevant manufacturer without delay.

3. What must be reported?

The CRA creates two mandatory reporting tracks: The first concerns actively exploited vulnerabilities, and the second concerns severe incidents having an impact on the security of the product.

a) Actively exploited vulnerabilities

A "vulnerability" is defined as a weakness, susceptibility, or flaw of a product with digital elements that can be exploited by a cyber threat (Art. 3(40) CRA). An "actively exploited vulnerability" is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner (Art. 3(42) CRA).

The obligation is therefore not triggered by every vulnerability contained in a product. It is triggered where the manufacturer becomes aware that the vulnerability is being actively exploited. A vulnerability that is not actively exploited may still require remediation, coordinated vulnerability disclosure, security updates, and product-security documentation for compliance with Annex I CRA, but it does not itself trigger mandatory Art. 14 reporting.

b) Severe incidents affecting product security

An "incident having an impact on the security of the product with digital elements" is defined as an incident that negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity, or confidentiality of data or functions (Art. 3(44) CRA). The definition of "incident" aligns with the NIS2 Directive and includes any event compromising the availability, authenticity, integrity, or confidentiality of stored, transmitted, or processed data or of the services offered by, or accessible via, network and information systems (Art. 3(43) CRA; Art. 6(6) NIS2 Directive).

For CRA reporting purposes, an incident is severe where it negatively affects or is capable of negatively affecting the product's ability to protect sensitive or important data or functions, or where it has led or is capable of leading to the introduction or execution of malicious code in the product or in a user's network and information system (Art. 14(5) CRA).

c) Voluntary reporting

Manufacturers and other natural or legal persons may voluntarily report vulnerabilities contained in products with digital elements, cyber threats that could affect the risk profile of products with digital elements, incidents having an impact on the security of products with digital elements, and near misses that could have resulted in such incidents (Art. 15(1), (2) CRA). ENISA indicates that the SRP will offer functionality for voluntary reporting after September 11, 2026 (ENISA SRP FAQ, Q6).

4. When does the reporting timeline start?

The reporting timeline starts when the manufacturer becomes aware of the actively exploited vulnerability or severe incident. The CRA does not define a detailed awareness threshold, which makes the internal assessment process particularly important.

The Commission's draft CRA guidance, published for feedback on 3 March 2026, indicates that manufacturers should conduct an immediate assessment after detecting a suspicious event or receiving notice of a potential vulnerability or incident from sources such as individuals, customers, authorities, or media organizations. According to the draft guidance, awareness arises once the manufacturer has a reasonable degree of certainty that a vulnerability contained in its product is being actively exploited, or that a severe incident has occurred and has led to the security of its product being compromised. This interpretation is broadly aligned with awareness triggers under other EU reporting regimes, such as Art. 33(1) GDPR.

This approach has two practical consequences:

• Unverified information does not necessarily start the clock. A customer report, researcher submission, media article, or supplier notification may require immediate assessment, but it will not in every case establish awareness of a reportable event.
• Manufacturers cannot wait for complete forensic certainty. Once the threshold of reasonable certainty is met, the manufacturer should be prepared to report within the CRA reporting timelines (see below), even if the investigation remains ongoing.

For governance purposes, manufacturers should document when information was first received, what was known at each stage, when the internal reporting threshold was met, and why the event was or was not treated as reportable.

5. What is the reporting timeline?

The CRA reporting obligations are staged. They require an early warning notification, a more substantial follow-up notification, and a final report once further technical and remediation information is available.

a) Reporting actively exploited vulnerabilities

Where the manufacturer becomes aware of an actively exploited vulnerability contained in the product, the following reports are required:

• Early warning notification. This must be submitted without undue delay and in any event within 24 hours. It should indicate, where applicable, the Member States on whose territory the manufacturer is aware that the product has been made available (Art. 14(2)(a) CRA).
• Vulnerability notification. This must be submitted without undue delay and in any event within 72 hours. Unless already provided, it must include general information about the product concerned, the general nature of the exploit and vulnerability, corrective or mitigating measures taken, corrective or mitigating measures that users can take, and an indication of how sensitive the notified information is considered to be where applicable (Art. 14(2)(b) CRA).
• Final report. This must be submitted no later than 14 days after a corrective or mitigating measure is available. Unless already provided, the final report must include a description of the vulnerability, including its severity and impact, available information about the malicious actor, and details about the security update or other corrective measures made available (Art. 14(2)(c) CRA).

b) Reporting severe incidents

Where the manufacturer becomes aware of a severe incident having an impact on the security of the product, the following reports are required:

• Early warning notification. This must be submitted without undue delay and in any event within 24 hours. It must include at least whether the incident is suspected of being caused by unlawful or malicious acts and, where applicable, the Member States on whose territory the manufacturer is aware that the product has been made available (Art. 14(4)(a) CRA).
• Incident notification. This must be submitted without undue delay and in any event within 72 hours. Unless already provided, it must include general information about the nature of the incident, an initial assessment, corrective or mitigating measures taken, corrective or mitigating measures that users can take, and an indication of how sensitive the notified information is considered to be where applicable (Art. 14(4)(b) CRA).
• Final report. This must be submitted within one month after the incident notification. Unless already provided, it must include a detailed description of the incident, its severity and impact, the likely threat type or root cause, and applied and ongoing mitigation measures (Art. 14(4)(c) CRA).

The staged structure means that the first report will typically be based on an incomplete forensic investigation. Authorities may request intermediary reports on relevant status updates (Art. 14(6) CRA).

The ENISA SRP FAQ specify the data fields to be submitted for each of the reporting stages, distinguishing between the reporting of vulnerabilities and incidents:

6. Where must reports be submitted?

CRA notifications must be submitted through the SRP established under Art. 16 CRA. The notification is made through the electronic notification endpoint of the CSIRT designated as coordinator in the EU Member State where the manufacturer has its main establishment in the EU, and will be simultaneously accessible to ENISA unless particularly exceptional circumstances apply (Art. 14(7), Art. 16 CRA; ENISA SRP FAQ, Q1, Q8, Q20).

For this purpose, the manufacturer's main establishment is the Member State where decisions related to the cybersecurity of its products with digital elements are predominantly taken. If that Member State cannot be determined, the main establishment is the Member State where the manufacturer has the establishment with the highest number of employees in the EU (Art. 14(7) CRA). ENISA indicates that additional information, including the list of national CSIRTs designated as coordinators, will be provided at a later stage (ENISA SRP FAQ, Q18).

Manufacturers without a main establishment in the EU may have to submit notifications through the electronic notification endpoint of the CSIRT designated as coordinator in the Member State of the authorized representative, the importer, the distributor, or the EU Member State in which the highest number of users of the relevant products are located, depending on the circumstances (Art. 14(7) CRA).

While the SRP at ENISA is a single CRA reporting entry point, it is not currently expected to provide API-based submission. Manufacturers should therefore map who will have SRP access, who is authorized to submit, how product and legal input will be validated within the 24-hour and 72-hour windows, and how sensitivity markings will be escalated before submission (ENISA SRP FAQ, Q9, Q15, Q16, Q21).

7. Notification of product users

In addition to reporting to the CSIRT and ENISA through the SRP, the manufacturer must inform impacted users of an actively exploited vulnerability or severe incident and, where appropriate, all users (Art. 14(8) CRA).

The user notification must include information on the vulnerability or incident and, where necessary, any risk-mitigation and corrective measures that users can deploy to mitigate its impact. Where appropriate, this information should be provided in a structured, machine-readable format that is easily automatically processable (Art. 14(8) CRA).

In contrast to reporting to CSIRTs and ENISA, the CRA does not set a fixed timeline for user notifications. However, where the manufacturer fails to inform users in a “timely manner”, the notified CSIRT designated as coordinator may provide such information to users (Art. 14(8) CRA).

The user notification obligation is operationally sensitive. While overly narrow communication may leave users without necessary mitigation steps, overly broad or premature disclosure may increase exploitation risk, particularly where the vulnerability is not yet patched or where affected products are used in sensitive environments. The European Commission's draft CRA guidance indicates that user information should be handled in a risk-based manner and does not necessarily require indiscriminate public disclosure of technical details where this could increase cybersecurity risk.

8. Interplay with other reporting regimes

The CRA reporting obligation may apply in parallel with other legal and contractual reporting duties. The same underlying event may also need to be assessed under the GDPR, NIS2 Directive transposition laws, Digital Operational Resilience Act (DORA), sector-specific cybersecurity rules, product-safety obligations, customer contracts, coordinated vulnerability disclosure policies, and insurance notification requirements.

The SRP's "single" character is therefore limited. It is a single entry point for CRA reporting to the relevant CSIRT and ENISA; it does not consolidate or replace other incident, data breach, sectoral, contractual, or customer notification obligations. A single incident may therefore require several assessments with different thresholds, addressees, timelines, and content requirements.

To utilize existing reporting procedures and increase efficiency, CRA reporting should be integrated into wider legal and technical incident-response processes that enable parallel compliance with different reporting obligations, consistent factual positions, and timely escalation to the SRP filing function.

9. Enforcement implications

Non-compliance with Art. 14 CRA falls within the CRA's highest penalty tier. Once the CRA penalty framework applies, non-compliance with the Art. 14 reporting obligations may lead to administrative fines of up to EUR 15,000,000 or, for an undertaking, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher (Art. 64(2), Art. 71 CRA).

The CRA contains limitations for microenterprises, small enterprises, and open-source software stewards. In particular, administrative fines do not apply to manufacturers that qualify as microenterprises or small enterprises for failures to meet the 24-hour early warning deadline, or to infringements by open-source software stewards (Art. 64(10) CRA).

Even where a statutory fine risk is limited, operational risk remains. Late, incomplete, inconsistent, or poorly substantiated SRP submissions may affect market surveillance expectations, customer confidence, vulnerability coordination, contractual reporting, and the manufacturer's broader CRA compliance record.

10. Practical implications for manufacturers

Manufacturers only have approximately three months to prepare for compliance with the CRA reporting regime. The following steps should be implemented before 11 September 2026:

• Establish a CRA-relevant product inventory. The inventory should cover new and legacy products, software and hardware, embedded components, remote data processing solutions, supported versions, unsupported versions that remain in use, and products placed on the EU market before full CRA application.
• Identify the responsible legal entities. This is particularly important for group structures, co-development models, OEM and white-label arrangements, products distributed through multiple entities, and products containing third-party components.
• Map the relevant SRP reporting route. Determine the manufacturer's main establishment for Art. 14(7) CRA purposes, identify any fallback route for non-EU manufacturers, and monitor ENISA's publication of the list of national CSIRTs designated as coordinators.
• Prepare SRP onboarding. Monitor ENISA's access, registration, training, and dry-run materials expected in June 2026. Identify portal users, internal approval authorities, escalation contacts, and substitute submitters for out-of-hours reporting.
• Define reportability criteria under Art. 14 CRA. The criteria should distinguish actively exploited vulnerabilities from non-exploited vulnerabilities and severe incidents from lower-severity security events, while aligning with the internal awareness threshold and documentation standard. In a CRA project, the criteria can be determined on basis of practical test scenarios.
• Prepare reporting templates mapped to SRP fields. Templates should cover the early warning, 72-hour notification, and final-report stages for both actively exploited vulnerabilities and severe incidents, using the data fields identified in ENISA's SRP FAQ.
• Integrate CRA reporting into incident response. Security, product, legal, regulatory, communications, customer support, and management functions should know when and how they are involved, and who decides whether the Art. 14 reporting threshold has been met.
• Plan for internal automation, but not API submission. Companies may automate internal evidence gathering, case tracking, and approval workflows, but should not assume that SRP submissions can be made through an API at go-live of the SRP (see ENISA SRP FAQ, Q15).
• Build a confidentiality and sensitivity process. Incident teams should be able to assess whether notified information is sensitive, whether Art. 16(2) CRA may be relevant, what supporting facts are available, and who can approve sensitivity markings within the 72-hour window.
• Prepare user notification playbooks. These playbooks should address direct customer notifications, broader user advisories, public security advisories, mitigation instructions, security-update communications, machine-readable formats, and escalation where disclosure could increase exploitation risk.

Finally, manufacturers should continue monitoring ENISA materials and finalization of the Commission guidance before the 11 September 2026 go-live date.

Authored by Henrik Hanssen.