Known is not exploited

Article 13(6) applies with no exploitation needed

Regulation Article 13(6):

“Manufacturers shall, upon identifying a vulnerability in a component, including in an open source-component, which is integrated in the product with digital elements report the vulnerability to the person or entity manufacturing or maintaining the component, and address and remediate the vulnerability in accordance with the vulnerability handling requirements set out in Part II of Annex I.”

The same paragraph continues: where you have developed a software or hardware modification to fix it, you “shall share the relevant code or documentation” with that person or entity, “where appropriate in a machine-readable format”.

So identifying the vulnerability is enough to create three duties: report it upstream, remediate it, and share your fix. Nobody has to have attacked anything.

Regulation Annex I Part II sets out what that remediation sits inside. Manufacturers shall:

• “identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products” (Part II(1));
• “address and remediate vulnerabilities without delay, including by providing security updates” (Part II(2)).

Guidance The Commission’s Article 26 guidance (C(2026) 5252, paras 222–229) narrows the upstream-reporting duty:

• You report “only in respect of the version of the component that they integrate” (para 223).
• You need not report where you “can confirm that the person or entity manufacturing or maintaining a component is aware of the existence of a vulnerability”; where the maintainer has its own disclosure process or reporting channel, use it (para 223).
• You report only vulnerabilities “that exist in the integrated component itself”, not ones created by your integration (para 224).
• There is no upstream report where the component “no longer has a maintainer”, or where you no longer rely “on the original maintainer for new versions or security fixes” — though you are encouraged to tell the component’s users another way (para 225).
• You must share your fix, but the CRA does not require the maintainer to accept it (para 228).

“Known” before you ship is a third concept

Regulation Separately from both articles, Annex I Part I(2)(a) requires products, “on the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable”, to “be made available on the market without known exploitable vulnerabilities”. 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”.

Guidance The Article 26 guidance says a vulnerability “should be regarded as known when it is listed in relevant publicly accessible vulnerability databases, such as the European vulnerability database established by Article 12(2) of Directive (EU) 2022/2555 or other prominent vulnerability databases” (para 233). It adds that “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 with digital elements concerned” (para 235).

Interpretation A CVE record is the obvious example of a listing in a prominent database. So a published CVE does have CRA consequences: it feeds your release decision under Annex I Part I(2)(a) and your vulnerability handling under Part II. It does not feed Article 14.

Source: Reg (EU) 2024/2847 — Article 3(41); Article 13(6); Annex I, Part I(2)(a) and Part II(1)–(2). Commission guidance C(2026) 5252, paras 222–229, 233, 235.

Article 14 applies only on active exploitation

Regulation Article 14(1):

“A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA. The manufacturer shall notify that actively exploited vulnerability via the single reporting platform established pursuant to Article 16.”

Regulation Article 3(42) defines the trigger:

“‘actively exploited vulnerability’ means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner”

Regulation Article 14(2) sets three deadlines:

After becoming aware, you must also inform “the impacted users of the product with digital elements, and where appropriate all users” (Article 14(8)). Guidance The Article 26 guidance says this duty “is to be applied in a risk-based and proportionate manner” and “does not imply that such information must be made public or disclosed indiscriminately” (para 220) — which matters for OT products in sensitive environments.

Regulation You submit through the electronic notification end-point of the CSIRT coordinator in the Member State of your main establishment in the Union (Article 14(7)). Article 14 applies from 11 September 2026; the rest of the Regulation from 11 December 2027 (Article 71(2)). Article 14 is already in force — and it reaches legacy products too. Article 69(3): “the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027.”

Guidance The Article 26 guidance adds three points:

• Reporting obligations “continue to apply after a product with digital elements is no longer supported” (para 210).
• For products placed on the market before 11 December 2027, or whose support period has ended, the Annex I Part II vulnerability-handling obligations do not apply (para 210; FAQ §5.3 says the same of legacy products).
• Reporting is not retroactive: you do not report exploitation you were already aware of before 11 September 2026 — but a vulnerability you knew about before that date becomes reportable if you become aware of its active exploitation afterwards (para 217).

“Known” is not “actively exploited”

Regulation The Article 14 trigger is reliable evidence that a malicious actor has exploited the vulnerability (Article 3(42)). A CVE record is evidence that a vulnerability exists. By itself it is not evidence that anyone has exploited it.

Guidance FAQ §5.2 draws the same line. A zero-day found by ethical hackers through a bug-bounty programme, or by a laboratory testing on your behalf, “for which there is no evidence of previous malicious exploitation”, “is not an actively exploited vulnerability subject to mandatory reporting”. You may still notify it voluntarily under Article 15.

Guidance On when awareness starts, the Article 26 guidance says a manufacturer “should assess the suspicious event immediately”, and “is therefore to be regarded as having become aware when, after such an initial assessment, it has a reasonable degree of certainty that … a vulnerability contained in its product with digital elements is being actively exploited” (para 213). “The emphasis should be on prompt action to carry out the initial assessment” (para 214).

Interpretation Treat these signals as a reason to run triage now: a vendor advisory saying “exploited in the wild”, an entry in a government known-exploited-vulnerabilities catalogue, a customer reporting compromise. Unlike a CVE record, each can be reliable evidence that someone is exploiting the vulnerability. Section 03 explains why, on the Commission’s reading, you then still have to establish whether it is being exploited in your product. Date and record that assessment.

Source: Reg (EU) 2024/2847 — Article 3(42); Article 14(1), (2), (7), (8); Article 15; Article 16; Article 69(3); Article 71(2). Commission guidance C(2026) 5252, paras 210, 213–214, 217, 220. Commission FAQs on the CRA v1.4, §§5.2–5.3.

The open-source twist: exploited where?

Regulation Two phrases do different jobs. “Contained in the product with digital elements” (Article 14(1)) decides which vulnerabilities are in scope: the ones in your product. “Exploited it in a system” (Article 3(42)) describes what the evidence must show — and the definition does not say whose system.

Guidance FAQ §5.4 applies Article 14 to integrated components:

“Where the product with digital elements contains an actively exploited vulnerability originating from an integrated component, the manufacturer of the product with digital elements is required to notify that vulnerability. The manufacturer of the integrated component is also required to notify it, if that component has been placed on the market.”

Guidance The Article 26 guidance, adopted on 27 July 2026, goes further than the FAQ on where the exploitation must happen (para 218):

“if a manufacturer is aware that a third-party component contains a vulnerability, but that vulnerability either (i) cannot be exploited in its product with digital elements (e.g. because the vulnerable code is not reachable) or (ii) has not been exploited in its product with digital elements, that vulnerability does not qualify as an actively exploited vulnerability contained in its product with digital elements, and therefore it is not subject to mandatory reporting for that manufacturer.”

You may still notify such a vulnerability voluntarily under Article 15, and you must still handle it under Annex I Part II and report it upstream under Article 13(6) (para 218).

On the Commission’s reading, then, exploitation of the same open-source library in someone else’s product does not by itself start your 24-hour clock: the exploitation has to be in your product. When a widely shipped library is exploited, each manufacturer whose product has been exploited — and which becomes aware of it — files its own notification. Your notification does not cover the next vendor’s, and theirs does not cover yours.

Interpretation Treat para 218(ii) as the working rule, but note what it rests on: the Regulation’s own definition says “in a system”, not “in your product”, and only the Court of Justice interprets the Regulation authoritatively. So when you learn that a library you ship is being exploited elsewhere, do not file it as “not reportable” and move on. Ask three questions, in order:

1. Can it be exploited in our product? The version we ship, whether the vulnerable code is reachable, the configuration we ship. If not: record the determination and the reasons, report upstream, handle it under Annex I Part II. Nothing goes to Article 14.
2. If it can, is there reliable evidence it has been exploited in our product? Customer reports, our telemetry, incident data from our installed base. Paras 213–214 expect a prompt initial assessment.
3. If yes, Article 14 applies — the 24-hour clock runs from the point your assessment reaches a “reasonable degree of certainty”. If there is no such evidence yet, keep investigating, and consider a voluntary Article 15 notification where the risk justifies it.

Regulation Do not expect the open-source project to carry this for you yet. Article 24(3) extends Article 14(1) to open-source software stewards “to the extent that they are involved in the development of the products with digital elements”, and Article 14(3) and (8) only where severe incidents affect network and information systems they provide for that development. Guidance FAQ §5.5 notes that, under Article 71(2), Article 24(3) applies only from 11 December 2027; the Article 26 guidance adds that a steward’s duty applies “upon becoming aware of an actively exploited vulnerability, and not merely where a vulnerability exists in the codebase” (para 216).

Source: Reg (EU) 2024/2847 — Article 3(42); Article 13(6); Article 14(1); Article 15; Article 24(3); Article 71(2). Commission guidance C(2026) 5252, paras 213–214, 216, 218. Commission FAQs on the CRA v1.4, §§5.4–5.5.

You need not watch the dark web — but you cannot skip identification

Guidance FAQ §5.1 lists ways a manufacturer might become aware — customers, threat-intelligence reports, government agencies, telemetry, dark-web monitoring — and then says: “this does not imply that the manufacturer is required to carry out such activities or monitor such channels to comply with the reporting obligations.”

Guidance The FAQ’s own footnote to that sentence adds that Annex I Part II still requires, among other things, “a single point of contact where vulnerabilities can be reported”, a coordinated vulnerability disclosure policy, and measures to share information about potential vulnerabilities.

Regulation Separately — and not relieved by §5.1 — Annex I Part II(1) requires you to “identify and document vulnerabilities and components contained in products”, including through a software bill of materials.

Interpretation Article 14 does not make you hunt for evidence of exploitation. Annex I does make you know what is in your product and which vulnerabilities it carries. A manufacturer with no SBOM cannot answer the first question in section 03 quickly — and speed matters, because awareness follows a prompt initial assessment.

Source: Reg (EU) 2024/2847 — Annex I, Part II(1). Commission FAQs on the CRA v1.4, §5.1 and footnote 9. Commission guidance C(2026) 5252, paras 213–214.

Build environments: a separate track, with a different final-report deadline

Interpretation A CVE in a development tool you use but do not ship — a compiler plugin, a CI runner — is not “contained in the product with digital elements” in the Article 14(1) sense, so on its own it is not an Article 14 vulnerability notification. This is our reading; the Regulation does not address development tooling directly.

Regulation A compromised build that taints what you ship is a different matter. Article 14(3) requires notification of any severe incident having an impact on the security of the product, and Article 14(5)(b) treats an incident as severe where it “has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product with digital elements.”

The 24 h and 72 h stages match the vulnerability track (Article 14(4)(a)–(b)); the final report does not:

Interpretation One event can open both tracks — a poisoned dependency that is then exploited in the field. Run them as two notifications with two final-report deadlines; do not merge them into one “CRA report”.

Source: Reg (EU) 2024/2847 — Article 14(1)–(5).

The IEC 62443-4-1 bridge: one column covered, one not

For OT and ICS manufacturers already running an IEC 62443-4-1 secure development lifecycle, the useful question is what the CRA adds. Checked against the text of the standard:

An IEC 62443-4-1 lifecycle gets you most of Article 13(6). It does not get you Article 14.

Interpretation The regulator notification, the fixed clock and the mandatory user information all have to be added on top — and DM-3 is the natural place to hook them in.

Source: IEC 62443-4-1:2018 — SM-7, SM-9, DM-3, DM-4, DM-5. Reg (EU) 2024/2847 — Article 13(6); Article 14; Annex I, Part II.

What a reviewer should be able to see

For each open-source vulnerability affecting a shipped product, a CRA reviewer should be able to find:

1. The SBOM entry showing the component and the version you ship (Annex I Part II(1)).
2. The upstream report — or the reason there is none: the maintainer was already aware, there is no maintainer, you no longer rely on upstream, or the issue arises only from your integration (Article 13(6); guidance paras 223–225).
3. The remediation decision and the security update or mitigation (Annex I Part II(2)).
4. The exploitability determination for your product — version shipped, reachability, configuration (FAQ §5.4; guidance para 218).
5. The exploitation assessment — the evidence considered, where the exploitation was observed, date and time, and whether it reached a “reasonable degree of certainty” of exploitation in your product (Article 3(42); guidance paras 213 and 218).
6. If Article 14 was triggered — the awareness timestamp, the 24 h, 72 h and final-report submissions (Article 14(2)), and the user communication (Article 14(8)).
7. Any severe-incident track kept separate, with its own one-month final report (Article 14(4)(c)).

The CRA Workbench and the free 24·72 tool are built around this record. They indicate the evidence needed and draft the paperwork for your own expert review; they do not decide on your behalf whether a vulnerability is exploited, and they do not guarantee compliance.