Asking a supplier or an open-source project for CRA evidence: a request you can send

Article 13(5) of the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) puts due diligence on the third-party components in your product on you, the manufacturer. Most makers already know they have to ask the people behind a component for something. What they lack is the words. This guide gives you a short request to send, says what to do with each kind of answer (including no answer), and covers the components that have nobody to ask. What Article 13(5) itself asks is in our guide "Due diligence on open-source components"; this guide does not repeat it. It is a documentation aid, not legal advice. Statements are labelled evidence where the Regulation or a public source says them and argument where they are our reading.

Why a request, and why these four questions

On 1 October 2026 three issues were opened in the MISP, misp-docker and misp-modules repositories. Each asked the project the same four questions "for the CRA": are SBOMs available, are they attached to releases, is there CI evidence, and is there documentation. The text says the asker is "actively evaluating the compliance posture of the critical open-source tools we rely on" (evidence: the issues exist with this text, as read for our research note on 9 October 2026). We cite them as proof that makers ask these questions in public, in whatever words they can think of. We cannot say how the projects answered, and nothing here speaks for them.

The request below keeps the first three of those questions and swaps "is there documentation" for an advisory contact, because Article 13(6) needs you to know where to send a report and where to hear about fixes (argument). The four questions fit what Article 13(5) and Annex I, Part II ask you to be able to show: which component and version you ship (Annex I, Part II, point 1, evidence), whether it receives security updates (Recital 34, evidence), and where you will hear about problems (argument, resting on Article 13(6) and Annex I, Part II, point 2).

The request

Copy it, change the square brackets, send it to the address on the project's security page if it has one, or open an issue or discussion if it does not. Keep it short: the person reading it is often a volunteer.

Subject: Security information for [component] [version], for our CRA records

Hello,

We ship [component] [version] inside [our product]. Under the EU Cyber Resilience Act we have to keep a record of how we looked after the third-party components in it. We are not asking for anything legally binding, and nothing here is a complaint. If you can answer any of these in a line or two, that helps us:

1. Do you publish a software bill of materials (SBOM) for [component]? If so, in what format (SPDX or CycloneDX) and where?
2. Is it attached to each release, or only to some?
3. Is there build or CI evidence we can point to, such as release workflow logs, signed release artifacts or a reproducible-build note?
4. Where do you publish security advisories, and who should we write to about a vulnerability we find? A security policy page or an advisory feed is enough.

We will keep your answer, with the date, in our technical documentation. If the answer is "we don't have that", that is also useful to us, and we will record it as such and work around it. We will not describe your project as compliant or certified in anything we publish.

Thank you for the work you put into [component]. [Name, company, contact]

What it says on purpose: it says what you will do with the answer, it makes "no" an acceptable reply, and it threatens nothing. A supplier who is a volunteer owes you nothing under the CRA (argument: Article 13(5) puts the duty on the manufacturer that integrates the component, and Article 24 gives open-source stewards only lighter duties of their own).

What to do with each answer

Keep every request and every reply, with its date, in your technical documentation. The record is the evidence; the supplier's reply is only one input to it (argument, resting on Article 13(7)).

• They send an SBOM. Check it names the version you ship. Compare it with the SBOM you generate from your own build, because the one you generate describes your product and theirs describes their release. Note any difference and which you rely on.
• They say it is attached to releases. Record the release page and how you will fetch the file for each new version. If it is attached to some releases only, record which one you ship.
• They point to CI or build evidence. Record the link and what it shows. A passing workflow is a fact about their build, not a finding about your product.
• They give an advisory feed or a security contact. Record it. This is the place you will report a flaw you find (Article 13(6), evidence) and the place you will watch for fixes. Subscribe to it, or note how you will check it and how often.
• They refuse, or say they do not do this. Record the refusal and the date. Article 13(5) asks for due diligence on the component; it does not ask the supplier to cooperate (argument). Then fall back on the checks that need no one's help: is it maintained, what does a public vulnerability database say, and what is your decision (Recital 34, evidence).
• They do not reply. Record "asked on [date], no reply". Ask once more after a reasonable time, say four weeks, and record that too. A dated request with no answer is part of the record, not a gap in it (argument).

In every case: a supplier's reply does not make your product compliant, certified or approved, and nobody upstream carries your duty. Article 13(5) puts the duty of due diligence on the components you integrate on you, not on the supplier (evidence). A good answer is strong evidence for your file. It does not replace the file.

A cloud or platform provider

The four asks above are written for components you build into the product. A cloud or platform service your product relies on is a different case, and the Commission's draft guidance (C(2026) 5252 Annex, approved 27 July 2026, not binding, formal adoption pending) says what to ask it for. Our guide "Is your cloud backend part of your product?" explains when the service counts. Do not send a provider the SBOM and CI-log request: it has no release of yours to attach them to.

Ask for assurance evidence. The guidance lists what you can reuse, and says the list is not exhaustive (point 207, evidence): evidence of meeting Commission Implementing Regulation (EU) 2024/2690; evidence of meeting Regulation (EU) 2022/2554 (DORA); a statement of conformity or certificate under a European cybersecurity certification scheme adopted under Regulation (EU) 2019/881; or evidence of conformity with ISO/IEC 27017:2015 or ISO/IEC 27001:2022.

Put it in the service agreement. Ask for security commitments in your service level agreement, including that the provider handles vulnerabilities adequately, and for the provider to keep you informed of changes to the service (point 208, evidence). Our reading (argument): on a change notice, check whether the evidence you hold is still current and whether your own controls on the product still fit.

Keep what you asked for, what you got and the date, as for any component. A provider's certificate is evidence for your file. It does not replace the file.

When there is no vendor to ask

Many open-source components have no company, no support desk and nobody who would call themselves a supplier. Realistic routes, in the order we would try them (argument):

• The repository's own security policy. Look for a SECURITY file or a "Security" tab. It usually says how to report and sometimes how long fixes take.
• The release page. See whether releases carry signed files, checksums or an SBOM, and whether security fixes are called out in the notes.
• The project's advisory feed. Many projects publish advisories on the repository or on a mailing list. Subscribe to it and record where.
• The project's governance page. If the project has a foundation or steward behind it, its security policy is evidence for your record (see "Due diligence on open-source components" on stewards). It does not replace it.

For many components none of these will give you a document. The honest answer is then a recorded judgement, not a document: what you checked, what you found, what you decided and why, signed and dated (argument, resting on Article 13(7) and Annex I, Part II, point 2). Declarable asks for a written decision only for a component with an open, in-triage or affected vulnerability match, one per component; a component whose upstream has stopped is something you record yourself for now. Our guide "Due diligence on open-source components" says how that record works. For any other component, including one whose supplier sent nothing, Declarable has no screen for the decision: keep it in your own file and put it in 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 a due-diligence record; keeping it there is our reading of Article 13(5) and 13(7) (argument), with what you checked, what you found, what you decided, who decided and the date.

What is settled and what is not

Settled (evidence): the text of Articles 13(5) to 13(7) and 24, Recital 34 and Annex I, Part II, as read on 9 October 2026, and that the three MISP-family issues exist with the quoted text.

Not settled: we found no Commission guidance saying that a maker must send a request like this, or how a market surveillance authority would read a recorded "no reply". Our position that it counts towards due diligence is argument.

What the Commission has published on supplier documentation is a draft and not binding. Its guidance on applying the CRA, C(2026) 5252, was approved as a draft on 27 July 2026, says of itself that it "is not binding" and still awaits formal adoption. Point 171 says the manufacturer has to identify the requirements an integrated component should satisfy and verify that it satisfies them, and goes on: "Evidence for this purpose may consist of documentation obtained from the component manufacturer, such as technical specifications, security documentation or relevant conformity or assurance documentation. Where appropriate, the manufacturer may also carry out tests to verify that those components adequately perform the relevant functions" (evidence: that the draft says this). So in the Commission's reading a supplier's documents are one kind of due-diligence evidence and your own tests are another. The word is "may": point 171 does not require either one, and it says nothing about a request, a refusal or silence (argument: our reading of the point). We read point 171 on 11 October 2026, and its wording can still change before adoption.