EU Cyber Resilience Act compliance for embedded products.
We get the firmware side of your connected product ready for the CRA: a software bill of materials, secure boot, signed updates and a working vulnerability reporting process.
Vulnerability and incident reporting starts, including for products already on sale.
To report an actively exploited vulnerability after you become aware of it.
Every essential requirement applies to products placed on the EU market.
Of worldwide annual turnover, whichever is higher.
Which products the CRA covers.
Any hardware or software product with a data connection to a device or network, sold in the EU. Where it was made makes no difference.
Consumer devices
Smart home products, wearables, connected appliances and toys.
Industrial devices
Sensors, gateways, controllers and operator panels.
Networking equipment
Routers, modems, access points and switches.
Software and firmware
Sold on its own or inside a product, plus the remote data processing a device depends on.
The dates that matter.
In force
Regulation (EU) 2024/2847 published and in force.
Notified bodies
Rules for conformity assessment bodies apply.
Reporting
Actively exploited vulnerabilities and severe incidents must be reported.
Full application
Every new product must meet Annex I and carry CE marking that covers cybersecurity.
What the CRA requires from your firmware.
Annex I sets the essential requirements. These six carry most of the engineering work.
Software bill of materials
A machine readable list of every component and version in the firmware, updated with each release.
Secure boot
The device runs only firmware signed with your key. Modified code is rejected at start up.
Signed security updates
Fixes delivered over a secure channel, verified on the device and provided free of charge for the support period.
Secure by default
Shipped in a secure configuration, with access control and a way to reset to the original state.
Data protection
Stored and transmitted data encrypted, with integrity protection against tampering.
Vulnerability handling
A published disclosure policy, a security contact, and a process to fix and report issues.
Security updates for as long as the product is expected to be in use. At least five years, unless the expected use is shorter.
What this looks like inside the device.
Three mechanisms do most of the work. Each is built into the bootloader, the build system and the update path.
Secure boot chain of trust
A key fused into the chip anchors every stage. Each stage checks the next signature before handing over.
Signed update path
Updates are signed off the build server, verified on the device and installed to a second slot, so a failed update rolls back.
SBOM with vulnerability check
Generated in the build for every release, then checked against published vulnerabilities as new ones appear.
Start with a two week readiness assessment.
One fixed price. A report that shows exactly where your product stands and what to fix first.
The reporting clock for exploited vulnerabilities.
The clock starts when you become aware of an actively exploited vulnerability in your product.
You become aware
A researcher, customer or your own monitoring reports active exploitation.
Early warning
Which product is affected and where it is sold.
Notification
The vulnerability, its severity and the mitigation available so far.
Final report
After the fix is available: root cause, impact and the correction released.
Same 24 h and 72 h steps, final report within one month. All reports go through the EU single reporting platform to ENISA and your national CSIRT.
What we set up for you
The readiness assessment.
Two weeks, one fixed price. We review your firmware, hardware and release process against Annex I and hand you a report you can act on or show your board.
How an engagement runs.
Readiness assessment
Firmware, hardware and release process reviewed against Annex I.
Implementation
Secure boot, signed updates, encrypted storage, SBOM generation in the build and the disclosure process.
Ongoing support
Components watched for new vulnerabilities, fixes released as signed updates, reports prepared when something is exploited.
Platforms and tooling.
Microcontrollers
ESP32 with ESP-IDF secure boot and flash encryption, STM32, Nordic nRF, FreeRTOS and Zephyr.
Embedded Linux
Yocto and Buildroot builds on NXP i.MX, Raspberry Pi Compute Module and NVIDIA Jetson.
Boot and update
MCUboot, U-Boot verified boot, A/B partition updates and signed OTA images.
SBOM and vulnerability data
CycloneDX and SPDX generated in the build, checked against public vulnerability databases.
Connected products we have engineered.
C100 · environmental monitoring
Sensing node with embedded software, IoT monitoring and an application specific machine learning workflow.
Dreep · connected dispensing appliance
Embedded software, touchscreen and electronics for a connected home appliance.
Integrated Display Controller
Embedded Linux controller with a dedicated maintenance interface for a full flight simulator.
Frequently asked questions.
Does the CRA apply to my product? ▼
If it is hardware or software with a data connection to a device or network and it is sold in the EU, it is almost certainly in scope. This includes products made outside the EU. Medical devices, motor vehicles, civil aviation and marine equipment follow their own sector rules instead.
My product is already on sale. What applies to it? ▼
The reporting duties apply from 11 September 2026 to products already on the market. The full requirements apply to products placed on the market from 11 December 2027, and to older products when they are substantially modified.
What must be reported, and where? ▼
Actively exploited vulnerabilities and severe incidents. An early warning within 24 hours, a notification within 72 hours and a final report afterwards, submitted through the EU single reporting platform to ENISA and the national CSIRT.
How long do we have to provide security updates? ▼
For the support period you declare. It has to reflect how long the product is expected to be used and is at least five years, unless the expected use is shorter.
How does this fit with conformity assessment and CE marking? ▼
Most products are self assessed by the manufacturer. Products in the important and critical categories need harmonised standards or a notified body. In both cases we produce the engineering evidence for your technical documentation: SBOM, security architecture, test records and the update process.
Can you work on firmware another team wrote? ▼
Yes. The assessment starts from your current source, build and hardware, whoever wrote them.
What do you need from us to start? ▼
Access to the firmware source and build, a hardware sample or remote access to a unit, and any existing product documentation. An NDA is signed first.
Who owns the work? ▼
You do. Deliverables are assigned to you as they are paid for.