Most of a software product with digital elements is code its manufacturer did not write: libraries, frameworks, an operating system, a database, a cloud service. The Cyber Resilience Act, Regulation (EU) 2024/2847, does not make the manufacturer responsible for those components' own compliance. It makes it responsible for the product as a whole, and it attaches three duties to the components inside it. Article 13(5): exercise due diligence when integrating them. Article 13(6): report vulnerabilities you find in them to their maintainer, and share the fixes you write. Annex I Part I point 2(a), read with Article 13(1): place the product on the market without known exploitable vulnerabilities. The Regulation states each in a sentence. The Commission's guidance of 27 July 2026, C(2026) 5252, sections 3.4, 7.3 and 9.2, says what each one takes, and this article is those sections, with the Commission's FAQ on the implementation, version 1.4, section 5.4, where it adds something.
Who is responsible for a component: only the person who places it on the market
Paragraph 87 of the guidance settles the question maintainers and integrators both ask: "Whether the CRA applies to a given FOSS component depends solely on whether the natural or legal person that publishes it places it on the market." Integrating a component into a monetised product "has no impact on the status of that FOSS component", and paragraph 86 adds that manufacturers "do not become responsible for such components' individual compliance with the CRA, even where the manufacturers contribute source code to their maintenance". When a project is placed on the market is a question for its publisher. What the integrator owes is in paragraph 88: compliance "for their own products with digital elements", due diligence under Article 13(5) "towards the FOSS components that they integrate", and the reports and fixes of Article 13(6).
Due diligence, Article 13(5): decide what you need from the component, then verify it
Section 7.3 draws the line between the risk assessment and due diligence. The risk assessment of Article 13(2) covers the product and the risks that reach it from outside, "such as external networks, environmental factors, or other external aspects", and for those "the CRA does not require manufacturers to control or govern the external environment", only "to identify such risks and to mitigate them through the design and development of the product" (paragraph 168). Paragraph 169's example is a back-end that is not part of the product but could be used to send it malicious commands: the answer is product-level, "cryptographic authentication of remote commands, verifying the integrity of configuration changes, or generating security-relevant logs", and the Regulation "does not impose obligations on how the back-end infrastructure is organised, staffed or operated".
Due diligence is the other duty, and it "relates to elements that form part of the product with digital elements itself, in particular integrated software or hardware components provided by a third party" (paragraph 170). Its content is in one sentence of the same paragraph: it "can only be achieved by determining what the product with digital elements requires from its components in order to meet its cybersecurity objectives, and verifying, in a risk-based manner, that those components are in line with the product's needs". Paragraph 171 makes it concrete: if the product "relies on cryptographic functions, update mechanisms or secure communications provided by a component, the manufacturer must, as part of its due diligence, identify those needs and verify that the component satisfies them". The evidence "may consist of documentation obtained from the component manufacturer, such as technical specifications, security documentation or relevant conformity or assurance documentation", and "where appropriate, the manufacturer may also carry out tests".
Two consequences for a dependency list. First, due diligence is proportionate and specific: it asks what each component does for the product's security and checks that, not everything about every package. A logging library and a TLS library do not get the same file. Second, the check happens "upon integration" (paragraph 172), and the components are treated "as externally supplied components whose properties are verified through due diligence", not redesigned. Paragraph 173: "where the manufacturer develops functionalities itself, it must directly implement the essential requirements. Where the manufacturer integrates components developed by others, it must ensure through due diligence, that those components can be used in a way that enables the product with digital elements as a whole to comply."
Reporting upstream and sharing fixes, Article 13(6): four limits the guidance sets
Article 13(6) requires a manufacturer that identifies a vulnerability in an integrated component to report it "to the person or entity manufacturing or maintaining the component", and to share any fix it develops. Section 9.2.1 fences the duty in four ways.
Only the version you integrate, through the maintainer's channel, and not twice. Paragraph 223: manufacturers "are required to report upstream only in respect of the version of the component that they integrate"; where the maintainer has "security policies, coordinated vulnerability disclosure processes or designated channels", the report goes through them; and "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". The guidance asks manufacturers to check "publicly accessible vulnerability databases, project-specific security advisories, or established issue trackers before reporting upstream", to spare maintainers duplicates.
Only vulnerabilities in the component, not in your integration of it. Paragraph 224: the duty covers "those vulnerabilities that exist in the integrated component itself, and not vulnerabilities that exist as a result of the integration between the component and other code developed by the manufacturer". Where integration reveals a behaviour of the component that was not apparent in isolation, telling the maintainer is encouraged, not required.
Not where there is no maintainer. Paragraph 225: no upstream report is owed "where the component no longer has a maintainer, or when the manufacturer no longer relies on the original maintainer for new versions or security fixes"; informing users of the component through "existing community mechanisms (such as mailing lists or issue tickets) or through public vulnerability records" is encouraged instead.
Share the fix; do not have to get it merged. Paragraphs 226 to 229: a fix you develop for a component vulnerability must be shared upstream, "where appropriate, in a machine-readable format" and, for an open-source component, "in a manner compatible with that component's licence". But manufacturers "are not required by the CRA to ensure that their security fixes are necessarily accepted" or "integrated into the component's code repository", are not required to accept the maintainer's fix in return, and where they mitigate the vulnerability by changing something else in their own system, "the CRA does not require the manufacturer to share the modification of another part of the system upstream".
When a component's vulnerability is yours to report to the authorities
Article 14's mandatory notification is a different duty from the upstream report, and the two are easy to confuse. Guidance paragraph 218 and FAQ 5.4 draw the line: a manufacturer reports an actively exploited vulnerability "contained in their product"; where a third-party component's vulnerability "cannot be exploited in its product with digital elements (e.g. because the vulnerable code is not reachable)" or "has not been exploited in its product", it "is not subject to mandatory reporting for that manufacturer". The FAQ adds that the component's own manufacturer reports it too, "if that component has been placed on the market", and that the integrator "can still notify that vulnerability on a voluntary basis, in accordance with Article 15". So a listed CVE in a dependency starts two things: the reachability assessment that decides whether the 24-hour clock has started, and, if you found something the maintainer does not know, the Article 13(6) report.
Known exploitable vulnerabilities at the moment you ship
The first essential requirement of Annex I Part I point 2(a) is to make the product available "without known exploitable vulnerabilities", and section 9.2.2 answers the two words the Regulation leaves open. "Exploitable" is Article 3(41): "a vulnerability that has the potential to be effectively used by an adversary under practical operational conditions", which paragraph 231 contrasts with vulnerabilities exploitable "only in theoretical conditions (e.g. in a lab or in a simulation)". "Known" is paragraphs 233 and 234, and it is wide: a vulnerability "should be regarded as known when it is listed in relevant publicly accessible vulnerability databases, such as the European vulnerability database" or "other prominent vulnerability databases"; when the manufacturer "has been made aware of it via non-public information, for example via coordinated disclosure by a security researcher or through the manufacturer's own internal testing and analysis, including, for example, when making use of AI-powered services"; and "when it has been publicly and prominently reported in reliable media outlets".
Paragraph 235 keeps it proportionate: a report "does not, in itself, mean that it is exploitable in practice or applicable to the specific product", the manufacturer "will need to investigate it and confirm the veracity of such information and applicability", and "a limited period of time may elapse between the first report of the vulnerability and its confirmation". Paragraphs 236 and 237 address the release that is a day away when a new CVE lands in a dependency: the obligation "applies at the moment of placement on the market", it is "a risk-based obligation", and the manufacturer decides on the basis of "the severity, exploitability and potential impact of the vulnerability" whether the product can be placed on the market or the vulnerability must be fixed first, and "may also take into account the risks of postponing the product's release", for example where the release fixes other exploitable vulnerabilities. Once on the market, the handling duties of Annex I Part II apply anyway.
Variants and product families
A short section that saves the most work. Section 7.4: where products "share the same architecture, security-relevant design and intended purpose, and are exposed to the same cybersecurity risks", the manufacturer "may rely on (i) a single cybersecurity risk assessment", "(ii) a single set of technical documentation; and (iii) a single conformity assessment procedure", and issue "a single EU declaration of conformity" that "clearly identifies the product variants to which it applies" (paragraph 175). Paragraph 176 gives the test: differences in "colour, form factor, memory size, or other non-security-relevant characteristics" do not split the family; differences in "communication interfaces, software stacks, update mechanisms or remote connectivity" do, and must be reflected in the documents.
What to keep, per component
The record that satisfies all three duties fits in the SBOM you already produce for Annex I Part II point 1, one row per component:
- Name, version integrated, and the maintainer's security contact or disclosure channel.
- What the product needs from it for security, in the paragraph 171 sense: nothing, or cryptography, updates, authentication, transport, and so on.
- The evidence you hold for that need and when you obtained it: the maintainer's documentation, an assurance artefact, your own test.
- The reachability of the component's known vulnerabilities in your product, and the date of the last check against the databases paragraph 233 names.
- Upstream reports made and fixes shared, with dates, or the confirmation that the maintainer already knew.
That table is the due diligence file, the input to the reachability assessment when a CVE appears, and the part of the technical file an authority will read first when the question is "did you know".
Sources
- Regulation (EU) 2024/2847, Article 3(41), Article 13(1), (2), (5) and (6), Article 14(1), Article 15, Annex I Part I point 2(a) and Part II point 1, Recital 34.
- European Commission, Commission guidance on the application of Regulation (EU) 2024/2847, C(2026) 5252 final of 27 July 2026, Annex, section 3.4 (paragraphs 85 to 88), section 7.3 and 7.4 (paragraphs 167 to 177), section 9.1 paragraph 218, section 9.2.1 and 9.2.2 (paragraphs 222 to 237).
- European Commission, FAQs on the Cyber Resilience Act, version 1.4 of 4 September 2026, section 5.4.
This is not legal advice. Sections 7.3 and 9.2 are seven pages between them, and they answer the dependency question more precisely than any tool vendor's page; read them with your lockfile open.