How to Comply with the 24-Hour Reporting Obligation for Exploited Vulnerabilities (Cyber Resilience Act)

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

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

For manufacturers, reporting under Article 14 is one of the key obligations that became applicable 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 under Czech legislation. The Act 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 upon 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. The Czech Act under Czech legislation explicitly includes the manufacturing industry among the sectors in which a service can be regulated (Section 4 of the Cybersecurity Act). A manufacturer under the Regulation can thus simultaneously be a provider of a regulated service. The new act is discussed in our article on the new Cybersecurity Act. A company subject to 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 the product designed, developed, or manufactured, and markets 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 a third-party device under its own brand therefore carries the obligations of a manufacturer, even if it has not written a single line of code.

An importer and a distributor are considered manufacturers in two specific situations: if they place a product on the market under their name or trademark, or if they carry out a substantial modification of a product 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.

Therefore, the contract with the original manufacturer should 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 settled merely 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 a third-party product may all find themselves classified as a manufacturer 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 these concepts. The Czech Cybersecurity Act under Czech legislation 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 affecting product security, so the same event might trigger one regime but not the other.

The deadline begins from the moment the manufacturer becomes aware of the vulnerability, not from the moment the attacker exploited it. Internal organization is therefore decisive: who in the company receives the report, who assesses whether it is an active exploitation, and who is authorized to submit the report. If these roles are not predetermined, the company will waste the first crucial 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, indicating, where applicable, 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 becomes 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 user systems. An example would be an attacker introducing malicious code into the channel through which the manufacturer releases security updates.

The notification is submitted simultaneously to the CSIRT designated as coordinator and to ENISA, via a single reporting platform. Thus, the manufacturer submits the report once, and the platform forwards it. Official Czech information on registration and reporting through this platform is published by the National Cyber and Information Security Agency (NÚKIB) on its portal, which mentions, among other things, that an EU Login account is used.

In addition to mandatory reporting, the Regulation allows manufacturers and other persons to voluntarily notify any product vulnerability, cyber threats that could affect its risk profile, and near-misses. Voluntary reporting can be used when a company is unsure whether there is active exploitation; however, it does not waive the obligation to report once the exploitation is confirmed.

Practical tip: it is wise to handle registration and access to the platform in advance, not only when you need to submit a report. With an increased volume of registration requests, user verification can take some time, while the deadline is already running.

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 only apply to older products if they undergo a substantial modification after that date. Therefore, an older product is no reason not to submit a report.

For companies, this leads to an unpleasant conclusion: the list of products to monitor includes not only new lines, but also hardware and software that customers have been using for years. Particularly sensitive are products with a long lifecycle, such as industrial control systems or network equipment, 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 an exploited flaw might appear and who 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 potentially all users, and, where necessary, about the risk mitigation and corrective 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. Communication with customers must therefore be prepared just as thoroughly as 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 holidays, weekends, or vacations, so a single designated employee is not enough. It is worth having a team of two or three people, 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 vulnerability information can reach the company, the 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 that they do not have to be drafted from scratch.

Special attention should be paid to records. 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 alert, the technical evaluation log, the confirmation of report submission. A company that records these moments continuously will find it much easier to prove compliance with the deadline than one reconstructing 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 flaw 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).

According to the recitals of the Regulation, when integrating third-party components, the manufacturer should exercise due diligence to ensure that the component receives regular security updates and has no registered vulnerabilities, and if they discover a vulnerability in the component, they should inform the person who manufactures or maintains it. 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, they cannot quickly determine whether an exploited flaw affects their product.

The fourth step is to involve the company's management. Anyone who accepts the position of a member of an elected body undertakes to perform it with necessary loyalty and 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 a management team that has not discussed the reporting obligation at all may find it difficult to defend itself in a later dispute.

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

The fifth step is to run a dry run of the entire process. 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.

At the same time, it is good to consider how insurance coverage approaches such events, which is discussed in our article on cyber risk insurance.

Furthermore, reporting is only the first component of a manufacturer's broader toolkit. According to the recitals of the Regulation, manufacturers are to implement a coordinated vulnerability disclosure policy, which determines how individuals or entities can report vulnerabilities to them, and they must document the components contained in the products, for example, with a software bill of materials (SBOM). These obligations will apply later, but a company that takes them into account when building its reporting process will save itself from later redesigns.

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 Czech legal team at ARROWS law firm always assesses this based on the specific manufacturer, rather than using a one-size-fits-all 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 a third-party product under its own brand; the obligation explicitly applies to previously introduced products as well, and it is a different regime from the Cybersecurity Act, even though a single company can fall under both regimes simultaneously.

For company 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 Czech legal team at ARROWS law firm assesses the status of companies under the Cyber Resilience Act, sets up internal reporting processes, and adjusts contracts with suppliers and partners. Write to us at consultation@arws.cz or explore our contracts and negotiations practice.