Preparing for the CRA 24-hour vulnerability reporting duty

A customer in the EU emails to say your connected product is being attacked in the wild. Under the Cyber Resilience Act you now have a clock running from the moment you become aware. Most small hardware makers have no one assigned to receive that email, no account on the reporting platform, and no way to tell which firmware version the customer is running.

The wider CRA product requirements apply from 11 December 2027. The reporting duty did not wait. It started on 11 September 2026. This note covers what triggers it, what the deadlines are, and what a tiny company can set up now, mostly in firmware and build records rather than paperwork.

What actually has to be reported

The duty is narrower than “any security bug.” Two things trigger it: an actively exploited vulnerability in your product, and a severe incident that affects the security of your product. The text of Regulation (EU) 2024/2847 defines both, and the severity criteria for incidents sit in Article 14.

In practice that means:

• Reportable: you have reliable evidence that someone has exploited a flaw in a shipped product without the owner’s permission. A compromised firmware signing key or a tampered build pipeline is the kind of incident that belongs here.
• Not the trigger by itself: a bug you found in review, a researcher’s good-faith report with no sign of exploitation, or a published proof of concept nobody has used. You still fix those. They do not start the 24-hour clock.

Whether a given event meets the definition is a judgment call, and the answer can depend on facts about your product. If you are unsure, ask a lawyer who knows the Regulation. We are an engineering shop and do not give legal advice.

The three deadlines

As the regulation text and published summaries lay it out, the deadlines run from when you become aware:

1. Early warning, within 24 hours. A first notice that an exploited vulnerability or severe incident exists. For an incident it also says whether you suspect unlawful or malicious acts. It can be thin. Speed matters more than completeness.
2. Notification, within 72 hours. A fuller account: the general nature of the vulnerability and the exploit, an initial assessment, and any corrective or mitigating measures taken or planned.
3. Final report. For a vulnerability, no later than 14 days after a fix or mitigation is available. For a severe incident, within one month of the 72-hour notification.

Note what the 14-day clock does not mean. It does not require a patch within 14 days. It starts when a fix or mitigation exists. But the first two deadlines do not wait for one, so you must be able to say something useful about impact before you have a fix.

Reports go through the single reporting platform that ENISA runs, which routes them to the relevant national CSIRTs. ENISA’s platform page says mandatory notifications go through it from 11 September 2026, that reporters register as Assigned Representatives (primary and secondary), and that the documentation is still being updated, so check the date on any guide you follow. Informing your users is a separate duty from reporting to the authorities. Read the Regulation on that point rather than relying on a summary. The European Commission also keeps a reporting page with its own guidance.

What to have in place before the email arrives

Almost nothing here is exotic. All of it is hard to do in the first 24 hours if you have never done it.

A named person and a backup. The platform expects at least two registered representatives. For a one- or two-person company, that means the second person may be a trusted contractor. Register while things are calm, not during an incident. ENISA’s page describes how representatives are invited and notes the process changed in a recent platform release.

A way to know what is out there. You cannot report on a product you cannot identify. For every shipped unit, you need to be able to answer: which hardware revision, which firmware version, which build, which bootloader. That means:

• A firmware version string that is reachable from the device, not only baked into a filename.
• A serial number tied to a build record at the end of the line. We cover that mechanism in provisioning serial numbers and keys on the production line.
• Tagged, reproducible builds, so you can rebuild the exact binary that shipped and diff it against a suspect one.

An inventory of what is inside the firmware. An exploited flaw in a library you did not write is still your problem as the manufacturer. Keep a software bill of materials for each release: RTOS, TLS stack, USB stack, BLE stack, bootloader, vendor SDK. Chip vendors are starting to publish tooling for this. For example, Espressif’s CRA obligations post describes scanning ESP-IDF projects against known vulnerabilities. That is a vendor document about one family, but the habit applies to STM32, nRF52, and the rest: subscribe to the vendor’s security advisories and re-check the list on a schedule.

A signing key you can account for. A leaked signing key is both a likely severe incident and the thing that makes a fix hard to deliver safely. Know where the key lives, who can use it, and what you would do if it leaked. If your bootloader trusts exactly one key with no rotation path, you have a design problem to fix before you have an incident to report.

A pre-written template. The 24-hour notice should take minutes. Draft the fields in advance: product name and version range, what you observed, why you believe it is exploitation, what you suspect the attacker can do, and what you are doing next. Keep it somewhere you can reach without the affected systems.

The firmware part: can you actually ship a fix?

Reporting is the easy half. The harder question is what happens next, and the answer is mostly decided by choices made in firmware design.

• Can a unit be updated at all? A product with no update path can only be mitigated by telling the owner to unplug it. If your product has no field update, decide now whether that is acceptable for its risk.
• Can an update fail safely? A rushed security patch is exactly when a brick is most costly. A dual-bank or recovery-image design, covered in firmware updates with recovery and rollback, lets you push the patch without betting the install base on one flash write.
• Can you mitigate before you patch? For some flaws, the fastest mitigation is a configuration change: disabling a debug service, closing a port, turning off a remote feature. Firmware that has a remote-configurable kill switch for risky features buys time for the 72-hour notification.
• Is debug access closed in production? Open debug ports, default credentials and shared passwords are the usual way a fleet gets exploited in the first place. Locking the debug interface on production units is a decision to make at the factory, not after a report.

Not every product needs all of this. A battery-powered sensor with no network connection is a different case from a gateway with a cloud account. Whether your product is in scope at all depends on its connections and on where you sell it, so confirm that against the Regulation first.

Rehearse once

Run a 90-minute drill with a made-up event. Someone sends a fake “customer reports exploitation” email. The named person has to log in to the platform, identify the affected firmware range from your own records, and fill a draft of the early warning. Whatever stalls, whether it is an expired login, a missing build record or nobody knowing where the signing key lives, is your real to-do list.

We do this kind of preparation as firmware and production-process work: version identification, build records, an update path that can recover, and a bill of materials per release. If you are shipping to the EU, send us your product’s firmware architecture, how units are updated today, and where the signing key lives. We will tell you what we would change first.

Sources: Regulation (EU) 2024/2847 on EUR-Lex, ENISA single reporting platform, European Commission CRA reporting page. This note is engineering guidance, not legal advice.