CRA reporting duty: 24 hours, and a Tyrolean manufacturer counts as the manufacturer

The Cyber Resilience Act entered into force on December 10, 2024, with the main obligations taking effect on December 11, 2027. Some requirements do not wait that long: the reporting obligations. They have applied since September 11, 2026, which is one week ago.

For a manufacturing company in the Tyrolean Unterland, this is a new role. It sells machines, not software. But the control software in the machine, the service app at the customer, and the internally built tool are exactly what the regulation defines as a product with a digital element. The wording of the regulation clarifies whether its own product line falls under it. It does not clarify that the deadline applies.

What has been in effect for a week

Two types of issues are reported: actively exploited vulnerabilities and severe incidents, each affecting the security of the product with a digital element. Four clocks:

Time	What is due	Deadline
From awareness	Early warning	24 hours
from awareness	full report	72 hours
actively exploited vulnerability	final report	no later than 14 days after a fix is available
major incident	final report	within one month of the 72-hour notification

You submit once. ENISA's Single Reporting Platform has been live since September 11, 2026. Reports go to the CSIRT of the member state of your main establishment and are simultaneously disclosed to ENISA, unless specific cybersecurity reasons prevent this. A delegated act from December 11, 2025 (CELEX 32026R0881) specifies these reasons. The receiving CSIRT shares the report with authorities in states where the product is available.

For us: one form, no package per country. Source status: September 17, 2026. As of today, CERT.at is the national CSIRT where reports under Art. 71 are submitted. Working assumption, not a legal citation: the Austrian market surveillance authority is not verified for us. The Commission guidelines of July 27, 2026 arrived just seven weeks before the deadline. Open-source stewards only become subject to reporting obligations from December 11, 2027 (Art. 71 para. 2 via Art. 24 para. 3). The first 24 hours are the focus of the debate. CERT.at referenced a post on heise online in its daily report on 16 September. Facts remain on the Commission pages.

Symbol of the European Union, ring of twelve stars — The Cyber Resilience Act is a regulation and applies directly. The 24-hour deadline is not a recommendation from an authority. (Quelle: EU Digital Strategy)

Where a finished product is subject to a duty

Four cases we see all the time:

Machine with control or service software. Service access runs through us.
Telemetry or fleet application. An app that sends machine data home.
Configurator or sizing tool. A bill-of-materials calculator or variant tool that the customer runs themselves.
In-house development used by the customer. The tool that originated internally and was shared because it was practical.

The trap is the sentence: the software comes from the supplier anyway. The role depends not on who wrote the code, but on what is placed on the market in whose name. A purchase does not shift the obligation. Only the regulation text, linked from the Commission's CRA page, not the blog summary, answers where the boundary between purchaser, distributor, and manufacturer lies. For the internal list, the rough rule suffices: Everything that leaves our house and connects a digital element with data goes on Sheet A.

Tuesday, 23:40

A customer reports via the service channel: A vulnerability in the service software of a delivered machine is being actively exploited in their network. Just before midnight, the email arrives at the service hotline number, on a device someone has at home.

The early warning runs until Wednesday 23:40. What must be delivered then is awareness, not a response: which product, what impact, what we are doing, who is reachable. The full report runs until Friday 23:40, then internal requirements go beyond a gut feeling: affected versions, number of customers, what is contained, who approved it.

Most people miss the third clock. The final report for an actively exploited vulnerability is due 14 days after a fix becomes available, not after the incident. Someone in-house must note the date the fix becomes available. Otherwise, the report is not late after six weeks; it simply does not exist. For a severe incident, the deadline is one month from the 72-hour notification. And on the night when your own operations are also affected, two clocks are running.

Deadlines per statute and authority descriptions, as of September 17, 2026 (source: European Commission, CRA reporting)

Three sheets that carry the case

A single reporting concept for everything becomes unmaintainable. Three sheets with clear interfaces work even in a spreadsheet maintained by an apprentice.

Sheet A: Product list with responsible person. One row per product: name and status, included software or firmware, company's ÖNACE code, main customers and target markets, and a named person authorized to report for this product. Without the last column, Sheet A is an Excel file.

Sheet B: Reporting path, one page. Platform access and who owns it, CSIRT contact, two templates for early warning and full report, the approval chain in hours. Plus the uncomfortable question: Who wakes whom at 23:40? The page is printed and available in the service office, not on a drive that nobody opens after 8 PM.

Sheet C: Proof. Outside: what was reported when, including platform confirmation. Inside: what was decided when, who approved it, why a measure was postponed. Without the inner block, the log later reads like a mailbox export.

The sheets are not new; they are the same ones NIS2 requires: inventory, process, evidence. The effort counts double. Those who fill them for NIS2 in-house have the CRA documentation almost ready, and those who keep their logs in-house provide the facts for both. Same method as for evidence under Article 4 of the AI Regulation: three sheets, maintainable by one person, without a compliance department.

The problem is the org chart

24 hours is not a tool problem. No product meets that deadline. It holds for a person who was told in advance that they are allowed to do it alone, without asking.

In most companies we ask, that person does not exist. There is someone who calls when things catch fire, and someone who decides when a note is placed in front of them. In between lie deadlines, Tuesday night, two vacations, and a phone battery. Security Awareness ends here with phishing training, yet it starts here: The alert about an active attack against a delivered product arrives at the service hotline, not at IT.

Our recommendation to CEOs at our size, in this order:

Name the authorized person and deputy in writing, with date, including permission to issue an early warning even without a full analysis.
One person who owns platform access, and a second who also gets it while on vacation.
Bind the 14-day clock to an event that already occurs in the house. The completion report date moves into the same list with the release report.
Twenty minutes per quarter. One person reads sheet B aloud, and everyone else says who they would call.

As long as access, templates, and the approval chain are in place, an early warning sent out too simply is a better miscalculation than one that arrives too late. An operational recommendation, not legal advice.