Cyber Resilience Act: Preparing the 24-Hour Reporting Workflow

Late on a Friday afternoon, a software supplier sends an uncomfortable message: attackers are exploiting a flaw in one of its libraries. The advisory includes a CVE number and a patched release. It does not say whether the vulnerable function exists in the products your company shipped, whether customers can reach it, or which versions remain in use across the European Union. Engineering starts searching old build records while Security tries to establish what actually happened.

This is the practical problem behind the Cyber Resilience Act’s 24-hour deadline. First, the manufacturer has to know its product.

The first deadline arrives early

The Cyber Resilience Act entered into force on December 10, 2024, but its obligations do not begin together. Article 14, covering regulatory reporting and the duty to inform users, applies from September 11, 2026. Most broader requirements for product design, vulnerability handling, technical documentation, and conformity assessment generally follow on December 11, 2027. Manufacturers therefore need a credible reporting operation before the rest of their CRA program is complete.

The duty falls primarily on the manufacturer of a covered product with digital elements placed on the EU market. Depending on the offering, that may be hardware, software, a separately marketed component, or a remote data processing solution on which a product function depends. The boundaries are broad, but not limitless, and must be settled for the actual product rather than inferred from how a company describes itself. The response plan also has to look backward. Article 14 reaches in-scope products placed on the market before the CRA’s general application date, and the European Commission’s current guidance says the reporting duty continues after a product’s support period ends. A discontinued release can still create a live deadline.

Awareness before certainty

The clock starts when the manufacturer becomes aware of a reportable event. In real incident work, that moment rarely announces itself. A customer sends an incomplete log. A researcher emails an exploit sample. A supplier warning appears urgent but may prove irrelevant to the product. None arrives with a legal conclusion attached.

The Commission’s nonbinding implementation guidance offers a workable threshold. After a prompt initial assessment, the manufacturer is regarded as aware once it has a reasonable degree of certainty that a vulnerability is being actively exploited or that a severe incident meeting Article 14’s threshold has occurred. This permits a signal to be tested; it does not permit uncertainty to drift. If the possible impact is serious, the initial assessment must move quickly while deeper forensics continue.

The record needs both timestamps: when the signal arrived and when the evidence crossed the threshold. A later approval meeting does not reset either one.

That makes the intake route more consequential than it looks. Telemetry, customer reports, researchers, and upstream maintainers should enter one case process, with an incident lead able to escalate outside business hours. Technical and legal review can run together. Somebody must own the decision, and the record must show what changed as evidence accumulated—not merely the conclusion eventually reached.

Product history changes the answer

Article 14 covers two event types. An actively exploited vulnerability requires reliable evidence that a malicious actor used the weakness in a system without the system owner’s permission. A CVE entry, scanner result, or vulnerable dependency is not enough by itself. The reverse matters just as much: a manufacturer cannot postpone a required report because no CVE identifier has been assigned.

A severe security incident follows a different test. The CRA asks whether the incident harms, or is capable of harming, the product’s ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions. It also covers incidents that have led, or could lead, to malicious code being introduced or executed in the product or a user’s systems. Malicious intent is not required in every case; the early warning instead states whether unlawful or malicious activity is suspected.

Third-party code brings the distinction into focus. When attackers exploit an integrated component through the manufacturer’s product, the upstream origin of the flaw does not remove the product manufacturer’s responsibility. But a supplier’s advisory does not automatically establish the same reporting threshold when the code is absent, unreachable in the shipped configuration, or not exploited in that product. Either conclusion needs a fast, documented technical basis.

During an incident, the useful question is not whether the organization owns a polished compliance inventory. It is whether the team can move from a marketed name to the exact release that left the company, understand what was inside it and establish which users may still be exposed. A current development branch cannot answer for a two-year-old installation. Release evidence has to travel with the artifact instead of being reconstructed after the clock starts.

A Software Bill of Materials can shorten that search. VEX can hold the next layer of analysis: whether a vulnerability is still being investigated, affects a specific product, is inapplicable for a documented reason, or has been fixed. Neither artifact decides the CRA question. An SBOM establishes composition, not active exploitation or reachability; VEX records product analysis but is not an ENISA filing. The CRA’s general machine-readable SBOM requirement also normally applies from December 2027, not from the September 2026 reporting date.

Reporting while the facts move

The sequence is progressive because knowledge develops. An early warning is due without undue delay and no later than 24 hours after awareness. A fuller notification is also due without undue delay and no later than 72 hours after awareness, adding the available product context, the nature of the vulnerability or incident, an initial assessment, actions already taken, and measures users can apply. Sensitive information may be identified as such, although the manufacturer does not control dissemination simply by marking a report sensitive.

The final deadline depends on the event. For an actively exploited vulnerability, the report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, it is due within one month after the 72-hour notification. The coordinating CSIRT may request interim updates. Finished root-cause analysis is not a prerequisite for the early warning; disciplined continuity between versions is.

Filing takes place through ENISA’s Single Reporting Platform, which routes the submission to the coordinating CSIRT and, as a rule, ENISA. The receiving CSIRT normally disseminates the report without delay to the CSIRTs of member states where the product was made available; delay is reserved for tightly limited cybersecurity grounds. Current guidance uses EU Login, and ENISA says no API will be available at this stage. A company may automate evidence collection and deadline tracking, but submission remains a controlled human act. The internal case should preserve exactly what was sent and when.

The operating model can remain lean. One incident lead should carry the case from signal through final report and pull in the people who know the release, the market, and the customer impact. Legal or Compliance tests scope without becoming a late-stage gate; a named backup must be able to file. Specialists may help, but accountability remains with the manufacturer.

The name Single Reporting Platform applies to the CRA filing. It does not automatically satisfy other legal or sector-specific reporting duties.

The work after filing

An on-time warning does not contain an attack, produce a safe update, or tell customers what to do. Investigation and remediation continue as the regulatory record develops. Article 14 also requires affected users—and, where appropriate, all users—to receive relevant information without undue delay about the event and the corrective or mitigating measures available to them.

That does not automatically mean publishing exploitable detail to the world. The Commission favors a risk-based approach: give the people who need to act enough information to identify an affected version, install an update, or apply a temporary control. Precision is more useful than indiscriminate disclosure.

A rehearsal should reflect that reality. Begin on a weekend with partial logs, a supplier warning, and an unavailable product owner. Make the team find the affected releases, decide when the evidence became sufficient, prepare the first warning, and keep the fix moving. Then continue into the 72-hour update. Switch to the backup filer, verify the current ENISA or coordinating-CSIRT instructions for a platform outage, and identify the customers who need a notice. Use ENISA’s field descriptions or an expressly provided test environment; never send a fictional case through the production platform. The exercise should end only when the decisions, handoffs, and evidence can be reconstructed by someone who was not in the room.

The 24-hour deadline attracts attention because it is easy to measure. The harder work precedes it: retaining the history of shipped products and giving people authority to make a documented decision. When those foundations exist, the filing is no longer the center of the crisis. It becomes one disciplined output of a response that already knows what product it is protecting—and how to protect the people who rely on it.