Use case
Reporting a vulnerability under the Cyber Resilience Act: a workflow from the first report to the final report that keeps to the clock.
A manufacturer of controllers for ventilation and air-conditioning systems, around 300 employees, 40,000 devices in the field, firmware with remote maintenance. Tuesday, 16:40: a system integrator writes to support that a script is circulating in a forum which opens the controller's web interface without a login, and that it has already been used at one of his customers. From this email, the clock of the Cyber Resilience Act is running: 24 hours to the early warning, 72 hours to the notification, and the customers with exactly this firmware must be the first to know. Anyone who opens a spreadsheet for this on Wednesday morning is too late. We build the software your team uses to meet this duty, from the incoming report to the final report: the workflow that starts at 16:41 on Tuesday. Not the legal advice, and not the notification on your behalf; the decisions stay with you.
Duty
What the law requires
The regulation's reporting duties have applied since 11 September 2026, including for products already in the field. The remaining manufacturer obligations follow in December 2027.
| Legal basis | Regulation (EU) 2024/2847, Cyber Resilience Act (CRA), Article 14; user information Article 14(8); transition Article 69(3) |
|---|---|
| Who is affected | Manufacturers of products with digital elements: controllers, inverters, building services equipment, connected devices, software and apps made available commercially in the EU. Areas with their own rules, such as medical devices and vehicles, are excluded. |
| Trigger | An actively exploited vulnerability in your own product or a severe security incident affecting the security of the product. Your own test findings and mere suspicion do not trigger the duty. |
| Deadlines | Early warning within 24 hours of becoming aware, notification within 72 hours, final report for vulnerabilities no later than 14 days after the corrective measure is available, for incidents one month after the 72-hour notification |
| Recipient and channel | The computer security incident response team designated as coordinator (CSIRT, in Germany at the Federal Office for Information Security, BSI) and the EU Agency for Cybersecurity (ENISA), simultaneously via ENISA's single reporting platform |
| User information | Affected users must be informed about the vulnerability and about corrective and risk-mitigating measures. If this does not happen, the CSIRT may inform the users itself. |
| Components | Vulnerabilities in bought-in components must be reported to their manufacturers; they only have to be reported to the authority if they are actively exploited in your own product. |
| Fine | Up to €15 million or 2.5 percent of worldwide annual turnover (Article 64(2)), applicable from 11 December 2027. Until then, the duty takes effect through supply chains, tenders and contracts. |
| Legal position as of | October 2026. We build the workflow; the legal assessment of whether a case must be reported stays with your legal department or law firm. |
Preparation
Until the workflow is in place
The duty already applies. You need these seven things in any case, with or without us; they are also the basis of the analysis.
- A list of your products with digital elements, with the firmware and software versions in the field for each product.
- The installed base: which customer runs which devices with which version, brought together from ERP, CRM and remote maintenance.
- An incoming channel for security researchers and partners that does not end up in a shared inbox.
- Classification criteria in your own words: what counts at your company as an actively exploited vulnerability, and what as a finding that does not have to be reported.
- Templates for the early warning, notification, customer information and security advisory, in your customers' languages.
- Responsibilities with deputies: who classifies, who approves, who talks to the CSIRT, including at the weekend.
- A trial run with a made-up case before the first real one arrives.
Your law firm or legal department sits at the table on the second day of the analysis, when the criteria are drawn up. If you do not have one with experience of the regulation, we can name law firms our customers work with. What the duty requires in detail is set out in the article Cyber Resilience Act: the reporting duty since September 2026.
Clock
The workflow, hour by hour
The tool takes in the report, classifies it, starts the clock, prepares every notification and lets nothing go out that has not been approved. The times are those of the regulation; hour zero is the moment the report reaches you.
- Minute 0
The report arrives, whatever the channel
An email to support, a form for security researchers, a report from a partner, an entry from your own monitoring or a notice from the component manufacturer: every incoming report becomes a case. The workflow reads the text, extracts the product, firmware version, described attack path and evidence, and searches your software bill of materials (SBOM) for the products and versions that contain the component named. Attachments such as scripts or log extracts are filed, not executed.
- Hour 1
Classification with a proposal and reasons
The workflow proposes whether this is an actively exploited vulnerability, a severe incident or a finding that does not have to be reported, and gives its reasons with the relevant passages of the report and the criteria of the regulation. Your product security officer confirms or changes the classification. The deadline clock has been running since the report came in; the confirmation does not change that, it only determines which deadlines apply.
- by hour 24
Early warning to the CSIRT and ENISA
The case produces the draft early warning with the mandatory details: manufacturer, product, versions, type of notification, the member states in which the product is made available, a note on possible cross-border impact. The clock sends reminders after eight, sixteen and twenty hours and escalates to management if nobody has approved it. After approval, the notification is entered in the platform; the acknowledgement of receipt goes into the log with a timestamp.
- by hour 24
First wave of the cascade
In parallel, informing those affected begins, in stages according to risk. From your installed base, the workflow identifies the customers running exactly the affected versions and prepares the emails and calls of the first wave: what has happened, which devices are affected, what the customer can do now, such as blocking remote access or isolating a network segment. Every wave is approved by a person before it goes out. The cascade in detail is in the next section.
- by hour 72
Notification with an initial assessment
Development analyses the vulnerability; the workflow gathers its findings from the ticketing system and writes the draft 72-hour notification: nature of the vulnerability, initial assessment of severity, measures taken, status of user information. Whatever is missing, it requests from the people responsible, with a deadline. After approval, the notification is submitted and the second wave of the cascade is triggered: partners, dealers and system integrators who pass the product on.
- Days 3 to 14
Corrective measure and third wave
As soon as the firmware update has been released, the workflow informs all users of the affected versions in their language: update path, check, contact for questions. Anyone who does not confirm or install the update receives a reminder; critical customers go onto the sales team's call-back list. The security advisory on your website is generated from the same case, and the component manufacturer receives its report if the cause lay in a bought-in component.
- by day 14 after the update
Final report from the log
The final report is due no later than 14 days after the corrective measure becomes available. The workflow produces it from what is in the case: description of the vulnerability, cause, severity, the times of every step, the scope of user information, details of the security update. None of this is pieced together from emails at the end, because everything has been in the case from the start.
- afterwards
Lessons and trial run
The case is closed, and the lessons go into your rules: new classification criteria, revised templates, an additional incoming channel. Twice a year the workflow runs a sample case, so that the call-back list is right, the installed base is current and those who approve know what to expect before it is real.
Cascade
Who learns what has happened, and when
Not everyone at once, but in stages according to how they are affected. Those at the highest risk hear first and in person, the rest in the order you have set in advance. Each wave has a draft, a person who approves it and a point in time in the log.
| Wave | Recipient | Channel | Content | Approval |
|---|---|---|---|---|
| 1, by hour 24 | Customers using the affected versions, starting with operators of critical facilities from your customer list | Email from the template in the customer's language, for critical customers also a call from the sales team with a call note in the case | What is known, which devices and versions, which immediate measures customers can take themselves, who can be reached | Product security and management |
| 2, by hour 72 | Partners, dealers, system integrators and maintenance firms that pass on or look after the product | Email to the security contacts on file, entry in the partner portal | Initial assessment, affected serial number ranges, what partners may tell their customers | Product security |
| 3, with the update | All users of the affected versions, including those without a direct contract | Email, notice in the device interface, security advisory on the website, entry in your company's vulnerability database | Corrective measure, update path, check, deadline, contact | Product security and development |
| 4, after the update | Anyone who has not confirmed the update after two weeks, plus component manufacturers and, on request, the CSIRT | Reminder by email, call-back list for the sales team, report to the component manufacturer from the case | Reminder with status, offer of support, cause for the component manufacturer | Head of service |
You set the order, the templates and the call-back list in the analysis, with your sales team and your legal department. The workflow keeps to them, receives confirmations and questions, matches them to the case and follows up when no answer comes. Anyone who was not reached is on a list in the morning, not in a forgotten email.
Approval
What stays with your people
- The classification. The workflow proposes and gives reasons. Whether a report is an actively exploited vulnerability is decided by your product security officer, in case of doubt with the legal department.
- Every notification to the authority. No draft goes into the platform without approval. Escalation makes sure someone approves before the deadline expires, not that things happen without people.
- Every wave of the cascade. Wording, group of recipients and timing are confirmed before sending. Your people make the calls to critical customers; the workflow supplies the list and the call note.
- The corrective measure. Your development team decides which update is delivered when. The workflow waits for it and derives the deadline for the final report from it.
- The conversation with the CSIRT. A person answers the authority's questions. The workflow puts the case in front of them with every point in time.
Integration
Which systems the workflow sits in
The reporting chain is not a new system alongside the others. It reads from the systems you have and writes back to them.
- IncomingSupport inbox, form for security researchers on your website, partner portal, monitoring of your own services, notices from component manufacturers
- CaseJira, ServiceNow, Freshdesk, Zendesk or whichever ticketing system your development team already uses
- Installed baseCRM such as Salesforce, HubSpot or Dynamics with devices per customer, ERP with serial numbers and deliveries, device register of the remote maintenance system
- Software bill of materialsSoftware bill of materials per product and version, matched against the vulnerability databases of the BSI and the EU
- CommunicationEmail sending with templates per language, Teams or Slack for internal escalation, the sales team's telephone list, security advisories on the website
- AuthorityENISA's single reporting platform. Authority portals rarely have an interface: the workflow pre-fills the notification, a person enters it, and the timestamp goes into the log.
Evidence
The log is the evidence
When the authority asks when you became aware and when you reported, the answer is not a search through inboxes but an export. Every step is in the case with a timestamp: receipt of the report, classification with reasons and the name of the person who approved it, sending of each wave with its list of recipients and confirmations, submission of each notification with the platform's acknowledgement of receipt, availability of the update, final report.
The auditor, the insurer and the customer whose framework agreement requires security management receive the same export. And because the workflow also documents the cases that turned out not to be reportable after checking, you can show that you checked, not just that you reported.
Twice a year, a trial run with a made-up report passes through the entire workflow without a real notification or email going out. It shows whether the installed base is right, whether the call-back list still has the right names on it and whether those who approve respond within the deadline.
Experience
What we bring
The building blocks of this reporting chain have been running at our customers for years. Reading incoming items at scale, matching them to the right case and routing them to the right team is something we know from a technology distributor with twelve sites, where enquiries from twelve sites across Europe reach the right team according to rules. Applying a set of rules to an entire inventory and classifying every finding with reasons is something we built across ten domains at a fuel cell manufacturer, whose service portal with returns process and ticketing system we also built. Cases with log, approval and emails at scale run every night in our own operations.
We put the chain under a statutory deadline, from the incoming report to the authority's platform, into operation together with you. That is why the trial run with a made-up case is the acceptance test: only when it shows that the installed base reaches the right customers and that approvals come within the deadline is the tool considered finished. We show you what a log export looks like in the first call, using an example.
Price
Price and scope
The order of magnitude first: the workflow analysis costs €4,900 at a fixed price and takes three days. Based on our projects, a custom tool typically costs between €25,000 and €60,000, as a fixed price that becomes binding after the analysis; the first version is ready in about six weeks, longer with several duties and languages. Ongoing operation after that starts at €2,900 a month and can be cancelled monthly. A more precise range in advance would be guesswork, because a reporting chain for one product with 400 customers and one for twelve product lines in nine languages are not the same tool. What determines the price:
- number of incoming channels and whether a form for security researchers is part of it
- number of systems from which the installed base is assembled
- number of languages and recipient groups in the cascade
- whether a software bill of materials already exists or still has to be created
- whether the workflow covers only the Cyber Resilience Act or also the reporting duties under NIS2 and for data breaches, which often concern the same incident
Data flow: reports, vulnerability descriptions and customer lists stay on your server or in a German data centre. The AI components, meaning reading, assigning, the classification proposal and drafts, run on open models on your own servers or via EU data centres; a vulnerability description never goes to a model that trains on it. Data flow per service.
Related
Related use cases
- NIS2: reporting a security incident in your own operations. The same deadlines, 24 and 72 hours, but for running your entity rather than for your product. An attack on remote maintenance can trigger both at once.
- GDPR: reporting a data breach within 72 hours. If personal data has leaked through the vulnerability, a third clock is running, to a third authority.
- Product safety: recall and market surveillance. The same cascade to the same installed base, when the problem lies not in the software but in the device.
- All use cases: reporting duties with deadlines, with the table of deadlines across all duties.
Further reading: Cyber Resilience Act: the reporting duty since September 2026 and Monitoring and maintaining an AI workflow.
Questions
Questions about the reporting chain under the Cyber Resilience Act
What product security, development and management ask before they have a reporting chain built. More answers under Questions and answers.
Does the AI decide whether a case must be reported?
No. It proposes a classification and gives its reasons with the relevant passages of the report and the criteria of the regulation. The decision is made by your product security officer, in case of doubt with the legal department. The deadline clock still counts from receipt, so that the decision does not eat into the 24 hours.
Can the workflow enter the notification directly in the ENISA platform?
The platform has been in operation since 11 September 2026; whether and how it offers an interface for manufacturers is something we check in the analysis. Until then, the workflow pre-fills the notification with all mandatory details, a person enters it after approval, and the timestamp of the acknowledgement of receipt goes into the log. The workflow keeps the deadline, not the interface.
Who is there at two in the morning on a Saturday, and who is liable for what?
The workflow runs on your server without people beside it: it takes in the report, opens the case, starts the clock and calls or messages the people on your on-call list until someone confirms. As part of ongoing operation we monitor that the workflow is running, with response times on working days; round-the-clock standby for the workflow itself is agreed separately. If it fails, the on-call list, templates and installed base are ready as an export so that your team can carry on by hand. Your company remains responsible as the manufacturer for meeting the deadline; we are liable for the tool under our terms and conditions, and the trial run before acceptance shows whom your installed base reaches and whom it does not.
Our installed base is incomplete. Does the cascade still work?
It works as well as your data does, and that is exactly why putting data in order is usually the first step: bringing devices from ERP, CRM and remote maintenance together into one list, removing duplicates, flagging missing contacts. The trial run then shows whom you would reach and whom you would not, before it gets serious.
We are a small manufacturer. Does this apply to us at all?
The reporting duty applies to every manufacturer of a product with digital elements, regardless of size. Relief exists in two places: micro and small enterprises pay no fine if they miss the 24-hour deadline for the early warning (Article 64(10)), and they may present the technical documentation in simplified form (Article 33(5)). Whether your product is covered is for your legal advisers to clarify. For the workflow, the smaller the team, the more a tool that keeps the clock pays off, because nobody can maintain a list for 72 hours alongside their actual work.
Handover
The first step is a 30-minute call.
You tell us about the workflow that costs you the most time. We tell you honestly whether AI pays off there and what the next step would be. Whether a workflow analysis follows is up to you.