--
days to 11 Sep 2026
Embedded Linux on Edge-AI 23rd Sept 2026 enrollingLinux kernel & Device drivers starts on 24th Oct 2026 enrollingCorporate on-site training - Submit proposal Pick your modulesSharpen your kernel skills: deep dives, drivers, Yocto, CVEs, careers — updated daily. Read the blog →Embedded Linux fast track starts 23rd sept 2026 enrollingEmbedded Linux Mastery track starts 23rd sept 2026 enrollingLinux systems engineering starts 23rd sept 2026 enrolling
Free resource - compliance
What 11 September 2026 actually requires
The EU Cyber Resilience Act reporting obligations start on 11 September 2026 and apply to products already on the market. An SBOM and vulnerability-reporting checklist for teams shipping Linux devices.
2
deadlines, not one
24h
early-warning window
Reporting obligations begin11 September 2026Actively exploited vulnerabilities and severe incidents. Applies to products already on the market.
Two CRA dates matter and they are not the same date. On 11 September 2026 the reporting obligations begin. On 11 December 2027 the main obligations begin, and that is when the SBOM, the essential cybersecurity requirements and CE marking (the EU conformity mark on the product) bite. A great deal of published commentary treats September 2026 as the SBOM deadline. It is not. What starts in September is narrower, arrives sooner, and applies to products you shipped years ago.
Is the CRA in scope for you? Two questions. Do you make a product with digital elements available on the EU market? And is it outside the sectors with their own rules (medical devices, vehicles, aviation, marine)? Yes to both means the CRA applies to you. Not shipping anything yet? Read on anyway — this regulation is a large part of why teams keep hiring people who understand kernel maintenance.
The dates
There is not one CRA deadline, there are two
| Date | Milestone | What it means for a Linux device |
|---|---|---|
| 10 Dec 2024 | Entry into force | The clock starts. No obligations yet, but scope already covers most Linux devices. |
| 11 Sep 2026 | Reporting obligations begin | Report actively exploited vulnerabilities and severe incidents within the mandated windows. Applies to products already on the market. This is the date most teams underestimate. |
| 11 Dec 2027 | Main obligations | Essential requirements, vulnerability handling, SBOM, conformity assessment and CE marking. |
The part teams miss. The September 2026 reporting duty is not limited to new products. It covers products with digital elements already made available on the EU market before the CRA fully applies. A device you shipped in 2023 and have not thought about since is in scope for reporting, whether or not you can still update it.
The windows
What you must report, and how fast
Two triggers. An actively exploited vulnerability means evidence of real attacks, not theoretical exploitability. A severe incident is one that impairs, or may impair, the confidentiality, integrity, availability or authenticity of the product.
| Stage | Deadline | Notes |
|---|---|---|
| 24 hours | Early warning | From becoming aware. This is a clock you cannot meet without a rota. |
| 72 hours | Full notification | From becoming aware. |
| 14 days | Final report | After a corrective measure is available, for exploited vulnerabilities. |
| 1 month | Final report | For severe incidents. |
Reporting happens once, through the CRA Single Reporting Platform, which ENISA (the EU cybersecurity agency) is building under Article 16 and which the Commission states will be operational by 11 September 2026 with a testing period beforehand. The notification goes to the CSIRT (the national incident-response team) where you have your main establishment, and is shared with ENISA and with the CSIRTs of the other territories where the product is available. A delegated act adopted on 11 December 2025 sets out the narrow grounds on which a CSIRT may delay onward dissemination.
Getting ready
Are you ready? Four workstreams
A
Know what you have on the market
You cannot report for a product you have forgotten you sold. This is usually the longest task, and it is why starting late hurts.
- List every product with digital elements available on the EU market, including discontinued lines still in service.
- For each, record the software it ships: kernel version, bootloader, userspace, and third-party components (on Yocto, the
create-spdxclass generates this inventory at build time). - Identify who inside the company would learn first that one of them is being exploited.
- Record whether each product can still receive an update, and if not, say so explicitly.
Proof it worked: A list that someone outside engineering can read, naming a responsible person per product.
Where this goes wrong: Products sold through distributors or as white label are still yours as manufacturer. Being invisible in your own CRM does not remove them from scope.
B
Build the 24-hour path before you need it
The early warning window is 24 hours from awareness. That is an operational commitment, not a documentation exercise.
5 checks, the proof and the failure modes — in the full checklistEnter your email for the full version →C
Know which vulnerabilities are actually yours
A Linux device inherits thousands of CVEs it is not affected by. Without a way to say so, every advisory becomes a fire drill.
4 checks, the proof and the failure modes — in the full checklistEnter your email for the full version →D
Prepare for December 2027 while you are here
The main obligations are further off but slower to satisfy, and several of them are decisions about product architecture rather than paperwork.
4 checks, the proof and the failure modes — in the full checklistEnter your email for the full version →Underneath it all
The kernel question underneath all of this
Most of the CRA work on a Linux device reduces to one question: can you still get fixes for what you shipped. The answer is public. Every longterm kernel series has a projected end-of-life date on the kernel.org releases page; find the series each of your products ships and note the date its upstream fixes stop. Set those dates against the support period you intend to declare. Where a date falls short, the gap is yours to close, and it is far cheaper to discover that in this checklist than after a report lands. And if you do not ship products yet: this same question is why employers keep hiring people who can maintain a kernel after the vendor moves on.
Sources. European Commission, Cyber Resilience Act — Reporting obligations and Cyber Resilience Act, both read 20 July 2026. Dates and durations above are taken from those pages. This is a working checklist, not legal advice; scope questions for your specific product belong with your counsel.
Rather have this done than read about it? TECH VEDA runs vulnerability response and CRA readiness as an engineering service: an SBOM generated from your build, the 24-hour reporting path rehearsed with your people, and a kernel patch cadence your support period can survive.See the service Discuss your product
Take the readiness pack with you
The complete version, laid out to print and keep. This one changes, so you can have the revision when the facts behind it move.
No mailing list, no spam. Only change-alerts you opted into.
Recent security advisories
Keep going
Linux Kernel CVEs: What to Patch by Device (2 – 8 Aug 2026) →
8 Aug 2026 — 46 Linux kernel CVEs (2–8 Aug 2026) with the minimum safe version per branch — including CVE-2026-64562, CVE-2026-68480 and what…
Linux Kernel CVEs: What to Patch by Device (26 Jul – 1 Aug 2026) →
1 Aug 2026 — 33 Linux kernel CVEs published 26 July-1 August 2026, all fixed in stable. Critical remote NVMe/TCP, SMC and SCTP bugs,…
Open-Source Device CVEs: What to Patch by Vertical (July 2026) →
31 Jul 2026 — Open-source device CVEs for July 2026: 22 patchable flaws in U-Boot, OpenSSH, curl, FFmpeg, GStreamer, containerd and Node.js, and what…