Help, I also have to report things under the CRA! But what exactly and with whom?

My colleague recently wrote that (malicious) hackers don't read laws, but legitimate organisations of course have to. Or at any rate they must comply with the law. And that means that legitimate organizations will very soon have to comply with several new obligations to report actively exploited vulnerabilities and severe (or significant) incidents.

Of course, reporting obligations under the GDPR for privacy breaches ('personal data breaches') have been in place for some time, but the Dutch Cybersecurity Act (‘Cyberbeveiligingswet’, the national implementation law of the NIS2 Directive), the Dutch Critical Entities Resilience Act (‘Wet weerbaarheid kritieke entiteiten’, which implements the CER Directive) and the Cyber Resilience Act (hereinafter also abbreviated as CRA) introduce new reporting obligations. In this blog you can read what must be reported when, under which law and to which authority. We start with the CRA and then explain the concurrence with the Dutch Cybersecurity Act and the Dutch Critical Entities Resilience Act.

What is the CRA about again?

Of course, we wrote about the CRA before (1, 2), but since its reporting obligations will apply from September 11, 2026, we will zoom in on that after a short refresh of memory. The CRA (Regulation (EU) 2024/2847) was adopted on 10 December 2024 and introduces essential cybersecurity requirements for virtually all products with digital elements offered on the European market. This goes beyond just hardware: it also includes stand-alone software, IoT devices, industrial control systems and individual components. The obligations will come into force in phases:

• 11 June 2026: the provisions on conformity assessment bodies (Chapter IV) have become applicable;

• 11 September 2026: the reporting obligations under Article 14 CRA will apply;

• 11 December 2027: the CRA becomes fully applicable, including the essential requirements and CE marking.

The fact that the reporting obligations are ahead of the rest of the regulation is no coincidence. The EU legislator wants to gain insight into actively exploited vulnerabilities as soon as possible, in order to allow for coordination at EU level. On 27 July 2026, new guidelines from the European Commission were published to help comply with the CRA on time. In 2025 the Dutch supervisory authority for CRA compliance (Rijksinspectie Digitale Infrastructuur, RDI) published an initial CRA Guide.

A closer look at the reporting obligations under Article 14 of the CRA

Article 14 of the CRA imposes two independent reporting obligations on manufacturers: one for actively exploited vulnerabilities and one for serious incidents with an impact on the safety of the product. Both reports must be made to both the designated Cyber Security Incident Response Team (CSIRT) of the Member State in question and to ENISA, viaa single reporting platform (SRP) to be set up by ENISA. (ENISA stands for European Network and Information Security Agency.)

2.1 Actively exploited vulnerabilities

An actively exploited vulnerability is when there is evidence that a malicious actor has exploited this vulnerability in a system, without the owner's consent. The reporting chain has three phases:

1. Early warning: within 24 hours of becoming aware. This first notification is concise: it must state which Member States are (suspected) affected by an actively exploited vulnerability.

2. Vulnerability notification: within 72 hours of becoming aware. This contains additional information about the nature of the vulnerability, the product(s) with digital elements that have been affected, any mitigating measures that the supplier itself takes and that users can take and how sensitive the provider thinks the data in the notification is.

3. Final report: within 14 days after a corrective or mitigating action (such as a security update or patch) is available. This includes the severity and impact of the vulnerability, available information about the malicious parties who have abused the vulnerability and the security update that has been made available or other measures taken.

2.2 Severe incidents impacting product security

In addition to vulnerabilities, manufacturers must also report serious incidents that affect the security of the product with digital elements and the data that is processed in it. The deadlines are identical (24 hours / 72 hours / 14 days after taking action), but the threshold is formulated differently: the incident must have (had) negative consequences for the product's ability to protect confidentiality, integrity or availability of data or functions. Now you would say that if a vulnerability is actively exploited, this will obviously also have negative consequences for the confidentiality, integrity or availability of data or functions. A reason to include an apparently double reporting obligation (or formulation) may be that 'actively abused vulnerability' refers to a vulnerability in a system that is actively exploited in general but not specifically in the supplier's product, while a 'serious incident' has an impact on the confidentiality, availability and/or integrity of the data processed in the product. Either way, if something turns out to be seriously wrong with security, it should be reported.

2.3 Information to Users

It is important not to forget the users. Without delay, and in any event after becoming aware of an actively exploited vulnerability or serious incident, the manufacturer must inform the users of the product and, where appropriate, instruct them on corrective measures that they can take themselves. This obligation runs parallel to the notifications to ENISA and the CSIRT.

Current state of play: ENISA and the single reporting platform (SRP)

The success of the notification obligations under Article 14 CRA stands or falls with a well-functioning reporting platform. ENISA is in charge of setting up and managing this platform under Article 16 of the CRA and is currently working on the technical and organisational set-up. In several stakeholder consultations and workshops in 2025, ENISA shared the conceptual design: a single front-end for manufacturers, where notifications are then routed via a decentralised back-end to the relevant national CSIRT and, where relevant, other Member States. This is in line with the design explicitly chosen by the EU legislator: ENISA does not act as a filter, but as a conduit that allows for coordination.

Delegated legislation was adopted on the possibility to postpone notification of actively exploited vulnerabilities and serious incidents if this is necessary to prevent that the notification and the information contained therein would lead to misuse.

The role of the NCSC

In the Netherlands, the NCSC (National Cyber Security Centre) is the designated CSIRT and therefore the first-line recipient of CRA reports. The NCSC has been preparing for a significant expansion of its range of tasks for some time: in addition to existing tasks under the previous national implementing law of the first NIS Directive, which now merges into the Dutch Cyber Security Act), the NCSC must receive and coordinate notifications under the CRA.

In practical terms, this means that manufacturers who fall under the CRA and are at the same time essential or important entities under the Dutch Cyber Security Act (implementing NIS 2) will have to deal with different but coherent reporting flows to the NCSC. It is up to the manufacturer to clearly state internally which notification falls under which regime. The following information may be helpful in this regard.

Concurrence with the Cybersecurity Act and the Critical Entities Resilience Act

On 15 August 2026, the Cybersecurity Act (implementation of NIS2) and the Resilience of Critical Entities Act (implementation of CER) will enter into force. This will create, within a few weeks, a layered system of reporting obligations:

The regimes partly overlap, but each has its own focus. The Cbw focuses on the services of the entity; the Wwke on the continuity of entities that have been specifically designated as critical to Dutch society; the CRA on the product itself. A manufacturer that is also an essential entity (e.g. a supplier of industrial control systems to the energy sector) may face obligations under multiple regimes in the event of a single incident. The time limits, 24 hours for the early warning under both NIS2 and CRA, then coincide, but the content and the addressee can (subtly) differ.

What to do? Five recommendations

Manufacturers who offer products with digital elements on the European market would be wise to take the following steps now:

1. Map out the application range. Make an inventory of which of your products are covered by the CRA and whether they include "important" or "critical" products within the meaning of Annexes III and IV. These products are not only subject to stricter conformity procedures (which take effect later), but incidents in general may also be more serious, making it more important to report and take measures in a timely manner.

2. Set up an internal reporting process. The 24-hour period is short. Provide clear escalation lines between product teams, security, legal and communication, and document when there is "knowledge".

3. Match the CRA signal flow to NIS2/CER. Determine which regime applies for each scenario and avoid duplication of work by setting up one integrated incident response process.

4. Follow the guidance of ENISA, the NCSC and RDI. In the coming months, final implementing acts, technical specifications of the reporting platform and Dutch guidance will be published. Include these in your policy.

5. Document and train. Make sure employees know how to recognize a potentially reportable incident or an actively exploited vulnerability, and practice the process with tabletop exercises.

In conclusion

With the phased entry into force of the CRA, combined with the Cbw and the Wwke, a fundamentally new legal framework for cybersecurity in the Netherlands and the EU will be created in the second half of 2026. Before 15 August, you are expected to know whether you fall under the Cybersecurity Act and comply with the reporting obligations if so. From 11 September, this also applies to the CRA.

Want to know what NIS2 mean for your organisation and how to meet the requirements? Our NIS2-compliance training provides practical tools to translate the requirements to your organisation.