Under the Cyber Resilience Act, an OEM must exercise due diligence on third-party components (Article 13(5)). A supplier whose part is in scope also has manufacturer duties. OEMs ask for scope, support period, vulnerability contact, VEX and integrator information.
The CRA does not list what a supplier must send. It sets the OEM's duty and leaves the evidence to the two parties. That gap is why every supplier now receives a different spreadsheet from every customer. This article maps the common requests to the text of Regulation (EU) 2024/2847, so a supplier can answer once.
Key takeaways
- Article 13(5) of the Cyber Resilience Act places the due diligence duty on the manufacturer that integrates a third-party component, from 11 December 2027.
- Article 3(1) includes hardware components placed on the market separately, so a chip or module can itself be a product with digital elements.
- Whether the CRA applies to a component depends on Article 2(1), a direct or indirect data connection in its intended or reasonably foreseeable use.
- A supplier can answer most OEM questionnaires with seven items, which are scope, support period, vulnerability contact, advisories and VEX, software content, integrator information and an upstream reporting channel.
- CSAF 2.0 can identify a hardware part by model number and by a CPE of part type h. CSAF 2.1 was still a Committee Specification Draft on 21 October 2026.
Does the CRA apply to a component sold on its own?
A component sold on its own can be a product with digital elements. Article 3(1) defines the term 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(5) then defines hardware as "a physical electronic information system, or parts thereof capable of processing, storing or transmitting digital data". A memory chip stores digital data. A radio module transmits it. A sensor with a digital interface processes it. The definition does not stop at finished devices.
The definition is not the scope test. Article 2(1) applies the Regulation to products "the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network". Article 3(10) defines an indirect connection as one that takes place "as part of a larger system that is directly connectable" to a device or network. Most components are only connected through the product they are built into.
The text does not say when the reasonably foreseeable use of a component includes an indirect connection. That question stays with the supplier, and the answer belongs in a written scope statement with its basis.
| Case | Product with digital elements? | Scope turns on |
|---|---|---|
| Finished device with a network interface | Yes | Article 2(1) is usually met |
| Hardware component placed on the market separately | Yes, under Article 3(1) and 3(5) | Article 2(1), the direct or indirect data connection |
| Software library placed on the market separately | Yes, under Article 3(1) | Article 2(1), and the open-source rules where they apply |
| Spare part that replaces an identical component, made to the same specifications | Yes | Excluded by Article 2(6) |
| Product covered by the medical device or vehicle type-approval regulations | Yes | Excluded by Article 2(2) |
What does Article 13(5) require from the OEM?
Article 13(5) requires the integrating manufacturer to "exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements". The duty includes free and open-source components that were not made available in the course of a commercial activity.
The duty applies from 11 December 2027. Article 71(2) brings only Article 14 forward, to 11 September 2026, and Chapter IV on notified bodies to 11 June 2026.
Article 13(5) names no document, no format and no supplier obligation. The OEM decides what evidence is enough, and a market surveillance authority later reads that decision in the technical file. For the supplier, that means the questions arrive as each OEM's own interpretation.
Two neighbouring provisions shape the questions. Article 13(6) requires the OEM to report a vulnerability it finds in an integrated component "to the person or entity manufacturing or maintaining the component". Article 13(8) lets the OEM take into account "the support periods of integrated components that provide core functions and are sourced from third parties" when it sets its own support period. Both turn the supplier's answers into inputs for the OEM's own obligations. The Article 13(6) reporting path explains who reports what.
What evidence do OEMs ask a component supplier for?
Seven items cover most OEM questionnaires. Each one maps to a provision the OEM must meet, or to a duty the supplier has when its own part is in scope.
| Evidence | Why the OEM asks | CRA text it supports |
|---|---|---|
| Scope statement, with its basis | The OEM must know whether the supplier carries its own CRA duties for the part | Article 2(1), Article 3(1) and 3(5) |
| Security support end date, at least month and year | The OEM may take core component support periods into account for its own support period | Article 13(8), Article 13(19) |
| Vulnerability contact and CVD policy | The OEM needs a place to send the upstream report | Article 13(6), Annex I Part II(5) and (6) |
| Security advisories and VEX statements | The OEM must decide fast whether a published vulnerability affects its product | Annex I Part II(8), for the supplier's own product where in scope |
| Software content statement or SBOM | An empty SBOM is ambiguous. It can mean no software or no answer | Annex I Part II(1), for products with software |
| Integrator information | The OEM must meet Annex I and complete its Annex VII file | Annex II point 8(f), where the supplier's product is in scope |
| Upstream reporting channel | The OEM must report a component vulnerability it finds | Article 13(6) |
The software content statement is the item suppliers skip most often. A part with no executable code, a part with fixed ROM code, a part with field-updatable firmware and a part that runs software are four different answers. The last three contain software, so a part of any of those three types needs an SBOM when it is in scope (Annex I Part II(1)). Fixed ROM code counts, even when nobody can update it. A short signed statement removes the question for a part with no executable code.
Annex II point 8(f) is the item most suppliers have not seen. It applies "where the product with digital elements is intended for integration into other products with digital elements" and asks for "the information necessary for the integrator to comply with the essential cybersecurity requirements set out in Annex I and the documentation requirements set out in Annex VII". For a component in scope, that is the supplier's own duty, not a courtesy. We explain the rest of Annex II in Annex II user information in practice.
How does VEX work for a part with no software?
VEX works for hardware, with care. CSAF 2.0, the OASIS standard for machine-readable security advisories, lets a product carry model_numbers, and section 3.1.3.3 says the field "can also be used to identify hardware". A CPE with part type h, such as cpe:2.3:h:vendor:part:..., also names a hardware product.
| CSAF 2.0 element | Use for a hardware part |
|---|---|
model_numbers | The part numbers covered by the statement |
cpe with part h | A machine-matchable identifier for the part |
skus | Only for orderable codes that differ from the part number |
flags label component_not_present | The affected subcomponent is not in the part |
flags label inline_mitigations_already_exist | A design feature of the part prevents exploitation |
threats with category impact | A plain-language reason. A not-affected statement needs this entry or one of the two flags |
Three details catch suppliers out.
The other three CSAF flag labels, vulnerable_code_not_present, vulnerable_code_cannot_be_controlled_by_adversary and vulnerable_code_not_in_execute_path, assume code inside the product. For a part with no code, only component_not_present and inline_mitigations_already_exist fit.
CSAF 2.0 reads ? and * in model numbers as wildcards and has no escape character. A part number that contains either character cannot be stated literally, so check the part list before you publish.
CSAF 2.1 was still at Committee Specification Draft 04 on 21 October 2026. It changes the wildcard rules and asks for hardware and software to be separate products joined by a product path. Publish CSAF 2.0 today, and keep part numbers in their literal form so a 2.1 writer can escape them later. Our VEX guide covers the statuses and the CRA link.
What should a component supplier never claim?
A supplier should never call a part "CRA compliant" or "CRA certified" as a promise to the OEM. A supplier's conformity assessment, where one exists, covers the supplier's part only. It does not discharge the OEM's Article 13(5) duty, and a label gives the OEM nothing to put in its technical file.
The useful claim is narrower and checkable. "Here is our scope statement and its basis. Here is the support end date. Here is where to report a vulnerability. Here are our VEX statements for these part numbers." An OEM can file each of those. An OEM cannot file a badge.
Where should a supplier share the evidence?
Share most of it under access control, not on a public page. The CRA does not force publication of an SBOM. Annex II point 9 asks only where to access it, "if the manufacturer decides to make available the software bill of materials to the user". Errata, integrator notes and VEX for unreleased parts are often under NDA.
Three properties make shared evidence useful to an OEM.
- Per part number. OEMs search by the part on their board, not by product family.
- Dated and versioned. A support period or a VEX statement without a date cannot go into a technical file.
- Machine-readable where a standard exists. CSAF 2.0 for advisories and VEX, CycloneDX or SPDX for an SBOM.
CVD Portal's trust portal shares these records with customers that a supplier approves. Viewers sign in with a magic link and can search by part number. Each product shows the supplier's CRA scope statement, its software content statement, the support end date and the CSAF VEX, SBOM and HBOM files. The supplier can make viewers accept an NDA first, and a download log records each NDA acceptance and each file download. To check whether a part is in scope first, start with the free CRA product classifier.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal of the European Union, L series, 20 November 2024. ELI, CELEX 32024R2847. Articles 2(1), 3(1), 3(5), 3(10), 13(5), 13(6), 13(8), 71(2), Annex I Part II and Annex II points 8(f) and 9.
- OASIS, Common Security Advisory Framework Version 2.0, OASIS Standard, 18 November 2022. Sections 3.1.3.3 and 3.2.3.5, and the VEX profile in section 4.5.
- OASIS, Common Security Advisory Framework Version 2.1, Committee Specification Draft 04, 21 October 2026.
Frequently asked questions
Is a hardware component sold on its own a product with digital elements under the CRA?
It can be. Article 3(1) of the Cyber Resilience Act includes hardware components placed on the market separately, and Article 3(5) defines hardware to include parts capable of processing, storing or transmitting digital data. Whether the Regulation applies then depends on Article 2(1), a direct or indirect data connection in the intended or reasonably foreseeable use.
Who carries the due diligence duty for a third-party component under the CRA?
The manufacturer that integrates the component carries the duty. Article 13(5) requires that manufacturer to exercise due diligence so that components sourced from third parties do not compromise the cybersecurity of its product. The duty applies from 11 December 2027 under Article 71(2).
Can a VEX document identify a hardware part with no software?
Yes. CSAF 2.0 lets a product carry model numbers, and the standard says the field can also be used to identify hardware. A CPE with part type h names a hardware product. For a part with no code, the not-affected flags that fit are component_not_present and inline_mitigations_already_exist.