Chen Embedded Software · Article · October 2026

CRA Article 14: what a firmware team must do when a vulnerability is actively exploited

For engineering leads and product owners of connected devices sold in the EU. About 7 minutes.

Most of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) applies from 11 December 2027. One part doesn't wait: Article 14 reporting has applied since 11 September 2026, and it covers products already on the market, not just new ones. If you make a product with digital elements and sell it in the EU, including from outside the EU, this applies to you today.

What triggers a report

Two kinds of events:

• An actively exploited vulnerability in your product: someone is exploiting it in the wild, not merely that it exists. A practical signal is a CVE in a component you ship appearing in CISA's Known Exploited Vulnerabilities catalog.
• A severe incident affecting the security of your product, for example a compromise of your update infrastructure.

A CVE that is merely published, with no known exploitation, does not by itself trigger Article 14 reporting. It still falls under your vulnerability-handling duties from December 2027.

The clock

The clock starts when you become aware, not when your analysis is finished. Reports go through ENISA's Single Reporting Platform to the CSIRT designated as coordinator (normally in the Member State of your main EU establishment). You must also inform affected users about the issue and what they can do.

What goes in each report

• Early warning (24 h): which product, and the Member States where it is made available. For an incident: whether it is suspected to be caused by unlawful or malicious acts.
• Notification (72 h): general information about the product, the nature of the exploit and the vulnerability (or the incident), corrective or mitigating measures taken and measures users can take, and how sensitive the information is.
• Final report: a description including severity and impact, information about the malicious actor where available (or the root cause for an incident), and details of the security update or other measures.

Why firmware teams are exposed

A typical microcontroller product ships vendored third-party code (an RTOS, a TCP/IP stack, a TLS library, vendor drivers) that nobody tracks after the initial integration. When one of those components lands in the KEV catalog on a Friday evening, three questions decide whether you can make the 24-hour deadline:

1. Which of our products and firmware versions contain this component? That needs a current SBOM per release.
2. Is the vulnerable code actually in the image and reachable? That needs linkage data and someone who knows the code.
3. Who submits the early warning, and are they reachable at the weekend? That needs a named owner and deputy.

Teams that can't answer the first question quickly usually can't meet the deadline at all.

A minimum setup you can do this month

1. Inventory: list every product on the EU market, its firmware versions in the field, and where it's sold.
2. SBOM per release: generate one from the shipped image. For bare-metal and RTOS projects, here's how with the free fwsbom tool.
3. Daily monitoring: re-scan every SBOM nightly against NVD, OSV and CISA KEV. New CVEs are published against old code every week.
4. Owner + deputy: name who reports, set up access to the reporting platform, and agree weekend coverage.
5. Pre-filled templates: prepare each product's fixed details (identity, Member States, update mechanism) now, so that under pressure you only add the event-specific facts.
6. Rehearse once: a 30-minute tabletop exercise ("CVE in our TLS library added to KEV, Friday 17:00") exposes the gaps.

Sources: Regulation (EU) 2024/2847, Article 14 and Article 71; official text on EUR-Lex. Always check obligations against the official text and ENISA guidance.