How to Comply with the 24-Hour Reporting Obligation for Exploited Vulnerabilities

What changed as of September 11, 2026, and why it is not NIS2

Regulation (EU) 2024/2847 lays down harmonised cybersecurity rules for products with digital elements, i.e. both hardware and software. It shall apply as a whole from December 11, 2027, but Article 14 on reporting shall apply as of September 11, 2026 (Regulation (EU) 2024/2847, Art. 71). Even earlier, from June 11, 2026, the chapter on conformity assessment bodies shall apply, but this only affects manufacturers indirectly.

For manufacturers, reporting under Article 14 is one of the key obligations that began to apply even before the full applicability of the Regulation. Therefore, a company cannot wait until December 2027. Yet, many manufacturers do not have the necessary process in place. It is also important to know that this obligation concerns the product itself, not how the company operates its own networks and systems.

This is precisely where the regime differs from the Czech Cybersecurity Act. The latter regulates the rights and obligations of persons in the field of ensuring cybersecurity, applies to persons established in the Czech Republic, implements the relevant European Union regulation, and builds on directly applicable European Union regulations (Section 1 of the Cybersecurity Act). The Act is built on the provision of a regulated service, whereas the Cyber Resilience Act imposes obligations based on the entity's role in relation to the product.

However, this does not mean that manufacturing companies stand outside NIS2. Among the sectors in which a service can be regulated, the Czech Cybersecurity Act explicitly includes the manufacturing industry (Section 4 of the Cybersecurity Act). A manufacturer under the Regulation can thus simultaneously be a provider of a regulated service. The new law is discussed in the text on the new Cybersecurity Act. A company under both regimes must separate them, as they have different addressees, different concepts, and different deadlines.

Am I a manufacturer if I put my name on someone else's product?

According to the Regulation, a manufacturer is not only someone who develops or manufactures the product themselves, but also someone who has had it designed, developed, or manufactured and offers it under their name or trademark, whether for payment, other monetization, or free of charge (Regulation (EU) 2024/2847, Art. 3 point 13). A company that sells someone else's device under its own brand therefore bears the obligations of a manufacturer, even if it has not written a single line of code in it.

An importer and distributor are considered manufacturers in two specific situations: if they place a product on the market under their name or trademark, or if they make a substantial modification to a product that is already on the market. In such cases, they are also subject to the reporting obligation under Article 14 (Art. 21 of the Regulation). Under the Regulation, the obligations of a manufacturer also apply to any other person who carries out a substantial modification and supplies the product to the market.

The contract with the original manufacturer should therefore determine who will submit the report and who will pass on information about the exploited vulnerability to whom without delay. However, the manufacturer's obligation arises directly from the Regulation, so it cannot generally be considered fulfilled simply by referring to the fact that the product is actually manufactured by someone else.

In practice, this means that a company must first clarify what role it actually plays. An electronics retailer placing its logo on a supplier's device, a manufacturing company integrating a control unit with its own software into its machine, or an integrator modifying someone else's product may all find themselves on the manufacturer's side in such an analysis, even if they do not feel like one at all.

What is an actively exploited vulnerability and when does the clock start ticking?

According to the Regulation, an actively exploited vulnerability is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner (Art. 3 point 42). Thus, the mere existence of a flaw or the fact that it is technically exploitable is not enough; there must be reliable evidence of its actual malicious exploitation. It is not a prerequisite that a security breach has already occurred for users. An incident with an impact on product security is a separate concept in the Regulation and is reported separately.

Conversely, a vulnerability discovered without malicious intent during authorized testing or good-faith security research does not meet the definition, as there is no malicious actor or unauthorized exploitation. Therefore, a routine finding by a security researcher that is not being exploited does not trigger the 24-hour reporting requirement. However, a company may report it voluntarily.

Beware of confusing concepts. The Czech Cybersecurity Act defines a vulnerability more broadly, as a weakness of an asset or security measure that can be exploited by a threat, and a cybersecurity incident as a breach of information security in cyberspace (Section 2(2) of the Cybersecurity Act). The Cyber Resilience Act only requires reporting of actively exploited vulnerabilities and severe incidents with an impact on product security, so the same event may trigger one regime and not the other.

The deadline starts from the moment the manufacturer becomes aware of the vulnerability, not from the moment the attacker exploited it. Therefore, internal organization is crucial: who in the company receives the report, who assesses whether it is an active exploitation, and who is authorized to submit the notification. If these roles are not determined in advance, the company will waste the first hours deciding who should make the decision.

Three reports, three deadlines, and where to report

The manufacturer shall submit an early warning without undue delay and in any event within 24 hours of becoming aware of the vulnerability, where applicable, indicating the Member States where the product is made available. This is followed by a vulnerability notification within 72 hours and a final report no later than 14 days after a corrective or mitigating measure is available (Regulation (EU) 2024/2847, Art. 14(2)).

For severe incidents that have an impact on product security, a similar 24-hour and 72-hour procedure applies, but the final report is submitted within one month of submitting the 72-hour incident notification (Art. 14(4)). The Regulation considers an incident to be severe if it adversely affects or has the potential to affect the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, or if it has led or has the potential to lead to the introduction or execution of malicious code in the product or in the user's systems. An example would be a situation where an attacker introduces malicious code into the channel through which the manufacturer issues security updates.

The notification is submitted simultaneously to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment (Art. 14(7)) and to ENISA, via the single reporting platform. Thus, the manufacturer submits the report once, and the platform forwards it. Official Czech information on registration and reporting via this platform is published by the National Cyber and Information Security Agency on its portal, which states, among other things, that an EU Login account is used.

Kromě povinného hlášení nařízení umožňuje, aby výrobci i jiné osoby dobrovolně oznámily jakoukoli zranitelnost produktu, kybernetické hrozby, které by mohly ovlivnit jeho rizikový profil, i významné události, které k incidentu téměř vedly. Dobrovolné hlášení lze využít tam, kde si firma není jistá, zda jde o aktivní zneužití; neznamená ale, že by tím odpadla povinnost hlásit, jakmile se zneužití potvrdí.

It is wise to arrange registration and access to the platform in advance, not only at the moment you need to submit a report. Indeed, with an increased volume of registration requests, user verification may take some time, and the deadline will be running in the meantime.

Does this also apply to a product we sold years ago?

Yes. The transitional provisions of the Regulation explicitly state that the obligations under Article 14 apply to all products with digital elements within the scope of the Regulation that were placed on the market before December 11, 2027 (Art. 69(3)). This is an exception to the general rule under which other requirements of the Regulation apply to older products only if they undergo a substantial modification after that date. Therefore, an older product is no reason not to submit a report.

For a company, this leads to an unpleasant conclusion: the list of products that need to be monitored includes not only new lines, but also devices and software that customers have been using for years. Particularly sensitive are products with a long lifespan, such as industrial control systems or network devices, where the manufacturer often does not know which version is deployed and where exactly. Therefore, the manufacturer needs records of what was sold, when, in which version, and to whom, in order to know where the exploited vulnerability might appear and whom to inform.

Furthermore, reporting to the authorities is not the only obligation. Upon identifying an actively exploited vulnerability or a severe incident, the manufacturer must inform the affected users of the product, or all users, and, if necessary, also about the risk mitigation and remediation measures they can take themselves (Art. 14(8)). This is an independent legal obligation, not just good practice, and if the manufacturer fails to fulfill it in time, the relevant CSIRT may inform the users itself. Therefore, communication with customers must be prepared just like the technical part.

How to set up the process before the phone rings

The first step is to designate responsible persons and their deputies. The deadline runs regardless of vacations, weekends, or holidays, so a single designated employee is not enough. A team of two or three people is advisable, where at least one can technically assess whether there is active exploitation, and one has the authority to submit the report.

The second step is to describe the decision-making process from the first report to the submission of the notification. This includes the sources through which information about a vulnerability can reach the company, criteria for assessing reliable evidence of exploitation, the method of recording the moment the company became aware of the vulnerability, and templates for early warnings and notifications so they do not have to be drafted from scratch.

Records deserve special attention. If it later turns out to be unclear when the company became aware of the vulnerability, timestamps will be decisive: the email with the first notification, the record of the technical evaluation, the confirmation of the report submission. A company that records these moments continuously will find it easier to prove that it met the deadline than a company that reconstructs them retrospectively from the memory of those involved.

The third step is to address contracts with component suppliers and partners who distribute or integrate the product. The supplier should be obliged to inform the manufacturer of vulnerabilities and incidents immediately, as the manufacturer cannot meet the 24-hour deadline if they learn about a bug in a third-party component with a week's delay. Liability for breach of such an obligation is governed by general contractual rules (Section 2913 of the Civil Code).

From December 11, 2027, when integrating third-party components, the manufacturer must exercise due diligence to ensure they do not compromise the product's cybersecurity, and if they discover a vulnerability in a component, they must inform the person who manufactures or maintains it (Art. 13(5) and (6) of the Regulation). According to the recitals of the Regulation, they should monitor, for example, whether the component receives regular security updates and has no registered vulnerabilities. For contracts, this means that the component supplier should share information in both directions, and the manufacturer should maintain an overview of what components their product contains, as without it, it is impossible to quickly determine whether the exploited bug affects their product.

The fourth step is to involve the company's management. Anyone who accepts the office of a member of an elected body undertakes to perform it with necessary loyalty as well as with the necessary knowledge and diligence (Section 159(1) of the Civil Code). How exactly this duty of due managerial care translates into the product's cyber risks depends on the circumstances, but management that has not discussed the reporting obligation at all may find it difficult to defend itself in a subsequent dispute.

This is also related to damages after an incident, which are analyzed in the text on liability for a cyber incident. Management should know who approves reports, what information about incidents reaches top management, and who is responsible for communication with customers.

The fifth step is to practice the entire procedure. A mock report on a Friday evening will show where communication gets stuck, who lacks access to the platform, and who lacks authorization. It is worth repeating the exercise with every change in the team or product portfolio, because a process that only works on paper will fail in a real incident.

Part of the preparation is also to clarify whether, in addition to reporting under the Regulation, the company also falls under the Cybersecurity Act or the critical infrastructure regime, as each has its own report recipients and deadlines. How to practically test the company's position in both regimes is described in the text Critical Infrastructure or NIS2?

Moreover, reporting is only the first component of a manufacturer's broader toolkit. The Regulation requires manufacturers (Annex I Part II points 1 and 5) to implement a coordinated vulnerability disclosure policy determining how individuals or entities can report vulnerabilities to them, and to document components contained in products, including by a software bill of materials (SBOM). These obligations will apply from December 11, 2027, but a company that takes them into account when building the reporting process will save on later rework.

How exactly to set up the process for a specific product depends on the role the company plays and how complex its supply chain is – which is why the Prague-based legal team at ARROWS always assesses this based on the specific manufacturer, not according to a universal template.

Risks of an Unaddressed Reporting Obligation

Summary

As of September 11, 2026, the manufacturer of a product with digital elements must report an actively exploited vulnerability within 24 hours of becoming aware of it. A manufacturer can also be a company that sells someone else's product under its own brand, the obligation explicitly applies to previously placed products, and it is a different regime from the Cybersecurity Act, although a single company can fall under both regimes simultaneously.

For the company's management, this leads to a clear task: determine whether the company is a manufacturer, designate specific people for reporting, and practice the procedure before it needs to be used for real. The 24-hour deadline leaves no room for improvisation, and the first hours decide whether the company will meet it.

The Prague-based legal team at ARROWS assesses the status of companies under the Cyber Resilience Regulation, sets up internal reporting processes, and amends contracts with suppliers and partners. Write to us at consultation@arws.cz or review our contracts and negotiations practice.