CRA vulnerability reporting for IoT and embedded device makers
- article-14
- iot
- sbom
- kev
- scope
- non-eu
If you make connected devices and sell them in the EU, Cyber Resilience Act reporting has applied to you since 11 September 2026. An actively exploited vulnerability in your firmware needs an early warning to your CSIRT and ENISA within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days of a fix being available.Art. 14(2) That covers devices already in people's homes and racks, not only the ones you ship next year.
Are devices already on the market in scope for CRA reporting?
Yes. Most of the Cyber Resilience Act only bites on products placed on the market from 11 December 2027, or on older products that are substantially modified after that date.Art. 69(2) Article 14 is the deliberate exception: it applies to all in-scope products placed on the market before 11 December 2027.Art. 69(3) There is no legacy exemption.
For device makers this is the paragraph that changes the arithmetic. Software vendors usually have most users on recent versions. You have a long tail of hardware running firmware from years ago, some of it never updated since the day it was installed.
Two things follow:
- Your reporting inventory is every model and firmware line still in the field that you support, not your current catalogue. If you only build an SBOM for the release you are shipping this quarter, you cannot see whether a kernel vulnerability being exploited today sits in the 2021 firmware a large share of your users still run.
- Support periods become load-bearing. The CRA expects a support period of at least five years, or the expected use time if shorter.Art. 13(8) Article 69(3) itself does not mention support periods, and the Regulation does not say in so many words what happens to a device whose support ended long ago. Treat every model you still support as squarely in scope, and take legal advice before deciding that an older one is not.
What should a firmware SBOM contain?
A firmware SBOM should list every component in the image you ship: the bootloader, the kernel, the C library, busybox, openssl or its replacement, and every package your build system pulls in, as well as your own application. The CRA requires a machine-readable SBOM covering at the very least the top-level dependencies.Annex I Part II(1) On a device, the kernel is a top-level dependency.
Embedded build systems already produce most of this. Yocto's create-spdx class writes
SPDX documents for the recipes in an image, and recent releases enable it by default.
Buildroot exposes per-package metadata, including CPE identifiers, through make show-info.
The problem is rarely that the file does not exist. It is that the components in it cannot
be matched against advisory feeds.
| Component | Typical identifier in a firmware SBOM | What goes wrong |
|---|---|---|
| Linux kernel, built from source | Name and version, sometimes a CPE | No package purl, and vendor backports make the upstream version misleading |
| busybox, openssl, zlib from your build system | Recipe name and version, CPE | Matches by CPE only if the vendor and product fields are right |
| Packages from a binary distribution, such as Debian | pkg:deb/debian/openssl@… | Matches only if your tooling handles OS-package purls and distribution version ordering |
| Your own application | Whatever your build emits | Often missing from the image SBOM altogether |
If you base firmware on a binary distribution rather than building from source, the OS-package problem is the same one container users hit, and it fails in the same silent way. Why your container SBOM matches nothing walks through the purl namespace and version-ordering traps, and the SBOM generation guide covers putting generation in CI so every firmware release gets its own file.
Keep one SBOM per firmware release, not per product. When a vulnerability is exploited, the question is "which versions in the field carry it", and you can only answer that if the old files still exist.
What did the Linux kernel's KEV entries mean for device makers?
Between 11 and 30 September 2026, CISA added 25 vulnerabilities to its Known Exploited Vulnerabilities catalogue. Three were in the Linux kernel, all added on 18 September: CVE-2025-39682, CVE-2025-39964 and CVE-2026-53266. For a software vendor these rarely touch an SBOM. For anyone shipping embedded Linux, they sit in every image.
The same window included two network devices in their own right: MikroTik RouterOS on 25 September and Zyxel GS1900 series switches on 21 September. The full list, with method and data, is in what CISA added to KEV in Article 14's first twenty days.
A kernel entry in KEV is not, by itself, a reportable event. Article 14 is triggered by an actively exploited vulnerability in your product.Art. 14(1) KEV tells you somebody's kernel is being exploited somewhere. It does not tell you yours is. The assessment for a kernel CVE on a device has questions a server vendor never has to ask:
- Is the affected code compiled in? Your kernel configuration decides which drivers and subsystems exist in the image. A flaw in a driver you never build is not in your product.
- Is it reachable on the device as shipped? A local-only flaw matters less on a device with no shell for untrusted users. A flaw in the network stack or a wireless driver matters more.
- Have you already backported the fix? Vendor kernels often carry patches the version string does not reveal, so a version match alone can be wrong in either direction.
- Is there evidence of exploitation against your devices or your users?
Write the answer down either way. A recorded "not reportable, driver not built" is as valuable later as a filing. When the answer is yes, the clock starts from that decision, as set out in what "becoming aware" actually means.
Who reports when you sell through importers and distributors?
The manufacturer reports. Importers and distributors who become aware of a vulnerability in your product must inform you without undue delay, and must also tell market surveillance authorities where the product presents a significant cybersecurity risk.Art. 19(5)Art. 20(4) They do not file the Article 14 report for you.
There is one exception, and it catches white-label hardware. An importer or distributor that places a product on the market under its own name or trademark, or substantially modifies it, is treated as the manufacturer and takes on Articles 13 and 14.Art. 21 If a European brand rebadges your device, check in writing which of you is the manufacturer for each SKU.
For a device maker with no EU establishment, the supply chain also decides where you report. Article 14(7) runs a cascade: the Member State of the authorised representative acting for the highest number of your products, then the importer placing the highest number of them on the market, then the distributor, then the Member State with the most users.Art. 14(7) Note "highest number": if you work with two importers, the one handling more of your products sets the CSIRT. The CSIRT cascade for non-EU manufacturers explains the order and how it changes when your contracts do.
Do product classes like routers and smart home devices change the deadlines?
No. Annex III lists important products, and class I includes several device categories: operating systems; routers, modems intended for connection to the internet, and switches; microprocessors and microcontrollers with security-related functionalities; smart home general purpose virtual assistants; smart home products with security functionalities, including smart door locks, security cameras, baby monitoring systems and alarm systems; internet-connected toys with social interactive or location tracking features; and certain personal wearables.Annex III
Class decides how you demonstrate conformity from 11 December 2027: whether you can self-assess or need a notified body.Art. 32(2) It has nothing to say about reporting. A smart lock and a default-category temperature sensor run the same 24-hour, 72-hour and final-report clocks. The product classes page lets you search the annex by plain-language keyword and shows the conformity route for each class.
What do you owe users of devices that cannot update themselves?
You owe them a notice. After becoming aware of an actively exploited vulnerability, the manufacturer must inform impacted users, and where appropriate all users, and where necessary tell them which mitigations or corrective measures they can apply themselves, where appropriate in a structured, machine-readable format.Art. 14(8) This duty is separate from the CSIRT filing.
The Regulation's design requirements expect automatic security updates enabled by default, where applicable, with an opt-out.Annex I Part I(2)(c) Plenty of fielded hardware cannot do that: no update client, no connectivity, or an installer who switched it off. For those devices, the notice is the fix's only route to the user. It should say which models and firmware versions are affected, how to check the installed version, what to do until an update is installed (disable a service, close a port, take the device off a public network), and how to apply the update by hand.
If you do not inform users in a timely manner, the CSIRTs you notified may inform them instead.Art. 14(8) For a device maker, that is a reputational cost as much as a legal one. You reported to your CSIRT. Now tell your users covers what the notice should contain and how to keep a record of it.
What changes for small device makers?
The duty does not change. The fine does, for one stage. Administrative fines do not apply to microenterprises or small enterprises that miss the 24-hour early warning deadline.Art. 64(10) That exemption covers the early warning only. It does not cover the 72-hour notification, the final report or the duty to inform users, and the early warning is still owed. The full penalty tiers are on CRA fines.
Small device makers also tend to share infrastructure in ways that matter here. If one build server signs firmware for every model, a compromise of that server is a candidate severe incident: Article 14(5) counts an incident capable of introducing malicious code into a product as severe.Art. 14(5) That runs on a different final-report clock from a vulnerability, described in why your final CRA report isn't due 14 days after the bug.
A checklist for device makers
| Item | Why it matters | Where it comes from |
|---|---|---|
| A list of every model and firmware line you still support | Article 14 covers devices sold before December 2027 | Art. 69(3) |
| A stored SBOM per firmware release, including the kernel | You need to know which fielded versions carry a component | Annex I Part II(1) |
| Kernel configuration kept beside each SBOM | Decides whether a kernel CVE is in your product at all | Your triage record |
| A named person who decides "reportable" and records why | Awareness starts the 24-hour clock | Art. 14(2) |
| Your coordinating CSIRT, worked out in advance | A non-EU maker's CSIRT depends on its importers and distributors | Art. 14(7) |
| A written agreement with each rebadging partner on who is the manufacturer | Own-brand importers and distributors become the manufacturer | Art. 21 |
| A user-notice template with a manual update path | Devices without automatic updates depend on it | Art. 14(8) |
What to do this week
- List every model and firmware version you still support, and find the SBOM for each. Where one is missing, regenerate it from the tagged build rather than from today's tree.
- Check one SBOM for the kernel. If it has no identifier you could match against an advisory, fix the generation step before anything else.
- Run that SBOM through the free KEV check to see what it matches today, and how many components it cannot identify at all.
- Work out which CSIRT you would report to, and write down the reasoning. If you have no EU establishment, the CRA reporting page from the Commission and the Regulation itself are the two sources to check your answer against.
Frequently asked questions
Do CRA reporting obligations apply to IoT devices sold before December 2027?
Yes. Article 69(3) applies Article 14 to every in-scope product placed on the EU market before 11 December 2027. There is no exemption for older devices, so an actively exploited vulnerability in a router you sold in 2022 and still support is reportable today.
Does an important product class change the CRA reporting deadlines?
No. Annex III classes decide the conformity assessment route that applies from December 2027. The Article 14 early warning, notification and final report run on the same clocks for a smart lock, a router or a default-category sensor.
Is a Linux kernel CVE in CISA KEV automatically reportable for a device maker?
No. Article 14 is triggered by an actively exploited vulnerability in your product. A KEV entry for the kernel tells you to check whether your build compiles the affected code, whether it is reachable on your device, and whether there is evidence of exploitation against it.
Who reports under the CRA if a non-EU device maker sells through an EU distributor?
The manufacturer reports. Importers and distributors must tell the manufacturer about vulnerabilities they learn of. Their location matters because Article 14(7) uses it to pick the CSIRT a manufacturer with no EU establishment reports to.
What must a device maker tell users when a device cannot update automatically?
Article 14(8) requires you to inform impacted users about the actively exploited vulnerability and, where necessary, the mitigations they can apply themselves. For a device without automatic updates, the notice is often the only way the fix reaches it.
Checked against Regulation (EU) 2024/2847 as of 1 October 2026. Written by the team that builds Declara.
Not sure whether this applies to you?
This produces evidence, timelines and drafts. It is not legal advice, and you remain the party responsible for reporting.