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.
What actually has to be reported
Two terms decide the scope of the reporting duty, and they are worth reading precisely, because informal summaries make them sound much broader than they are.
An actively exploited vulnerability is a vulnerability in your product that is being used in an attack. A vulnerability you discover and fix before anyone exploits it is handled through your ordinary vulnerability-handling process, not through this reporting channel.
A severe incident is narrower still. The regulation describes an incident having an impact on the security of a product with digital elements as one that negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of data or functions. The severe qualifier tightens this further: the data or functions involved are sensitive or important, or the incident can lead to malicious code being introduced into or run on the product or on a user’s networks and information systems. Routine bugs and ordinary patches are outside the reporting duty entirely.
The reporting deadlines run from the moment you become aware: an early warning within 24 hours, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available for an actively exploited vulnerability, or within one month of the 72-hour submission for a severe incident. Notifications go through the CRA Single Reporting Platform that ENISA is required to establish under Article 16, addressed to the CSIRT of the member state where the manufacturer has its main establishment and to ENISA.
💡 Key insight: The reporting obligations apply to products already made available on the Union market, including those placed on it before December 2027. A device you shipped in 2024 and have not touched since is in scope from September 2026. The transitional relief that exists for the 2027 requirements does not extend to reporting.
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 since the Styhead (5.1) release this output is in the SPDX 3.0 format. On current releases you do not need to switch it on — the class is inherited by default through INHERIT_DISTRO, and you would have to remove it deliberately:
INHERIT_DISTRO:remove = "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. On the 5.0 (scarthgap) LTS release it is enabled with INHERIT += "cve-check"; in the current development series it has moved to sbom-cve-check, enabled through the core/yocto/sbom-cve-check configuration fragment. 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.
- Only actively exploited vulnerabilities and severe incidents are reportable — routine bugs and ordinary patches are not. Reporting covers products already on the market, including those shipped before 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.
What counts as a severe incident under the CRA?
The regulation describes an incident having an impact on the security of a product as one that negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of data or functions. The severe qualifier means the data or functions involved are sensitive or important, or that the incident can lead to malicious code being introduced into or run on the product or on a user’s networks.
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.
Further reading
- European Commission — Cyber Resilience Act
- European Commission — Summary of the legislative text
- European Commission — CRA reporting obligations
- Open Regulatory Compliance Working Group — CRA resources
- kernel.org — Active kernel releases and longterm support
- Greg Kroah-Hartman — Linux Kernel Monkey Log (kernel CNA and CVE volume)
- Yocto Project documentation — Creating a Software Bill of Materials
