Your firmware has hundreds of CVEs. A handful reach the device.
Connected and embedded products are squarely in scope of the CRA — and their firmware SBOMs are where the noise is worst. An RTOS, a crypto library, a board support package and a hundred bundled components each drag in a long CVE list, almost none of it exploitable in your build. ProvenVEX proves which ones actually reach the device, so you report and patch the few that matter.
The CRA applies the same. The product doesn't behave the same.
A connected device is a product with digital elements like any other — but three things about embedded software make the obligations bite differently.
Years in the field
Devices ship and stay deployed for a long time. The support period stretches accordingly, and you owe vulnerability handling for all of it — long after the team has moved on to the next product.
Deep, opaque dependency trees
Firmware bundles a kernel or RTOS, C/C++ libraries, a BSP and layers of open source. The tree is large, transitive, and often inherited from a vendor SDK you didn't assemble.
Hard to patch, hard to reach
You can't hotfix a fielded device like a web app, and whether a bundled CVE is even exploitable depends on how the component was compiled and configured for this device.
Most of a firmware CVE list is not your problem — but you have to prove it.
Correlate a firmware SBOM against the vulnerability databases and the result is overwhelming. The catch: in an embedded build, most of it never runs.
A vulnerable component isn't a vulnerable device.
An openssl CVE in a feature you didn't compile in. A kernel flaw in a subsystem your board doesn't use. A library bug behind a config flag you set to off. Each is present in the SBOM and unreachable in the device — and static correlation can't tell the difference, so it flags them all. Exploitation evidence can: it shows whether the vulnerable path is actually reachable and triggerable in this firmware.
Four obligations, tuned for hardware that ships and stays.
A real firmware SBOM
Describe the software in the image — RTOS/kernel, libraries, BSP, bundled OSS — in CycloneDX or SPDX. See SBOM for the CRA.
Which CVEs reach the device
Reachability and exploitation proof against the actual build, so the hundreds collapse to the few that are genuinely exploitable — evidence-backed VEX.
Support period & EOL components
Track the declared support window per device, and flag components — an ageing kernel, an unsupported crypto library — that reach end-of-life inside it.
Report only what's real
When a bundled component crosses into active exploitation, decide fast whether it reaches your device — and report on the 24 / 72 / 14 clock only if it does.
Reporting without the noise.
The embedded world lives in the KEV catalogue — router, camera and IoT component flaws are among the most actively exploited vulnerabilities there are. So when one lands in a library you ship, the 24-hour clock is a real risk, not a theoretical one. The question that decides whether you're filing a report is always the same: does the exploited vulnerability actually reach this device?
Answer that with evidence and two things happen. The reporting load drops to the vulnerabilities that genuinely qualify, instead of every KEV hit against a bundled component. And each not_affected you file carries proof that the vulnerable path isn't reachable in your build — the defensible answer when a market-surveillance authority asks why a fielded device wasn't recalled or reported. The mechanics are the same correlation and active-exploitation detection and 24 / 72 / 14 reporting the platform runs everywhere — the embedded case is just where cutting the noise matters most.
The honest answers.
Does the CRA apply to IoT and embedded devices?
Yes. Connected and embedded devices are products with digital elements and are squarely in scope of the CRA. The obligations — secure-by-design, an SBOM, vulnerability handling across the support period, and reporting of actively exploited vulnerabilities — apply to the software in the device, including bundled open source and firmware.
Does the SBOM have to cover firmware and bundled open source?
Yes. The SBOM must describe the software actually shipped in the device, which for embedded products means the firmware image: the RTOS or kernel, C/C++ libraries, the board support package and every bundled open-source component. Those components are where most of a device's CVEs — and most of the noise — come from.
My firmware SBOM has hundreds of CVEs. Do I have to report them all?
No. The CRA reporting obligation is triggered only by actively exploited vulnerabilities that affect your product. In an embedded build most bundled-component CVEs are not reachable — the vulnerable feature isn't compiled in, or the configuration disables it. Evidence-backed VEX proves which of the hundreds actually reach the device, so you report and remediate the few that matter.
How long is the support period for a device, and what about EOL components?
The CRA support period is at least five years, unless the device's expected use is shorter — and for long-lived industrial or embedded products it is often longer. Across that window you must keep handling vulnerabilities, which means tracking components that reach end-of-life inside the support period, such as an unsupported kernel or crypto library, and flagging them before they become unpatchable.
Bring one firmware image. See what actually reaches the device.
We'll take the SBOM for a single device, run the assessment against the build, and come back with an evidence-backed VEX and a reportability shortlist — the few CVEs that matter, out of the hundreds that don't.
Firmware SBOMs · support-period & EOL tracking · EU-hosted