The EU Cyber Resilience Act makes security a mandatory part of embedded Linux engineering, not an optional add-on. Reporting obligations for actively exploited vulnerabilities start on 11 September 2026, and the main obligations, including a documented vulnerability-handling process and update support for the product’s lifetime, apply from 11 December 2027. At the same time, the Linux kernel is now its own CVE Numbering Authority and issues thousands of CVEs a year, making frozen, unpatched vendor kernels hard to defend in an audit. Yocto’s create-spdx and cve-check classes already provide the SBOM and CVE-scanning tooling needed to meet these requirements.
The EU Cyber Resilience Act (CRA) stops being theoretical this year. From 11 September 2026, manufacturers who sell products with digital elements in the European Union must report actively exploited vulnerabilities and severe security incidents to the authorities. The full set of obligations applies from 11 December 2027. For embedded Linux teams, this changes what counts as a normal engineering skill: SBOM generation, CVE monitoring, and a working kernel update strategy are moving from optional to mandatory. This post looks at the evidence and at what it means for your day-to-day work.
What the Cyber Resilience Act requires, and when
The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. It applies to “products with digital elements” placed on the EU market, a definition that covers most connected embedded devices: industrial controllers, gateways, medical peripherals, consumer IoT, and the software inside them.
The timeline has two dates that matter for planning:
- 11 September 2026 — reporting obligations begin. Manufacturers must notify ENISA and their national CSIRT of actively exploited vulnerabilities and severe incidents, with an early warning due within 24 hours of becoming aware of the issue.
- 11 December 2027 — the main obligations apply. Products must be designed with security in mind, ship without known exploitable vulnerabilities, have a documented vulnerability-handling process, and receive security updates for a support period that reflects how long the product is expected to be in use.
💡 Key insight: These dates are market dates, not project-start dates. A device that is in development today and ships in 2027 ships into a regulated market. The compliance work has to be designed in now, not added at the end.
The kernel now produces its own CVE stream
The second piece of evidence comes from the kernel community itself. In February 2024, the Linux kernel became a CVE Numbering Authority (CNA), which means the kernel team now assigns CVE identifiers for its own fixes. The volume is large by design: the kernel CNA assigns a CVE for any fix that could plausibly be a vulnerability, and it does not attach severity scores. By Greg Kroah-Hartman’s own account, the kernel went from issuing no CVEs to being the largest CVE issuer by volume in 2025, with thousands of identifiers assigned per year.
This creates a direct tension with how many embedded products are still built. A common practice is to pin a vendor kernel at whatever version the BSP shipped with and leave it untouched for years. With thousands of kernel CVEs published annually, and a regulation that requires you to handle vulnerabilities in your product, that practice becomes difficult to defend. Reviewing each CVE by hand against a frozen kernel does not scale.
The kernel community’s answer is consistent: stay on a maintained stable or longterm (LTS) kernel and take the fix stream regularly. But note what kernel.org itself says about LTS lifetimes — each new longterm kernel usually starts with only a 2-year projected end of life, extended only if there is enough interest and testing support. Embedded products routinely live 10 to 15 years. Projects such as the Civil Infrastructure Platform maintain selected Super Long Term Support kernels for around a decade, and part of your platform decision is now matching your kernel choice to your product’s support period.
💡 Key insight: Upstream’s position is that the continuous fix stream is the security mechanism. Pinning an old kernel and cherry-picking individual patches is now measurably more expensive than tracking a maintained LTS branch — and it is the harder position to defend in a compliance audit.
The tooling has moved into the build system
The good news is that the mainstream embedded build systems already carry most of the mechanical work. The Yocto Project generates a Software Bill of Materials as part of a normal build: the create-spdx class produces SPDX documents for every recipe and merges them into an image-level SBOM, and recent releases have moved this output to the SPDX 3.0 format. Enabling it is one line in your configuration:
INHERIT += "create-spdx"Alongside it, the cve-check class compares the versions of every recipe in your image against published CVE data and reports which known vulnerabilities apply to your build. Buildroot users have an equivalent view through make pkg-stats, which includes CVE matching for packages. None of this is exotic tooling; it ships with the build systems most embedded Linux products already use.
💡 Key insight: Generating an SBOM is now a build-system feature, not an engineering project. The real work is what the SBOM exposes: every component it lists is a component you must be able to patch and re-deploy for the life of the product.
What this means for your skill set
Taken together — the Cyber Resilience Act’s fixed dates, a kernel that publishes thousands of CVEs a year, and build systems that make the state of your software visible — the direction is clear. Security maintenance is becoming a core competency of the embedded Linux engineer, not a task that belongs to a separate security or legal team. In practical terms:
- Know your build system’s security tooling. Be the person on the team who can enable and interpret
create-spdxandcve-checkoutput, and who can explain why a reported CVE does or does not apply to your image. - Have a kernel lifecycle plan. Choose an LTS or SLTS kernel with an end-of-life date that fits the product’s support period, and budget engineering time for taking stable updates on a schedule.
- Treat the update path as a launch requirement. A device that cannot receive updates in the field cannot meet a multi-year vulnerability-handling obligation. Secure, reliable OTA update capability belongs in the initial architecture.
- Build the documentation habit. The CRA expects technical documentation of your security posture. Records of what you shipped, what you patched, and why, are engineering artifacts now.
Doing this work well requires exactly the fundamentals that are easy to postpone: understanding how the kernel is versioned and maintained, how a BSP is assembled, and how the build system composes an image. Our Embedded Linux and Yocto training covers this ground for engineers building products on Linux.
Key takeaways
- The Cyber Resilience Act’s reporting obligations start on 11 September 2026; the main obligations apply from 11 December 2027.
- The Linux kernel is now its own CVE Numbering Authority and the largest CVE issuer by volume; frozen, unpatched product kernels are increasingly hard to justify.
- LTS kernels start with a 2-year projected EOL — match your kernel choice to your product’s support period, or plan for SLTS options.
- SBOM generation (
create-spdx) and CVE scanning (cve-check) are built into Yocto; learn to use and interpret them. - Field-updatable devices and documented vulnerability handling are becoming baseline engineering requirements, not optional extras.
Frequently asked questions
When do Cyber Resilience Act obligations start to apply?
Reporting obligations for actively exploited vulnerabilities and severe incidents begin on 11 September 2026. The main obligations, including secure design, a documented vulnerability-handling process, and update support, apply from 11 December 2027.
Why does a frozen vendor kernel become a compliance problem?
The Linux kernel became its own CVE Numbering Authority in February 2024 and now issues thousands of CVEs a year. Reviewing each one by hand against a kernel that is pinned and never updated does not scale, and it is hard to defend in a compliance audit.
How long do LTS kernels stay supported?
Each new longterm (LTS) kernel usually starts with only a 2-year projected end of life, extended only if there is enough interest and testing support, while embedded products routinely live 10 to 15 years. Projects such as the Civil Infrastructure Platform maintain Super Long Term Support (SLTS) kernels for around a decade to cover this gap.
What tools help generate an SBOM and check for CVEs in Yocto?
The Yocto Project’s create-spdx class generates an SPDX-format Software Bill of Materials as part of a normal build, and the cve-check class compares recipe versions in the image against published CVE data. Buildroot users get similar CVE matching through make pkg-stats.
