Cyber Resilience Act: What It Means for Embedded Linux

If you sell a connected device in the EU, the Cyber Resilience Act already applies to you. Since 11 September 2026, you must report any actively exploited vulnerability in it within 24 hours of finding out, and that includes units you sold years ago. From 11 December 2027, every new unit you place on the EU market must also meet the Act's security requirements: an SBOM, security updates for at least five years, a way to report vulnerabilities to you, and a CE mark that says you checked.

The Act does not care where the manufacturer is. A Canadian or American company that sells into the EU is covered exactly as a German one is. For an embedded Linux product, most of what it asks is a build-system problem, and a well-kept Yocto build already does much of it.

Two dates, two different duties

The Act entered into force on 10 December 2024, but its obligations arrive in stages. Two dates matter to a device maker.

11 September 2026: reporting. Article 14 now applies to every product with digital elements on the EU market, including those placed on it before December 2027. If someone is actively exploiting a vulnerability in your product, or a severe incident affects its security, you must notify.

11 December 2027: everything else. Each unit placed on the market from that date must meet the essential requirements in Annex I, carry technical documentation and an EU declaration of conformity, and bear the CE mark. Units already sold before then do not have to be brought up to standard, unless you substantially modify them afterwards.

So the first deadline has already passed, and it is the one that catches teams out: a product line that is years from its next hardware revision still owes the 24-hour report today.

What reporting within 24 hours means in practice

An actively exploited vulnerability starts three clocks:

• 24 hours: an early warning.
• 72 hours: a full notification, with what you know about the vulnerability and what you have done about it.
• 14 days after a fix is available: a final report.

A severe incident follows the same first two steps, with its final report due within a month. Every notification goes through the Single Reporting Platform run by ENISA, the EU's cybersecurity agency, which passes it to the national cybersecurity authorities concerned. You also have to tell affected users what they can do to protect themselves.

None of that is hard to file. What is hard is answering the questions behind it inside a day: which firmware versions contain the vulnerable component, which customers run them, and whether those devices are reachable from a network an attacker could use. A team that cannot answer from its build records will spend the 24 hours finding out. That is why reporting turns into a build-system question a year before the build requirements apply.

What Annex I asks of the device from December 2027

Annex I has two parts: what the product must be, and how you must handle vulnerabilities in it. For an embedded Linux device, these are the requirements that land on the build.

• No known exploitable vulnerabilities at release. Every image you ship needs a vulnerability scan and a written decision on each finding.
• A software bill of materials. It must be machine-readable, in a commonly used format, and cover at least the top-level dependencies. It goes in your technical documentation, which a market surveillance authority can ask for; it does not have to be published.
• Secure by default. The product ships in a secure configuration, with a way to reset it to its original state. In practice: no shared default password, no debug services, no open ports nobody needs.
• Security updates. Vulnerabilities must be fixable by updates, installed automatically by default where that is appropriate, with an opt-out. Security updates must be free of charge and distributed securely.
• Integrity and confidentiality. Protect the software and the data on the device from tampering, and encrypt what is sensitive, at rest and in transit.
• A minimal attack surface. Ship only what the product uses.
• Security logging. Record security-relevant events, with a way for the user to opt out.
• A front door for researchers. A published contact for vulnerability reports and a coordinated disclosure policy.

On top of Annex I, Article 13 sets the support period: at least five years, or the product's expected time in use if that is shorter, and the end date has to be stated where the buyer can see it. Article 13 also makes you answerable for every component you integrate, open source included.

Where each requirement lands in a Yocto build

Most of this maps onto Yocto features that already exist.

• SBOM: the create-spdx class writes an SPDX document for every image. Since Yocto 5.1 the default is SPDX 3.0, which can also carry each recipe's CVE status. Archive it with the release, not in a build directory.
• Known vulnerabilities: the cve-check class, or the newer sbom-cve-check tool that reads the SPDX output, reports CVEs per image. Record a reason in the recipe for every CVE you decide not to fix, so an ignored one explains itself.
• Updates: an A/B update system such as RAUC, SWUpdate or Mender, with signed bundles and a rollback you have tested on real hardware, power cut included.
• Integrity: a verified boot chain that ends in a key you control, and a read-only root filesystem protected by dm-verity.
• Confidentiality: a LUKS-encrypted data partition, with keys held by the SoC's secure storage rather than in the image.
• Attack surface: a minimal production image, without the development features that allow an empty root password or ship debug tools.

The Yocto Security & CRA Compliance Checklist works through each of these as a release check.

The support period is longer than any Yocto release

Here is the arithmetic most teams have not done yet. Yocto's current long-term releases are Scarthgap, supported until April 2028, and Wrynose, supported until April 2030. A product that ships in December 2027 on Wrynose and commits to five years of security updates owes them until December 2032.

That leaves two and a half years with no upstream fixes. You can plan a move to the next long-term release partway through the product's life, or you can maintain the old one yourself. Both are workable. What does not work is discovering the gap when the first CVE lands in 2030. Write the plan down now, because the end date you state to buyers is a promise the Act will hold you to.

Where to start this quarter

1. List what is in the field. Firmware versions, the customers running each, and which of them sell into the EU.
2. Rebuild an SBOM for every shipped release. If a tagged release cannot be rebuilt bit for bit, that is the first thing to fix.
3. Rehearse the 24-hour path. Who receives a vulnerability report, who decides it is actively exploited, and who files with ENISA. Publish a security contact, if you have none.
4. Choose the support period and the long-term release plan that covers it.
5. Check the build against Annex I, using the checklist above, and fix the gaps before December 2027 rather than during it.

The penalties are real: up to 15 million euros or 2.5% of worldwide annual turnover, whichever is higher, for breaching the essential requirements or the reporting duty. But the larger cost is the one that does not show on a fine. From December 2027, a product that cannot be patched cannot be sold in the EU, and a buyer's procurement team will ask how you comply long before a regulator does.

MNP Systems builds and maintains production embedded Linux platforms, from the SBOM to the update pipeline. Talk to us about where your build stands, or read how we approach embedded systems.

Sources

• Cyber Resilience Act, European Commission
• CRA reporting obligations, European Commission
• Regulation (EU) 2024/2847, the full text
• Yocto Project releases and support dates
• Creating a software bill of materials, Yocto Project manual