CRA reporting is live: can you name every affected product in 24 hours?

The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, sets mandatory cybersecurity requirements for hardware and software products with digital elements placed on the EU market. Most of the debate so far has been about December 2027, when the main obligations apply. But one part of the regulation is already in force: since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting their products.

The reporting clock starts when the manufacturer becomes aware of the problem. Within 24 hours, an early warning is due. That deadline turns an engineering data question into a compliance question: when a vulnerability is found in a component, can your team say, within hours, which of your products contain it?

This article explains what the CRA asks today and in 2027, why that question is hard to answer with files and spreadsheets, and how an AI engineering system for regulated hardware answers it in minutes. For a broader overview of the regulation and its impact on hardware teams, see our earlier article on the CRA compliance wall.

What the CRA requires, in short

The CRA entered into force on 10 December 2024. Its obligations apply in two stages.

From 11 September 2026: reporting. Manufacturers must notify actively exploited vulnerabilities in their products and severe incidents that affect the security of their products. Notifications go to the CSIRT designated as coordinator and to ENISA.

From 11 December 2027: the full set of obligations. Products must meet the essential cybersecurity requirements of Annex I, manufacturers must run a vulnerability handling process for the support period, carry out the conformity assessment that matches the product class, draw up the technical documentation and affix the CE marking.

A few obligations deserve attention because they are data obligations as much as security ones:

• —The SBOM. Manufacturers must draw up a software bill of materials in a commonly used, machine-readable format, covering at least the top-level dependencies of the product, as part of the technical documentation.
• —The support period. It must reflect the time the product is expected to be in use, and is at least five years unless the product is expected to be in use for less time. Vulnerabilities must be handled for that whole period.
• —Retention. The technical documentation must be kept for ten years after the product is placed on the market, or for the support period if that is longer.
• —Product classes. Products are default, important (class I or II) or critical. The class decides the conformity assessment route, from self-assessment to third-party assessment.

What the reporting clock actually asks

For an actively exploited vulnerability, the CRA sets three deadlines:

1. 1.An early warning within 24 hours of becoming aware of it.
2. 2.A vulnerability notification within 72 hours, with general information about the product, the vulnerability and the corrective or mitigating measures taken or available.
3. 3.A final report within 14 days after a corrective or mitigating measure is available. For a severe incident, the final report is due within one month.

The early warning must say which product is affected. In practice, the team cannot write it without answering four questions:

• —Which of our products contain the vulnerable component, and in which variants?
• —Which firmware or software versions ship it, and which configurations are in the field?
• —Who owns each affected product, and which suppliers are involved?
• —Which essential requirements and tests does the fix reopen?

Why files and spreadsheets fail the 24-hour test

Take a typical case. A vulnerability is published in the network stack of a radio module, or in a cryptography library used by a microcontroller firmware. The security lead receives the alert at 9:00.

In most hardware companies, the answer is spread across several systems. The SBOM, when it exists, is a file generated at build time and stored with the release. The mapping between firmware versions and product variants lives in a spreadsheet. The list of shipped configurations is in the ERP or a service database. The owner of each product is known by the people who worked on it. The link between the component and the essential requirements, if anyone made it, is in a compliance document.

Answering the four questions means opening each of these sources, reconciling identifiers by hand and asking colleagues. For one product line, this takes a day. For a portfolio of products with variants and years of firmware releases, it takes several days. The 24-hour deadline does not wait for the reconciliation.

The issue is not the lack of security expertise. It is that the answer depends on links between engineering data that nobody maintains in one place.

How Koddex answers the question

Koddex is an AI engineering system for regulated hardware. Teams model their products in their own vocabulary: parts, assemblies, firmware versions, requirements, tests and the links between them. Koddex has no prebuilt "CRA module". The CRA becomes manageable because the data it needs can be modelled as linked items, and the following capabilities then apply to it.

SBOM components as linked items. Each software component from the SBOM is an item, linked to the firmware versions that include it. Firmware versions are linked to the product variants and the hardware revisions they run on. When a component is reported vulnerable, the chain from component to product is already declared.

Impact analysis in seconds. Select the vulnerable component, and impact analysis lists every firmware version, variant and product that depends on it, upstream and downstream, with the owner and status of each item. The answer to the first question of the early warning takes seconds instead of days.

Frozen release baselines. Each release is frozen as a baseline: the exact configuration that was shipped, with its SBOM, its requirements and its test results at that date. You can show which configurations in the field contain the component, and compare two releases to see when it was introduced or removed.

Essential requirements linked to their evidence. The Annex I requirements are items, linked to the design decisions and tests that address them. When a fix changes a component, Koddex shows which requirements and tests it reopens, so the conformity evidence stays current. This is the same approach as audit-ready traceability in other regulated industries.

Traced decisions and scoped access. Every change and decision is logged with who made it, person or agent. Each supplier sees only its own scope of the model, so a module supplier can update its components without seeing the rest of your portfolio. Hosting and access control are described on the security page.

AI agents in the first 24 hours

The reporting deadlines are where AI agents help most, as teammates that take assigned tasks and hand the result back for approval.

When the alert arrives, the security lead assigns a task to an agent: check the reported component against the SBOM items and list what it affects. The agent works within the rights of its service account. It reads the component, the firmware versions, the variants and the baselines, and returns the list of affected products with their owners. It comments on the items it touched, so the trail stays on the data.

A second task drafts the early warning and, later, the 72-hour notification, from the affected list and the information the team has confirmed. The draft goes to the product security lead, who corrects it and approves it. Agents do not submit anything to the authorities on their own: an engineer reviews and signs every notification.

When the fix is ready, the agent lists the requirements and tests the change reopens and prepares the evidence for the final report. The engineer approves the result, as with a pull request.

Preparing for December 2027

The work done for reporting also prepares the full obligations of December 2027:

• —Technical documentation per baseline. Each release baseline holds its SBOM, its requirements, its risk assessment and its test evidence, and can be exported as the technical documentation for that version.
• —The support period. Because baselines are kept with their links, a vulnerability found years after a release can still be traced to the products and configurations it affects.
• —Ten-year retention. The documentation is not rebuilt for each audit. It is the state of the model, frozen at each release and kept.

A practical checklist

1. 1.Classify your products with digital elements: default, important class I or II, or critical.
2. 2.Generate an SBOM for each release in a machine-readable format, covering at least the top-level dependencies.
3. 3.Link SBOM components to firmware versions, and firmware versions to product variants and hardware revisions.
4. 4.Freeze each release as a baseline with its SBOM, requirements and test results.
5. 5.Name an owner for each product and each supplier-provided component.
6. 6.Map the Annex I essential requirements to the design decisions and tests that address them.
7. 7.Rehearse the 24-hour scenario: pick a component, time how long it takes to list every affected product, and fix what slows you down.
8. 8.Define who approves each notification before anything is sent.

If step 7 takes more than an hour, your data is the bottleneck, not your security team.

Conclusion

The CRA turns a question engineering teams rarely ask under pressure into one they must answer within 24 hours: where is this component, and what does it affect? Teams that keep their SBOM, firmware versions, variants, baselines and requirements in separate files will spend the first day reconciling them. Teams that keep them linked in one model will spend it fixing the problem.

Koddex is built for that second situation. In a 20-minute demo, we show how a vulnerable component is traced to every affected product on a portfolio like yours, and your first use case is then live in your own Koddex within a month. The same approach applies across regulated hardware, from robotics to advanced manufacturing.