24 Hours to Report. Unless the Code Isn’t Reachable?

On 11 September 2026, the first operative part of the EU Cyber Resilience Act switches on. From that date, manufacturers of products with digital elements placed on the EU market must report actively exploited vulnerabilities to ENISA and their national CSIRT — with an early warning due within 24 hours.

Most coverage of this stops at the deadline. If you ship a product built on Linux, the deadline is not the hard part. The hard part is the question underneath it: the kernel CNA now mints thousands of CVEs a year, in a component you integrate rather than write. When one of them is exploited somewhere in the world, does your 24-hour clock start?

On 27 July 2026 the Commission published its first official guidance on applying the CRA. It answers that question directly — and the answer is narrower, and considerably more favourable to manufacturers who understand their own build, than the panic-adjacent reading suggests.

What actually starts on 11 September

Article 14(1) and (3) of the CRA require a manufacturer to notify, simultaneously, the CSIRT designated as coordinator and ENISA of two categories of event: any actively exploited vulnerability contained in its product that it becomes aware of, and any severe incident having an impact on the security of the product that it becomes aware of. Reports are filed through ENISA’s CRA single reporting platform.

Stage	Actively exploited vulnerability	Severe incident
Early warning	Within 24 hours of becoming aware	Within 24 hours of becoming aware
Notification	Within 72 hours of becoming aware	Within 72 hours of becoming aware
Final report	Within 14 days after a corrective or mitigating measure is available	Within one month of the 72-hour notification

Nothing else in the CRA applies yet. The essential requirements in Annex I, the vulnerability-handling obligations, the SBOM, CE marking — those land on 11 December 2027. Between now and then, Article 14 stands alone.

It covers products you shipped years ago

This is the provision that catches people, and it is worth stating plainly. Products placed on the market before 11 December 2027 are otherwise outside the CRA unless they undergo a substantial modification. Article 69(3) carves the reporting duty back in. The Commission’s guidance is explicit:

So the scope is your entire installed base, not the products currently in development. Two consequences follow. The obvious one: an appliance you shipped in 2021 and stopped supporting in 2024 is still in scope for reporting. The less obvious one, from the same paragraph: those legacy products carry no Annex I Part II vulnerability-handling duty at all. For the installed base, reporting is the only live obligation — you are not obliged to patch a product whose support period has ended, but you are obliged to report active exploitation of it.

A proof-of-concept is not an actively exploited vulnerability

The trigger is defined narrowly. Article 3(42):

Three things that look alarming and are not this: a public exploit on GitHub, a conference talk with working code, and a CVSS 9.8. None of them is evidence that anyone ran the exploit against a real system without permission. Good-faith research, testing and coordinated disclosure sit outside the definition by design.

What is reliable evidence: your own incident telemetry, a customer forensic report, a CSIRT or vendor advisory describing in-the-wild abuse of your product. A PoC is not the trigger — it is the leading indicator that the trigger may be coming, which is a reason to have your analysis ready, not a reason to file.

KEV proves exploitation — of the component, not of your product

This is the distinction most likely to be collapsed in practice, and collapsing it is expensive in both directions. A CISA KEV entry for a Linux kernel CVE is reliable evidence that the vulnerability is being exploited somewhere, in someone’s deployment. It is not evidence that it is being exploited in your product — and § 218 is unambiguous that the latter is what the duty attaches to. Article 14 speaks throughout of an actively exploited vulnerability contained in the product, and § 213 sets the awareness threshold at reasonable certainty that “a vulnerability contained in its product with digital elements is being actively exploited”.

So an upstream kernel CVE landing in KEV is an ecosystem signal that starts your investigation, not a filing deadline. It obliges you to establish promptly whether the vulnerable code is in your build, whether it is reachable there, and whether anything indicates your product is among what is being attacked. If the first two answers are no, limb (i) applies and there is nothing to report. If they are yes but nothing points at your product, you are on limb (ii) — not reportable, and squarely on your watch list.

That line is cleanest for a bounded product — an appliance, a controller, a device image — where “is this us?” has a factual answer. It is harder for a general-purpose distribution, where a report of exploitation “against Linux servers” may well be describing your users. Where it is genuinely ambiguous, the voluntary notification route in Article 15 exists so that erring toward disclosure does not require pretending the mandatory test was met.

The part that matters if you ship Linux

Here is the fear, stated honestly: you integrate a kernel with several thousand known CVEs against it. A kernel bug gets exploited in the wild against cloud hosts. The same code is in your image. Do you now owe a filing every time that happens?

No. § 218 of the Commission’s guidance addresses this exact situation:

Read the two limbs carefully, because they are alternatives — either one is enough to take a vulnerability out of mandatory reporting.

Limb	What it means	How durable it is
(i) Cannot be exploited in your product	The driver is not built, the option is unset, the code path is not reachable, or the bug is not triggerable under the conditions your product actually runs in.	Durable. A property of your build. It does not change because the outside world changed.
(ii) Has not been exploited in your product	The vulnerable code may well be reachable — but no one has been observed attacking your product through it.	Fragile. A fact about the world. It can end overnight, and the first you hear of it may be a customer’s forensics report.

Limb (ii) is the one most products are quietly relying on today, and it is the one that expires without warning. Limb (i) is the one you can establish in advance and still be holding when the news breaks.

The regulation backs the engineering argument

Limb (i) is not a loophole read into the text — it tracks a definition in the regulation. Article 3(41) defines an exploitable vulnerability as “a vulnerability that has the potential to be effectively used by an adversary under practical operational conditions”, and the guidance draws the consequence:

For a Linux-based product this is the difference between a CVE list and an answer. “CONFIG_SMB_SERVER is not set, so ksmbd is not in this image” is a statement about practical operational conditions. So is “this bug requires an unprivileged local user, and this appliance has no interactive local accounts and runs no untrusted workloads.” Both are checkable claims about a specific build. Neither is a matter of opinion.

“Becoming aware” is not “saw a headline”

The 24-hour clock is less brutal than it reads, because it does not start at first rumour. The guidance sets the threshold at the end of an initial assessment:

§ 235 makes the same allowance from the other direction: “the mere fact that a vulnerability is reported or found does not, in itself, mean that it is exploitable in practice or applicable to the specific product… Accordingly, a limited period of time may elapse between the first report of the vulnerability and its confirmation.”

That window is for investigating, not for waiting. § 214 puts the emphasis “on prompt action to carry out the initial assessment”. A team that can answer “is this reachable in our build?” in an hour is compliant and calm. A team that needs a week of kernel archaeology per CVE is neither — and will end up filing defensively, which has its own costs.

One relief worth knowing: § 217 confirms there is no retroactive reporting. Active exploitation you already knew about before 11 September 2026 does not need to be filed. But if you knew of a vulnerability without knowing of exploitation, and exploitation surfaces afterwards, it becomes reportable.

Not reportable still isn’t nothing

§ 218 is careful about what a “not reachable” determination buys you: exemption from mandatory reporting, and nothing more. The same paragraph lists what survives.

One timing point before the detail: unlike Article 14, none of what follows starts on 11 September. Article 13 and Annex I apply from 11 December 2027. This is what your programme has to be built for, not what you owe in ten days’ time.

Reporting upstream — to your supplier or the maintainer

Article 13(6) requires manufacturers, on identifying a vulnerability in a component integrated in their product, to report it to the person or entity manufacturing or maintaining that component. Both halves of that phrase do work, and it is easy to read this as an open-source duty when it is not:

• Bought-in commercial components — a licensed protocol stack, a vendor BSP, a third-party library you pay for — are reported to your supplier.
• Open-source components are reported to the project maintainer, or to the open-source steward where the project has one. The CRA gives stewards their own reporting duty for actively exploited vulnerabilities under Article 24(3), and § 216 of the guidance notes that stewards will typically learn of exploitation precisely this way — from a downstream manufacturer who detected it in an integrated component.

Note how much wider this net is than Article 14’s. The trigger is identifying a vulnerability, not active exploitation — so it catches exactly the ones you determined were not reachable and never had to report.

It is not unbounded, though. The guidance sets four real limits:

• Only the version you integrate (§ 223) — not every release of the component.
• Not if they already know (§ 223). “manufacturers are not required to report upstream where they can confirm that the person or entity manufacturing or maintaining a component is aware of the existence of a vulnerability.” You are encouraged to check public vulnerability databases, project advisories and issue trackers first, to avoid duplicate reports.
• Only vulnerabilities in the component itself (§ 224) — not ones that exist because of how you integrated it. Where your integration surfaces behaviour that was not apparent in isolation, sharing it is encouraged rather than required.
• Not if there is nobody to report to (§ 225) — the component is unmaintained, or you no longer rely on that maintainer. You are then encouraged to use community mechanisms or public vulnerability records instead.

Sharing the fix

Where you have developed a modification that addresses a vulnerability in an integrated component, Article 13(6) also requires you to share it upstream. The guidance is unusually practical about what that does and does not mean:

• Provide it, where appropriate, in a machine-readable form that can be easily verified and integrated (§ 227).
• For open-source components, share it compatibly with the component’s licence — under the same licence, or one that lets the maintainer redistribute it — and follow the project’s contribution guidelines where it has them (§ 227).
• You are not required to get your fix accepted or merged, and you are not required to accept the maintainer’s fix in return — either side may prefer a different approach (§ 228).
• If upstream has already shipped a fix and you mitigated differently — a configuration change on your side, say — you do not have to push that mitigation upstream (§ 229).

The rest of what survives

• Handle it anyway. The Annex I Part II vulnerability-handling requirements apply to in-scope products from December 2027, independently of whether anything was ever reportable.
• You may file voluntarily. Article 15 provides for voluntary notification, which is worth knowing about for the genuinely ambiguous cases.

And when you do report, Article 14(8) requires you to inform impacted users. That is less alarming than it sounds: § 220 states the duty is to be applied in a risk-based and proportionate manner, and that it “does not imply that such information must be made public or disclosed indiscriminately” — you may limit detail to the affected customers, expressly so for products used in sensitive or essential environments.

What this means for a Linux product team

Strip the legal vocabulary away and Article 14 asks a Linux vendor for one operational capability: on any given day, for any given CVE, for every image you have ever shipped, state whether the vulnerable code is in it and reachable — and be able to show your working.

Three properties make that answer useful rather than decorative:

• It has to pre-exist the event. Deriving a per-image reachability determination from scratch, under a 24-hour clock, on the day a kernel bug hits the news, is how teams end up over-reporting to be safe.
• It has to be reproducible. “Our security lead judged it not applicable” is not evidence. “CONFIG_IP_SCTP is unset in this build, the fix commit touches only net/sctp/, therefore the code is not compiled in” is.
• It has to be dated. Article 69(3) put your whole installed base in scope. A determination is about a specific build at a specific time, and a market surveillance authority asking questions in 2028 will be asking about a decision you made in 2026.

And if you build your own tree

Yocto and Android make this concrete. The Yocto Project and AOSP publish FOSS for others to integrate; at most they are stewards under Article 24. Responsibility for the device sits with whoever places it on the market under their own name — you. § 49 puts FOSS under the responsibility of those who “publish it and exercise primary control over its development, releases, and distribution decisions”, and integrating a component never transfers that (§§ 86–87).

Which is where a forked tree stings. Your BSP patches and out-of-tree drivers are not part of anyone else’s component — § 224 excludes vulnerabilities arising from your own integration from the upstream duty, so they are yours alone, carried by no CVE feed and fixed by no maintainer. And on a vendor tree that has backported some fixes and skipped others, the version string stops being evidence of anything. Limb (i) is a claim about your build; only your build can support it.

Where KernelScan fits

This is the analysis KernelScan was built to produce, and the Commission’s guidance has now written its central argument into the official interpretation of the regulation.

You upload the kernel .config for a product. KernelScan maps each CVE’s fix commit to the source files it touches, maps those files to the Kconfig options that compile them, and evaluates those options against your build. The output is a per-CVE verdict — affected, or not affected with a stated justification such as code not reachable — delivered as a CycloneDX VEX document you can archive, diff and hand to an auditor.

Three things about that pipeline matter specifically for Article 14:

• The verdict is deterministic, not inferred. No machine-learning component participates in the affected / not-affected decision. Identical inputs produce identical outputs, which is what makes the determination something you can defend rather than merely assert.
• It runs continuously, per product. The determination for a new CVE exists before anyone attacks it, which is the difference between limb (i) and a 24-hour scramble.
• Exploit and PoC intelligence is tracked separately. Public exploit code does not change a verdict — correctly, since a PoC is not active exploitation — but it is exactly the signal that tells you which reachable CVEs are candidates to lose limb (ii). That is your watch list.

None of this makes anyone CRA-compliant on its own; compliance is a programme, not a report. What it does is turn the question Article 14 asks into one you can answer from evidence, on the day, instead of from memory.

References — official EU sources

• The regulation. Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), OJ L, 2024/2847, 20.11.2024. Provisions cited: Art. 3(40)–(42) (definitions), Art. 13(6) (upstream reporting of component vulnerabilities), Art. 14 (reporting obligations), Art. 15 (voluntary notification), Art. 24(3) (open-source steward reporting), Art. 69(3) (transitional provisions), Annex I Part II (vulnerability handling). eur-lex.europa.eu/eli/reg/2024/2847/oj
• The Commission guidance. Commission Decision C(2026) 5252 final of 27 July 2026 and its Annex, “Commission guidance on the application of the Cyber Resilience Act”, issued under Art. 26(1) CRA. Paragraphs cited: §§ 47–49 and §§ 85–88 (responsibility for free and open-source components), §§ 209–221 (reporting obligations), §§ 222–229 (reporting upstream and sharing security fixes) and §§ 230–237 (known exploitable vulnerabilities). digital-strategy.ec.europa.eu
• Commission reporting overview. “Cyber Resilience Act — Reporting obligations”, European Commission, Shaping Europe’s digital future. digital-strategy.ec.europa.eu/en/policies/cra-reporting

Notes

• The Commission guidance is non-binding. It states the Commission’s interpretation and is the clearest available signal of how these provisions will be applied, but only the Court of Justice of the European Union can rule definitively on the meaning of the regulation.
• This article is a reading of published regulatory texts for a technical audience. It is not legal advice. Decisions about your own reporting posture — in particular any determination that a vulnerability is outside mandatory reporting — should be taken with your own counsel.
• KernelScan verdicts (affected / not affected per kernel configuration) are produced by deterministic analysis: CVE fix commits are mapped to source files, source files to the Kconfig build options that compile them, and those options evaluated against the uploaded .config. No machine-learning component participates in this verdict; identical inputs produce identical, auditable outputs.