11.08.2026

CyberSec Update#32: Vulnerability Reporting Under CRA

One Month Until the First CRA Reporting Obligations Take Effect

NIS2 and the amendment to Poland’s National Cybersecurity System Act have already entered mainstream legal awareness. Unfortunately, the same cannot yet be said about another important piece of cybersecurity legislation, namely the European Cyber Resilience Act (CRA). Meanwhile, some of its obligations will begin to apply as early as September.

Reporting Actively Exploited Vulnerabilities and Significant Incidents

September 2026 will mark the first real test of organisations’ readiness for the Cyber Resilience Act. Although most CRA obligations will not apply until 11 December 2027, one important requirement comes much sooner.

From 11 September 2026, manufacturers of products with digital elements will be required to report actively exploited vulnerabilities and significant incidents affecting the security of those products.

This is not an obligation that can be fulfilled by simply submitting a form after the fact. In practice, the key question will be whether a manufacturer can quickly determine the nature of the issue, whether the vulnerability is being actively exploited, which product versions are affected, and who is responsible for making the reporting decision.

Why Is This Obligation So Important?

The CRA is a product-focused regulation. Its objective is to reduce vulnerabilities in products with digital elements and to ensure that cybersecurity is considered throughout the entire product lifecycle, rather than only when a problem emerges.

The September reporting obligation is therefore much more than a formality. It is the first element of the CRA that will require manufacturers to take concrete operational action. If a vulnerability is being actively exploited, the clock starts ticking. Manufacturers cannot afford to start asking who is responsible for analysing the report, where the component inventory is located, how affected product versions can be identified, or who should contact the relevant authorities.

If an organisation spends the first hours after receiving a report figuring out who is responsible for analysis, decision-making and communication, it is a clear sign that its CRA reporting process exists only on paper.

What Must Be Reported?

The CRA covers two categories of events that will become reportable from 11 September 2026.

Actively Exploited Vulnerabilities

Not every vulnerability discovered in a product is subject to reporting. The key issue is whether there is credible evidence that the vulnerability has been exploited by an unauthorised actor.

Significant Incidents Affecting Product Security

This may include incidents affecting the confidentiality, integrity, authenticity or availability of product data or functions. It also includes incidents that may lead to the introduction of malicious code into the product or users’ systems.

When Do Reporting Deadlines Start?

Under the CRA reporting framework, the critical point in time is when the manufacturer becomes aware of the event. From that moment, the following deadlines apply:

  • 24 hours to submit an early warning notification;
  • 72 hours to submit a more detailed incident report;
  • 14 days to submit the final report in the case of an actively exploited vulnerability;
  • 1 month to submit the final report in the case of a significant incident.

This means that within the first few hours, organisations must determine the basic facts: which product is affected, whether the vulnerability is actively exploited, what impact it may have on users, and whether a report must be initiated.

What Cannot Be Replaced by an NIS2 Incident Procedure?

Many organisations may naturally seek to rely on existing incident response procedures developed for NIS2 compliance. However, the CRA requires an additional question to be answered: does the issue affect the security of a product that has been placed on the market?

This changes the perspective entirely. Organisations must be able to connect a report to a specific product version, component, library, module, firmware version or update mechanism.

For that reason, manufacturers should supplement their NIS2 processes with a product-centred approach, particularly in relation to vulnerability handling, component management, coordinated vulnerability disclosure (CVD) procedures and CRA reporting workflows.

What Should Manufacturers Have Ready Before 11 September?

One month before the reporting obligation enters into force, a minimum level of readiness should include:

  • a map of products potentially covered by the CRA, including designated product owners within the organisation;
  • a vulnerability triage procedure allowing the organisation to determine whether the report concerns a product, whether the vulnerability is actively exploited, which versions are affected and whether reporting is required;
  • a channel for receiving vulnerability reports, such as a dedicated security inbox, reporting form or another monitored communication channel integrated into the decision-making process;
  • an inventory of components, libraries and modules, enabling rapid assessment of whether a reported vulnerability affects a product;
  • templates for reports and communications, avoiding the need to create content from scratch during a crisis.

What Should Be Done Now?

The coming weeks should be used to conduct a practical readiness test. A useful exercise would be to simulate a scenario in which a manufacturer receives information about a vulnerability affecting a component used in multiple versions of a product, together with indications that the vulnerability is already being exploited.

The organisation should verify whether it can answer the following questions within a single day:

  • Who receives the report?
  • Who performs the technical verification of the vulnerability?
  • Who identifies the affected products and versions?
  • Who assesses whether the vulnerability is actively exploited?
  • Who decides whether reporting is required?
  • Who communicates with users?
  • Which evidence is documented and retained?

If the answers are not immediately clear, those gaps should be addressed as a priority.

Summary

11 September 2026 will not mark the full application of all CRA obligations. It will, however, signify the beginning of a very specific reporting regime. Manufacturers of products with digital elements must be prepared to rapidly report actively exploited vulnerabilities and significant incidents affecting product security.

This obligation should not be viewed as a simple extension of existing incident response procedures. The CRA requires organisations to look at security through the lens of the product itself, its components, versions, users and lifecycle.

In the first hours after receiving a report, there should be no room for uncertainty about responsibilities and decision-making. CRA reporting requires clearly defined roles, established inputs and a documented escalation path long before an incident occurs. This readiness will distinguish organisations that are prepared from those that begin searching for someone to take charge only after the 24-hour reporting clock has already started to run.

1 … 63 64 65

Newsletter

Want to stay up to date?
Subscribe to our newsletter.

By entering your e-mail address above and clicking ‘Subscribe!’ you declare that you have read and accept the Terms of Service and subscribe to the newsletter, i.e. information on legal topics, including information on important legal events, legislative changes and the Law Firm's activities, services and products, via e-mail communication.

The controller of your personal data is KWKR Konieczny Wierzbicki i Partnerzy S.K.A. with its registered office in Kraków, Kącik 4 Street, 30-549 Kraków. Your data will be processed in order to provide the newsletter service and thus send commercial and marketing information to the e-mail address provided, in accordance with the Privacy Policy and the Terms of Service. For more information on the principles of personal data processing, including your rights, please see the Privacy Policy.

Please wait...

Thank you for sign up!