Due diligence on open-source components: what Article 13(5) of the CRA asks

A firmware image can carry hundreds of open-source components. The Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) does not exempt them because you did not write them: the duty for the whole product sits with you, the manufacturer. This guide says what Article 13(5) asks about those components, what it does not ask, and what a reader of your technical documentation can check. It is a documentation aid, not legal advice. Statements are labelled evidence where the Regulation says them and argument where they are our reading.

Which code counts as yours and which as upstream's is covered in our guide "What is yours to document and what Zephyr, Yocto and ESP-IDF already cover"; this guide does not repeat it.

What Article 13(5) asks

In our words (evidence, Article 13(5)): when you integrate components sourced from third parties, you exercise due diligence so that those components do not compromise the cybersecurity of your product. The paragraph says this includes free and open-source components that were not made available on the market in the course of a commercial activity, which is most of what a firmware build pulls in.

Two neighbouring paragraphs give the duty its shape (evidence):

• Article 13(7) asks you to document the product's relevant cybersecurity aspects systematically, in a way proportionate to the risks, including vulnerabilities you become aware of and relevant information from third parties.
• Annex I, Part II, point 1 asks you to identify and document the components and vulnerabilities in the product, including by drawing up a software bill of materials (SBOM), and Annex I, Part II, point 2 asks you to address and remediate vulnerabilities without delay.

So the duty has two halves: do the checking, and be able to show what you checked and what you decided.

One thing worth getting straight before any of that (evidence, Article 3(1)): a component sold on its own is itself a product with digital elements. The definition reads "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately". So a chip, a module, an RTOS or a commercial library may have a manufacturer carrying their own CRA duties for it, and from 11 December 2027 it may carry its own CE marking and EU declaration of conformity — which is exactly what recital 34 asks you to look for below. What does not follow is that your product conforms: the duty for what you place on the market stays with you. Our guide "What the CRA asks of a one-person firm" answers the "is my chip CRA compliant?" form of the question.

What it does not ask

It does not ask you to audit every upstream project's source code (argument). The basis is Recital 34 (evidence): the appropriate level of due diligence "depends on the nature and the level of cybersecurity risk associated with a given component", and should take into account "one or more" of four actions: checking that the component's manufacturer has shown conformity with the CRA (for example the CE marking, where the component is itself a product), checking that it receives regular security updates, checking it against public vulnerability databases, or carrying out additional security tests. A line-by-line code review is not on that list. Our reading is that a small, isolated parsing library and the TLS stack that guards your device's network traffic do not need the same depth of checking, and that the effort should follow the risk (argument).

The Commission's draft guidance on applying the CRA reads the duty the same way (evidence for what the draft says; the draft is the Commission's reading, not law). Its point 170 says a manufacturer has to keep third-party components from undermining the product's compliance with the essential requirements, and that this "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, as also indicated in recital 34". Point 171 gives an example: "if the product with digital elements 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". It then names what can serve as evidence: "documentation obtained from the component manufacturer, such as technical specifications, security documentation or relevant conformity or assurance documentation", and adds that "Where appropriate, the manufacturer may also carry out tests to verify that those components adequately perform the relevant functions".

How much weight to give it: this is guidance C(2026) 5252, published on 27 July 2026 but not yet formally adopted. The Commission says it applies only once formally adopted, and the copy we read on 11 October 2026 was still the draft. Its own point 8 says it is not binding and that only the Court of Justice of the European Union can give an authoritative interpretation. What this means: it shows how the Commission reads Article 13(5), it does not change what the Regulation says, and its wording may still change before adoption.

What counts as evidence

A short list you can act on for each component, starting with the ones that face the network or handle keys:

• It is maintained. It has a recent security release, or a published security update history. Recital 34 names this check (evidence).
• Its known vulnerabilities, and your decision on each. Check it against public vulnerability databases (Recital 34, evidence), then write down what you did about each match: upgraded, mitigated, or kept it with a reason. Recording the decision rather than only the match is our reading of Article 13(7) and Annex I, Part II, point 2 (argument).
• The version is pinned. Your SBOM names the exact version you ship, not a branch or a range. Without it neither you nor a market surveillance authority can say which vulnerabilities apply (argument, resting on Annex I, Part II, point 1).
• Upstream has a security contact or an advisory feed. You need somewhere to send a report under Article 13(6) and somewhere to hear about fixes (argument). Where it has none, say so and say how you will learn of problems.
• Where the risk is high, your own testing. Fuzzing a parser you expose to the network is the kind of "additional security tests" Recital 34 names (evidence for the action, argument for when to do it).

The free SBOM check reads your SBOM in your browser and shows every component, its version and the identifiers vulnerability feeds look for, and can check them against known vulnerabilities if you ask it to. Our guide "Firmware SBOMs that match CVEs" says how to fix them. For the asking itself, with a request you can send, see "Asking a supplier or an open-source project for CRA evidence".

Reporting a flaw upstream (Article 13(6))

When you identify a vulnerability in a component, including an open-source one, you report it to the person or entity that manufactures or maintains that component, and you address and remediate it under Annex I, Part II (evidence, Article 13(6)). Where you developed a fix, you share the relevant code or documentation with them, where appropriate in a machine-readable format (evidence, Article 13(6)). Reporting upstream does not move your remediation duty: your product still needs the fix within your support period (evidence, Article 13(8) and Annex I, Part II, point 2). Our guide "Coordinated disclosure for small teams" covers how to run the report.

Article 13(6) names no exceptions. Section 9.2.1 of the Commission's draft guidance C(2026) 5252 says where it reads the duty as stopping. Its weight is set out under "What it does not ask" above: a draft, not binding, and its wording may change.

• Only the version you ship (point 223; the Commission's draft reading, not binding): manufacturers report "only in respect of the version of the component that they integrate", and through the maintainer's own security policy or reporting channel where it has one.
• Not when the maintainer already knows (point 223; the Commission's draft reading, not binding): 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", and are encouraged to check public vulnerability databases, the project's security advisories and its issue tracker first, so that maintainers are not sent duplicates.
• Only flaws in the component itself (point 224; the Commission's draft reading, not binding): the duty covers "only those vulnerabilities that exist in the integrated component itself", not ones that exist because of how you integrated it with your own code or with other components.
• Not for a component nobody maintains (point 225; the Commission's draft reading, not binding): no report is required "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"; the draft encourages you to tell the component's other users another way, for example through a mailing list, an issue ticket or a public vulnerability record.
• A shared fix need not be accepted (points 227 to 229; the Commission's draft reading, not binding): a fix to an open-source component "should be shared in a manner compatible with that component’s licence", manufacturers "are not required by the CRA to ensure that their security fixes are necessarily accepted", and where the maintainer has already released a fix and you mitigate another way, by changing a configuration elsewhere in your system for example, that change does not have to be shared.

If you send no report for one of these reasons, write down which one and what showed it, with the date you checked (argument). The Regulation's own words are only that you report, so the record is what you would show if the draft's reading changes.

If you contribute to a component you use

Article 13(6) tells you to share a fix upstream, so teams ask whether doing that makes the component theirs. The Commission's draft guidance C(2026) 5252 says it does not (point 86; the Commission's draft reading, not binding): manufacturers that integrate open-source components "do not become responsible for such components’ individual compliance with the CRA, even where the manufacturers contribute source code to their maintenance". Paying for a feature does not either (Examples 32 and 33; the Commission's draft reading, not binding): "A manufacturer that has contributed to the development of certain features does not become the manufacturer of that FOSS component", and members of a foundation whose developers contribute code "are not responsible for the SDK’s compliance with the CRA". Your own duty stays: point 65 and Example 23 say a company that funded the work still exercises due diligence under Article 13(5) when it integrates the result, and point 88 says the same of every maker that integrates an open-source component (the Commission's draft reading, not binding; the duty itself is Article 13(5), evidence). So a patch or a paid feature leaves the component in your record like any other (argument). All of this is about a component someone else publishes and controls; software you publish yourself is a different question, and this section does not answer it (argument).

The open-source steward's lighter duties

An open-source software steward is a legal person, other than a manufacturer, that supports on a sustained basis the development of free and open-source software intended for commercial activities and keeps it viable (evidence, Article 3(14)). Recital 19 says stewards include certain foundations and entities that develop and publish open-source software in a business context, and that they get a "light-touch and tailor-made regulatory regime" (evidence). What it means: the organisation that looks after a project, not the people who write commits.

A steward owes far less than you do (evidence, Article 24): a documented cybersecurity policy that fosters secure development and the handling of vulnerabilities, cooperation with market surveillance authorities when asked, and Article 14 reporting that depends on the kind of support it gives (Article 24(3)). Which reporting falls on a steward is set out in the steward result of our scope check, and this guide does not restate it. Administrative fines do not apply to stewards (evidence, Article 64(10)(b)): Article 64(10) opens "By way of derogation from paragraphs 2 to 9" since the corrigendum of 2 July 2025, so it reaches paragraph 2, where the fine for an Article 13 or Article 14 failure is set, and point (b) excludes it for a steward. That is relief from administrative fines, not from the duties above; recital 120 states the intent behind Article 64(10). Our glossary row penalties carries the same wording.

A steward does not take your duty over (argument, resting on Article 13(5) placing the duty on the manufacturer that integrates the component). A project with a steward and a good security policy is strong evidence for your due-diligence record; it does not replace it.

How the record in Declarable maps to it

For the current release of each product, Declarable lists a component that has an open, in-triage or affected vulnerability match. It asks you for one record per component, not per vulnerability. It does not yet list a component only because its upstream has stopped being maintained; if you know of one, write that record yourself. Each record holds a decision, in these words: Upgraded (a newer version of this component is in this release), Mitigated another way (the component is unchanged; something else stops the problem being reachable), Kept as it is (unchanged, and you judged it carries no real risk here) or Accepted the risk (the risk is real, understood, and carried for a written reason), with your reason, who decided and when. A record you wrote earlier stays in the list after the component stops being listed, marked "no longer carries either flag; your record is kept". The records appear as a section of the technical documentation draft. The list is what Declarable has found from the SBOM and the match record, not a statement that no other component needs a record: a component with neither flag gets no screen here, including one whose supplier sent nothing or one you have judged risky for other reasons. Keep that decision in your own file and put it in the technical documentation under the due-diligence section of your technical documentation, filed with the vulnerability-handling material of Annex VII point 2(b) (Annex VII does not name the record; that is our reading, argument).

What a reason for "Accepted the risk" may rest on

Section 7.1 of the Commission's draft guidance C(2026) 5252 is about the cybersecurity risk assessment of the whole product under Article 13(2) and (3). It does not mention this record; applying it to a decision on one component is our reading (argument). Its weight is set out under "What it does not ask" above: a draft, not binding, and its wording may change.

• What the reason rests on (argument, resting on points 157 and 159): that the risk left over is small enough for what the product is for and how it will foreseeably be used, with the measures you took named. Point 157 says residual risk "should be assessed in light of the requirement that the product with digital elements placed on the market ensures an appropriate level of cybersecurity based on the risks, taking into account its intended purpose and reasonably foreseeable use". Point 159 says "the existence of residual risk does not imply that any risk may be accepted at the manufacturer’s discretion" (both the Commission's draft reading, not binding).
• What does not count alone (point 158; the Commission's draft reading, not binding): "the manufacturer’s internal risk tolerance, commercial strategy or mere cost considerations are not relevant in determining whether risks have been addressed". So "too expensive to fix in this release", "the release date is fixed" or "within our company's risk policy" is not a reason when it stands alone (argument). Point 163 adds that considerations "relating solely to cost or commercial feasibility do not constitute sufficient grounds for leaving such risks untreated where this would prevent the product with digital elements from meeting the essential requirements".
• Leaving it to the user does not count either (point 161; the Commission's draft reading, not binding): the CRA "does not provide for the transfer of cybersecurity risk or responsibility to users or third parties to compensate for shortcomings in product design or to justify leaving cybersecurity risks unaddressed".
• The limit (evidence for the requirement, argument for how the record sits with it): a product is to be made available on the market "without known exploitable vulnerabilities". A vulnerability you know can be exploited in your product is a matter for that requirement, Part I(2)(a), and this record does not settle it. Accepting a risk in a component is not the same as shipping a vulnerability you know to be exploitable in your product. That row says when a vulnerability counts as known and how the decision is made for one found shortly before release.

Whatever decision a record holds, it shows what you checked and what you decided. It does not make the product meet the essential requirements (argument).

What is settled and what is not

Settled (evidence): the text of Articles 3(14), 13(5) to 13(8), 24 and 64(10), and recitals 19 and 34, as read on 9 October 2026, and Article 3(1) and recital 120 as the sources below record them. The words of Article 64(10) are settled, in the form the corrigendum of 2 July 2025 gave them ("paragraphs 2 to 9"), and so is the steward's exclusion from fines under point (b).

Published but not binding (evidence for what it says): the Commission's draft guidance C(2026) 5252, section 7.3, points 170 and 171, as read on 11 October 2026. It says due diligence is risk-based and names the kinds of evidence, as quoted above. The same draft's section 9.2.1, points 222 to 229, as read on 13 October 2026, says where the duty to report upstream stops, as quoted above. The same draft's section 7.1, points 156 to 163, as read on 13 October 2026, says what leaving a risk in place may and may not rest on, as quoted above. Its section 3.4, points 85 to 88, with point 65 and Examples 23, 32 and 33, as read on the same day, says that contributing code to an open-source component or paying for a feature does not make you answerable for that component's conformity, and that your Article 13(5) duty stays, as quoted above. It is the Commission's reading, awaiting formal adoption.

Not settled: how much checking a given component needs. Section 7.3 of the draft guidance (points 167 to 173) gives no measure for it: no threshold, no minimum set of checks per component and no test for when you have done enough. That judgement stays with you, and the reasons for it belong in your record. Nor is it settled how small a leftover risk has to be: section 7.1 of the draft speaks of the product's risk assessment, does not mention a record per component and gives no threshold, so reading it onto "Accepted the risk" is ours (argument). We also found no harmonised standard cited under the CRA in the Official Journal on 9 October 2026. The open-source community's own questions and answers on the CRA are collected by the Open Regulatory Compliance Working Group, hosted by the Eclipse Foundation; read them for the maintainer's side. We update this guide when the guidance is formally adopted or its wording changes.