Skip to content
CRA Reporting Desk

CRA Article 14 for third-party components: who reports

Most Article 14 cases will start in someone else's code — a chip SDK, a middleware library, a firmware blob. The question manufacturers ask first is whether every integrator must flood the Single Reporting Platform. Commission FAQ 5.4 answers that with a product test, not a component census.

The short version

  • Article 14(1): you notify an actively exploited vulnerability contained in your product that you become aware of.
  • FAQ 5.4 — exploited in your product: if the AEV originates in an integrated component, you still notify; the component maker notifies too if that component was placed on the market.
  • FAQ 5.4 — not exploitable in your product: not mandatory Article 14; voluntary Article 15 remains open; upstream Article 13(6) still points at the maintainer.
  • Same clocks when Art 14 bites: 24-hour early warning, 72-hour notification, then the final-report rules — from your awareness, not from the component vendor's press release.
Track your Article 14 clockOpen the deadline calculator

Components are products too (when placed separately)

Article 3(1) defines a product with digital elements as a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately. Article 3(6) defines a component as software or hardware intended for integration into an electronic information system. So a separately marketed library, SoC, or module can have its own manufacturer with its own Article 14 duty. That does not pull every downstream assembler into a filing solely because they listed the part on an SBOM.

FAQ 5.4: the integrating manufacturer's test

Commission CRA implementation FAQ entry 5.4 (ORC WG mirror of the official FAQs) states the rule in two limbs. First: manufacturers must notify any actively exploited vulnerability contained in their product. Where that product contains an actively exploited vulnerability originating from an integrated component, the manufacturer of the product 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. Second: if you are aware that an integrated component contains a vulnerability, but that vulnerability cannot be exploited in your product, it is not actively exploited for that product and is not subject to mandatory reporting. You may still notify voluntarily under Article 15, and you are required to report the vulnerability to the person or entity manufacturing or maintaining the component under Article 13(6).

Article 13(6) is upstream — not a substitute for the SRP

Article 13(6) says that upon identifying a vulnerability in a component integrated in the product — including open-source — the manufacturer shall report it to the person or entity manufacturing or maintaining the component, and address and remediate it in line with Annex I Part II. Where you develop a software or hardware modification, you share the relevant code or documentation with that maintainer where appropriate, preferably in a machine-readable format. That is a supply-chain conversation. It is not the Article 14 early warning to the coordinating CSIRT and ENISA via the Single Reporting Platform. When FAQ 5.4's first limb applies, both tracks can run at once.

Application-date caution: Article 14 has applied since 11 September 2026 (Article 71(2)). Article 13 and Annex I Part II vulnerability handling generally apply from 11 December 2027. FAQ 5.4 still cites Article 13(6) for the non-exploitable-in-you case — keep that split in your playbook, and confirm with counsel how the Art 13 limb binds your catalogue before December 2027.

Open-source components vs open-source stewards

Integrating a free and open-source component into a commercial product does not make you an open-source software steward. Steward reporting under Article 24(3) starts on 11 December 2027 and is scoped differently — see Article 14 for open-source stewards. Manufacturers who ship FOSS inside their products still face Article 14 from 11 September 2026 when the actively-exploited or severe-incident tests are met, including where the root cause is an upstream OSS component. Separately, a third-party cloud you integrate is not automatically your remote data processing solution — see Article 14 for SaaS and remote data processing.

Same Article 14 clocks once awareness hits your product

Early warning within 24 hours, fuller notification within 72 hours, then the final report (14 days after a corrective or mitigating measure is available for an exploited vulnerability; within one month after the 72-hour notification for a severe incident). Overview: reporting deadlines explained. Awareness timing: when the 24-hour clock starts. The actively exploited definition and filing shape: notifying an actively exploited vulnerability.

Questions people ask

A CVE landed in a library we embed. Do we all have to file Article 14?
Only if the vulnerability is actively exploited in your product with digital elements. Commission FAQ 5.4 says the integrating manufacturer notifies when the product contains an actively exploited vulnerability originating from an integrated component. If the same component was placed on the market separately, its manufacturer notifies too. There is no automatic “every integrator of that library files” rule when the flaw cannot be exploited in your product.
The component is vulnerable but cannot be exploited in our product. Still mandatory?
No. FAQ 5.4 says that if you know an integrated component has a vulnerability but it cannot be exploited in your product, it is not an actively exploited vulnerability for that product, so mandatory Article 14 reporting does not apply. You may still notify voluntarily under Article 15, and you still owe the upstream report to whoever manufactures or maintains the component under Article 13(6).
Who files — us, or the chip / SDK / open-source maintainer?
Both can. You file for your product when exploitation is in your product. The component manufacturer also files if that component was placed on the market as its own product with digital elements (Article 3(1)). Open-source stewards have a different, later Art 24(3) reporting track from 11 December 2027 — integrating manufacturers still report from 11 September 2026 when Art 14 is met.
Is telling the library maintainer the same as an ENISA / CSIRT filing?
No. Article 13(6) is a supply-chain disclosure to the person or entity manufacturing or maintaining the component. Article 14 is the mandatory early-warning / notification / final-report chain through the ENISA Single Reporting Platform to the coordinating CSIRT. Upstream notice does not stop the 24-hour clock when Art 14 applies to your product.
Does Article 13(6) already apply, or only from December 2027?
Article 14 reporting has applied since 11 September 2026. Article 13 and Annex I Part II vulnerability-handling duties generally apply from 11 December 2027 (Article 71(2)). FAQ 5.4 still cites Article 13(6) for the upstream path when the component flaw is not exploitable in your product — treat that citation as Commission guidance on the split of duties, and confirm with counsel how your Member State and product timeline apply the Art 13 limb before 11 December 2027.
What should we do operationally when a component CVE drops?
Map which of your SKUs contain the component, decide quickly whether exploitation (or a severe incident) affects your product, timestamp awareness, and start the 24h / 72h / final chain if Art 14 is met. In parallel, notify the component maintainer under your upstream channel. Practice the clocks on the free desk or deadline calculator — filing still goes through ENISA.

Component CVE, your clock

When you decide the vulnerability is actively exploited in your product, enter that awareness time in the free desk or deadline calculator and get the 24-hour, 72-hour and final-report dates. No sign-up; data stays in your browser. Keep a component map so the “is it in our SKU / is it exploitable here?” question does not burn the first day.

Track your Article 14 clockOpen the deadline calculator

Workflow support, not legal advice. Whether a given component vulnerability is exploitable in your product, whether the component was placed on the market, and how Article 13(6) binds you before 11 December 2027 are determinations for qualified counsel. Claims above track Regulation (EU) 2024/2847 Articles 3(1)/(6), 13(6), 14(1), 15 and 71(2), plus Commission CRA implementation FAQ entry 5.4 (as reproduced on the ORC WG mirror). Confirm against the Official Journal text (EUR-Lex) and current Commission / ENISA guidance before relying on this for a live case.