Almost every company knows reporting duties: from occupational safety, from accounting, from data protection. The duty that applies to manufacturers of products with digital elements from 11 September 2026 (Regulation 2024/2847) differs in one respect. It runs against a clock, and the clock starts with awareness, not with a decision. Anyone who learns that a vulnerability in their own product is being actively exploited has 24 hours (Regulation 2024/2847) until the first report - regardless of whether the case is understood, the scope is clear or management can be reached. This article describes the chain itself: who reports, which body the report goes to, what has to happen in the first 24 hours, which deadlines follow and which records make the case defensible later on.
Key takeaways
- The clock runs from awareness. Article 14 requires the early warning within 24 hours (Regulation 2024/2847), counted from the moment the manufacturer learns of the actively exploited vulnerability. Internal confirmation is not a separate starting point.
- The report has two addressees. It goes simultaneously to the CSIRT designated as coordinator and to ENISA (Regulation 2024/2847). In Germany the Federal Office for Information Security is the national coordinator (BSI Act).
- Two further dates follow the early warning: 72 hours for the notification with a first assessment and 14 days for the final report on vulnerabilities (Regulation 2024/2847).
- The operator duties under NIS2 are a second, separate chain (Directive 2022/2555). The deadlines look similar, the triggers and recipients differ - a company holding both roles needs two routes with one shared intake.
- The process is decided before the incident: a named role with a deputy, prepared text modules, a log that records the moment of awareness, and a dry run that walks the chain through once without time pressure.
The deadline starts with awareness, not with a decision
Article 14 of the regulation requires the early warning without undue delay and in any event within 24 hours of the manufacturer becoming aware (Regulation 2024/2847). The sentence contains two statements that come apart in practice. The first is the deadline. The second is the starting point: awareness, not confirmation, not sign-off, not the completion of the analysis. In many companies this very starting point is recorded nowhere. A customer message lands in the sales inbox, a note from a security forum reaches a developer at the weekend, a monitoring system triggers during the night. If nobody writes down when that information first entered the building, compliance with the deadline can be neither evidenced nor disproved afterwards.
Not every vulnerability triggers the report. Article 14 attaches to the actively exploited vulnerability - that is, to a case in which somebody is actually using the gap, and not to the mere existence of a defect in the source code (Regulation 2024/2847). Alongside it stands a second trigger: a severe security incident that has an impact on the security of the product. Both triggers are matters of judgement, and both are judged under time pressure. Anyone who makes this decision only in the emergency loses hours on the question of whether a report is due at all. A short description agreed in advance works better: which observation counts as an indication of exploitation, who decides on it, and what happens if the situation stays unclear.
In practice the start of the deadline hangs on the intake point, and most companies have several: support inbox, telephone, service portal, monitoring, supplier information. Each of these points can start the clock, and none of them is staffed around the clock. Companies that monitor their interfaces systematically get technical anomalies on the table earlier; anyone who has once worked through the failure of an interface in an orderly way knows the difference between a malfunction and a security-relevant event. For the reporting process one simple addition is enough at first: every incoming piece of security information receives a time stamp and a case number immediately, before anybody assesses it.
Why the situation is not theoretical
Two reporting chains that do not overlap
Many companies have built a reporting route in recent years because they fall under the NIS2 directive as an entity or because a client asked for it. That route does not carry the manufacturer duty from the Cyber Resilience Act, because it hangs on a different role. NIS2 obliges operators of essential and important entities to report significant security incidents in their own operations (Directive 2022/2555). The Cyber Resilience Act obliges manufacturers to report vulnerabilities and incidents in their products - that is, in something that sits at the customer site and keeps running there. What the operator side means for smaller companies is set out in the article on NIS2 and mid-size companies.
In terms of timing, the two duties sit close together. The Cyber Resilience Act entered into force on 10 December 2024 (European Commission); the main obligations apply from 11 December 2027, whereas the reporting obligations apply from 11 September 2026 (Regulation 2024/2847). One transitional rule is easily overlooked here: the obligations in Article 14 also apply to products placed on the market before 11 December 2027 (Regulation 2024/2847). A legacy product from 2023 that is still working in the field therefore falls under the reporting duty, even though it does not have to meet the remaining requirements of the regulation.
| Feature | Article 14 Cyber Resilience Act | Article 23 NIS2 |
|---|---|---|
| Who reports | manufacturer of a product with digital elements | operator of essential and important entities |
| Trigger | actively exploited vulnerability or severe security incident in the product | significant security incident in the entity itself |
| First deadline | 24-hour early warning (Regulation 2024/2847) | 24-hour early warning (Directive 2022/2555) |
| Second deadline | 72-hour notification (Regulation 2024/2847) | 72-hour notification (Directive 2022/2555) |
| Closure | 14 days after the corrective measure, one month for incidents | one month after the notification to the CSIRT |
| Recipients | coordinator CSIRT and ENISA simultaneously | CSIRT or the nationally competent body |
| Application | from 11 September 2026 in all member states | via national transposition, in Germany the BSI Act |
For day-to-day operations this does not necessarily mean two separate organisations. A shared intake with a switch works well: every piece of security information is first sorted by whether it concerns the company itself or a delivered product. Only then does the respective sequence take over, with its own recipients, its own forms and its own documentation. Anyone who presses both routes into a single form ends up losing time on the question of which field applies to which case - and that time is missing exactly where the deadline is shortest.
Who reports to whom: the stations of the chain
The first station is the CSIRT designated as coordinator. The role comes from NIS2: each member state designates one of its CSIRTs as coordinator for the purposes of coordinated vulnerability disclosure (Directive 2022/2555). In Germany the legislator has assigned this task expressly to the Federal Office for Information Security; the statute records that the Federal Office is the national coordinator for the purposes of coordinated vulnerability disclosure (BSI Act). For the manufacturer this means a fixed addressee, one that should be known before the emergency and recorded with its contact route in the procedural description.
The second station is ENISA. Article 14 requires the report to go simultaneously to the coordinator CSIRT and to the agency (Regulation 2024/2847) - not one after the other and not as an either-or. So that this does not turn into a duplicated administrative act, ENISA is setting up a single reporting platform through which both the reports under Article 14 and voluntary reports are submitted (Regulation 2024/2847). Anyone still looking for access to that platform while the 24 hours are running has not prepared the process. Credentials, contacts and a second authorised person belong in the same place as the other emergency contacts.
The third station sits inside the company, and it is the most fragile. A reporting duty with a 24-hour deadline needs a named person, a named deputy and access that works even when the named person is on holiday. This is exactly where unclear responsibilities for accounts and permissions take their toll; how to put that in order is described in the article on account access when staff join and leave. Without that foundation the chain stalls at its very first station, and the deadline keeps running all the same.
Reporting responsibility
One named person decides on submitting the early warning and sends it. The role hangs on a function, not on a name in the holiday calendar, and has a deputy with equal authorisation.
Technical assessment
Development and operations establish which product releases are affected, which customers use them and whether exploitation is discernible. The result goes into the notification after 72 hours as a short assessment.
Customer communication
If users have to be informed about the incident and possible remedial measures, agreed texts and a maintained distribution list are needed. Sales and service work from the same template here.
Management
Management is informed but does not hold up the sequence. A report within 24 hours cannot carry an approval chain with three signatures; the mandate is granted beforehand and not negotiated during the incident.
Documentation
The moment of awareness, the assessment made, the sender, the recipients and the content of every report are recorded continuously. That log is later the only evidence that the deadlines were met.
Remedy and correction
Technical remediation runs alongside the report on its own schedule. Only once a corrective or mitigating measure is available does the deadline for the final report start to run.
The first 24 hours step by step
The sequence of the first 24 hours can be laid down in advance, because it has little to do with the specific case. What varies from case to case is the technical assessment; what stays the same is the order, the responsibility and the record. The following five steps are deliberately short. A sequence that cannot be taken in within a minute under pressure gets bypassed in the emergency - and a bypassed sequence is worse than none at all, because everyone was relying on it.
One note in advance: the early warning is not a complete analysis. For this first report Article 14 essentially requires the statement that an actively exploited vulnerability exists, together with the member states in whose territory the product has, to the knowledge of the manufacturer, been made available (Regulation 2024/2847). Anyone who waits until cause and scope are clear is confusing the early warning with the notification after 72 hours - and overruns the shorter of the two deadlines in doing so.
Step 1: record the intake
The information receives a time stamp, a source and a case number before anybody assesses it. This moment is the start of the deadline and cannot be reconstructed later if it was not noted straight away.
Step 2: check the trigger
The named person decides, using the criteria agreed in advance, whether an actively exploited vulnerability or a severe security incident exists. If the situation stays unclear, the assessment is documented with reasons and reviewed again a short while later.
Step 3: narrow down what is affected
Development and operations determine the affected product releases and the countries in which they were made available. A maintained bill of materials for the components used shortens this step from hours to minutes.
Step 4: submit the early warning
The report goes through the designated platform to the coordinator CSIRT and to ENISA at the same time. The text module already exists; product, timing, affected member states and the state of knowledge are added.
Step 5: secure the evidence
Confirmation, dispatch time and content of the report are filed with the case. Only then is the step complete, because a submitted report without a record is, in case of doubt, an unsubmitted report.
The information receives a time stamp, a source and a case number before anybody assesses it. This moment is the start of the deadline and cannot be reconstructed later if it was not noted straight away.
The named person decides, using the criteria agreed in advance, whether an actively exploited vulnerability or a severe security incident exists. If the situation stays unclear, the assessment is documented with reasons and reviewed again a short while later.
Development and operations determine the affected product releases and the countries in which they were made available. A maintained bill of materials for the components used shortens this step from hours to minutes.
The report goes through the designated platform to the coordinator CSIRT and to ENISA at the same time. The text module already exists; product, timing, affected member states and the state of knowledge are added.
Confirmation, dispatch time and content of the report are filed with the case. Only then is the step complete, because a submitted report without a record is, in case of doubt, an unsubmitted report.
Two points decide whether this sequence holds. The first is the sign-off: if the early warning needs a signature, the route to it has to be mapped digitally and with a deputy - the pattern for that is described in the article on digitising approval workflows. The second is access to its own records. If the incident concerns its own infrastructure, the bill of materials, the contact list and the text modules may sit on a system that is currently unavailable. That is why backups that hold up in an emergency are part of the reporting process and not a separate project.
What is due after 72 hours and what after 14 days
The actual notification follows the early warning. It is due within 72 hours of becoming aware and contains general information about the product, the nature of the exploitation and the corrective or mitigating measures taken (Regulation 2024/2847). After that the two strands part ways. For an actively exploited vulnerability, a final report has to be submitted at the latest 14 days after a corrective or mitigating measure is available (Regulation 2024/2847). For a severe security incident, one month after the notification applies instead (Regulation 2024/2847). Anyone who keeps both dates in a single line regularly misses the shorter one.
Case: CRA-2026-0001
Product: control module SM-4 (releases 2.1 to 3.4)
T+0h00 awareness (support inbox, time stamp in the case)
T+0h20 trigger checked: actively exploited vulnerability
T+3h00 affected releases and member states narrowed down
T+6h00 early warning to coordinator CSIRT and ENISA -> deadline 24 h
T+40h00 corrective measure in test
T+58h00 notification with assessment and remedy -> deadline 72 h
T+96h00 correction available, users informed
T+14d final report submitted -> deadline 14 days
Deputy: named person B from T+8h00
Filing: case file, log, dispatch recordsThe plan looks trivial until it is filled in for the first time. Then it becomes apparent that the time of awareness is unclear, that nobody knows exactly which product releases are running at the customer site, and that the text modules are missing. That is precisely what a dry run is for. The deadlines themselves are the simplest quantity in this calculation: they are fixed and can be entered as dates in the case. The harder question is who delivers the technical assessment between the early warning and the notification - and what happens if that person is currently on site with a customer.
User information is a separate strand
Alongside the report to the competent bodies there is a second duty that often gets lost in day-to-day work. After becoming aware of an actively exploited vulnerability or a severe security incident, the manufacturer informs the affected users of the product about the incident and, where necessary, about mitigating and corrective measures that the users can take themselves (Regulation 2024/2847). This is not a press release but targeted information for the people who operate the product. It presupposes that the manufacturer knows who runs its products - and that this list is maintained.
In practice this information runs through the same channel as complaints and service requests, and it produces the same backlog: follow-up questions, requests for appointments, uncertainty. Companies that already handle complaints digitally have the advantage that every response hangs on a case and does not disappear into individual inboxes. For the reporting process this means: user information gets its own template, its own distribution list and its own follow-up. Mixing it with the report to the competent body delays both.
The penalty framework names Article 14 expressly
These figures are no reason for alarm, but they do put the effort into perspective. A reporting process with a named role, a deputy, text modules and a log costs a manageable part of a working week to set up and little maintenance afterwards. It is therefore considerably cheaper than the alternative of improvising in the emergency - and it has the advantage over improvisation that it can be evidenced after the fact.
What the reporting process needs in documentation
A report is a time-critical procedure, and with time-critical procedures the record is what counts in the end. The regulation prescribes no particular form, but it presupposes that the manufacturer can set out the moment of awareness, the content of the reports and the measures taken. Anyone who has already written process documentation for audits knows the structure: purpose, responsibility, sequence, systems used, retention. The reporting process is one more chapter in it and needs no separate system of its own. We support the process documentation when the sequence is lived but written down nowhere.
- Time and source of awareness, with a time stamp from the system rather than from memory
- Reasons for the classification as an actively exploited vulnerability or a severe security incident
- Affected product releases, serial numbers or delivery batches and the countries of supply
- Wording and dispatch time of the early warning, notification, interim report and final report
- Acknowledgements of receipt and every response from the coordinator CSIRT
- Content, distribution list and timing of the user information
- Corrective and mitigating measures taken, with the date of availability
The second part of the documentation concerns not the individual incident but the knowledge of how the product is built. Which component sits in which release, who integrated it, why was a version not updated? In many companies this knowledge sits in individual heads, and that is exactly where it is hardest to reach in a reporting case. How to retain company knowledge before people leave is therefore not a soft topic but a precondition for the 24-hour deadline.
One log beats ten declarations of intent
Voluntary reports and the dry run
The regulation opens a second route: manufacturers as well as other natural or legal persons may voluntarily report any vulnerability contained in a product with digital elements, as well as cyber threats, to a CSIRT designated as coordinator or to ENISA (Regulation 2024/2847). For a company this is interesting for two reasons. First, it provides an orderly route for cases below the mandatory threshold. Second, the sequence can be walked through once on such a case without time pressure. Anyone who has taken the route once loses no more time in the emergency on access, form fields and the question of who signs.
- Name the role and the deputy in writing, with availability outside office hours
- Record the criteria for the trigger on one page and agree them with development
- Bring the bill of materials per product release and the customer distribution list up to date
- Prepare text modules for the early warning, notification, final report and user information
- Run a dry run against the clock and feed the measured times back into the sequence
A reporting process that is used for the first time during the incident is not a process but a hope. The 24 hours then go on searching rather than on reporting.
The reporting process is the visible part of a larger task. Behind it stand the usual questions of product security: which interfaces does the product expose, how are they secured, who updates the components in use? The article on security for interfaces covers that level; in ongoing operations and maintenance the topic then becomes updates, monitoring and records. If you are unsure whether your products fall under Article 14 and what the sequence would have to look like in your case, we will clarify that in a conversation based on your product list.
Sources and Studies
Related Articles
Packaging reporting driven by the item master
Which field is missing on the item, how packaging weights per variant and shipping carton are maintained, and how delivery note quantities become a defensible reported tonnage per material type.
Account Access When Staff Join and Leave the Company
How access is ready on the first working day and reliably ends after someone leaves: taking stock, roles, a trigger from the HR system, annual review.
Backups that hold up: copies, distance and a proven way back
Several copies, one off site, one without a permanent connection: how firms set recovery time and tolerable data loss, and how to test restores for real.