What the CRA asks of your Linux firmware, and what you can check today

Regulation (EU) 2024/2847, the Cyber Resilience Act, has been in force since December 2024. Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents. On 11 December 2027 the full regulation applies: essential requirements, technical documentation and CE marking with cybersecurity inside.

If you build a product with embedded Linux and sell it in the European Union, this affects you. What follows is a translation of what the regulation asks into what that means for a Yocto or Buildroot image, and a short list of things you can check today without hiring anyone.

What the regulation asks, in firmware terms

Annex I of the CRA has two parts. The first describes what the product has to be like; the second, how you have to manage its vulnerabilities over its whole life. Summarised for a Linux device:

About the product

• No known exploitable vulnerabilities at delivery. It does not say “no CVEs”, it says no known exploitable vulnerabilities. The difference matters: a kernel with 200 listed CVEs can be acceptable if none is exploitable in your configuration; a single CVE in a network-exposed service is not.
• Secure by default configuration. No default passwords, no debug services active in production, no open ports that are not needed.
• Integrity and secure updates. The device must be able to receive security updates, and those updates must be protected: signing, verification, and ideally rollback if something fails. This is where secure boot and the OTA mechanism come in.
• Protection of data and communications. Encrypted communications, protected storage of credentials and keys.
• Security event logging. The device must record what is relevant for security in a way that cannot be tampered with unnoticed.
• Attack surface reduction. What is not used is not included.

About vulnerability handling

• Component inventory (SBOM) in a machine-readable format, at least covering top-level dependencies. Without an inventory you cannot know whether a new vulnerability affects you.
• A process to handle vulnerabilities: how you detect them, how you fix them, how you distribute the patch.
• A contact point for reports and a coordinated disclosure policy.
• Notification to the authority within 24 hours for severe cases, with a report at 72 hours.
• Support for the expected period, with a minimum of five years unless the product is designed to last less.

What costs the manufacturers I know the most is not the list itself. It is that most products on the market were built without any of these mechanisms, on a BSP from the module vendor that nobody has updated since launch.

Five things you can check today

You do not need an audit to get an idea of where you stand. With the production image and an afternoon:

1. Generate an SBOM and count the packages

With Syft on the rootfs or the image:

syft dir:./rootfs -o spdx-json > sbom.spdx.json

If you use Yocto, compare the result with the manifest the build produces in tmp/deploy/images/<machine>/. The differences tell you how much your SBOM can be trusted against what is really in the image.

2. Run a vulnerability scanner over it

With Grype on that SBOM:

grype sbom:sbom.spdx.json -o table

The total number is always scary. Do not stop there. Filter by severity and, above all, ask for each high CVE whether the affected component is exposed on your device. A vulnerable curl used only in an internal script is not the same as a vulnerable dropbear listening on port 22.

3. See what is listening on the network

On a running device:

ss -ltnup

Every open port is attack surface. The usual suspects in embedded products: a configuration web server without TLS, SSH with password login, telnet “for compatibility”, a debug service that was left enabled.

4. Look for credentials and keys in the image

grep -rE "BEGIN (RSA|EC|OPENSSH) PRIVATE KEY" rootfs/
cat rootfs/etc/shadow

A private key inside the image is the same key in every device you have sold. A root password in /etc/shadow is a default password, however long it is.

5. Check whether boot is verified

Does the bootloader verify the kernel signature? Does the kernel verify the rootfs? On i.MX that is HAB and, on recent parts, AHAB; on STM32MP it is the TF-A secure boot chain. If the answer is “I do not know”, the answer is no. And without verified boot no update is truly secure, because anyone with physical access can replace the image.

What to do with what you find

These five checks give you an honest picture in an afternoon. What they do not give you is priority or a plan: which of the 137 CVEs matter on your device, which gap against the regulation is the most expensive to close, and in what order to do it so you reach December 2027 without rebuilding the product.

That is exactly what our Quick Scan does: you send us the image and within 48 working hours you have the SBOM, the vulnerabilities with their exploitability on your specific device, the configuration findings and a page with what is missing against the CRA. For €1,900, credited in full if you later order the complete audit.

If you would rather talk first, book 30 minutes. No commitment and no sales deck.