For machinery and product-security teams, responsibility starts with the final product and the organisation's actual role in the supply chain. Supplier evidence can support that work, but it does not transfer responsibility for the complete product.
Start with the final product and the actual role
A company buying a controller, bus system or embedded firmware does not simply inherit the component manufacturer's responsibilities. Under the Cyber Resilience Act, Regulation (EU) 2024/2847, the key questions are what is being placed on the market, under whose name or trade mark, and how the component is integrated into the final product.
Where a manufacturer places a machine with digital elements on the market, it is responsible for ensuring that the product meets the applicable essential cybersecurity requirements. That includes carrying out, documenting and using a product cybersecurity risk assessment through the relevant stages of the product lifecycle.
A supplier may be responsible for its own controller or software component where that item is separately placed on the market. But once a machine manufacturer integrates it into a final product, the machine manufacturer remains responsible for the cybersecurity of that complete product. This does not mean that it must personally write every patch for every component. It does mean that it must ensure vulnerabilities in the product, including its components, are handled effectively during the support period.
The Act also treats an importer or distributor as a manufacturer where it places a product on the market under its own name or trade mark, or makes a substantial modification. The facts of branding, placement on the market and modification matter in every case.
The supply-chain roles in brief
The Cyber Resilience Act assigns different duties to economic operators. The table is a practical overview, not a complete statement of every obligation.
| Activity | Manufacturer | Importer | Distributor |
|---|---|---|---|
| Create the product SBOM | Yes | No | No |
| Handle vulnerabilities and provide security updates for the product | Yes | No, but has related checks and information duties | No, but has related checks and information duties |
| Prepare product conformity evidence | Yes | Checks specified conformity information before placing a product on the market | Checks specified requirements before making a product available |
| When aware of a vulnerability | Handles it under the manufacturer's obligations | Informs the manufacturer | Informs the manufacturer |
Importers and distributors also have obligations concerning specified conformity information, cooperation with authorities and certain significant cybersecurity risks. Their duties differ from the manufacturer's product-level obligations and should not be reduced to the table alone.
What an SBOM is under the Cyber Resilience Act
A software bill of materials, or SBOM, is an inventory of software components in a product. Annex I requires manufacturers to identify and document vulnerabilities and components, including an SBOM in a commonly used machine-readable format. It must cover at least the top-level dependencies.
An SBOM is part of a wider set of technical documentation and vulnerability-handling records. It is not a general publication requirement. A market-surveillance authority may request conformity information and documentation. Information for users must state where the SBOM is available only if the manufacturer chooses to make it available to them.
For a final-product manufacturer, the practical challenge is often understanding the contents of purchased controllers, firmware, libraries and other integrated components. That is where supplier evidence becomes useful.
Separate risk assessment from component due diligence
The product cybersecurity risk assessment and due diligence for integrated third-party components are connected, but they are not the same activity.
The manufacturer must assess the cybersecurity risks of its complete product. When it integrates third-party components, including qualifying free and open-source software, it must exercise due diligence so those components do not compromise the product's cybersecurity.
The European Commission's non-binding guidance explains this distinction. It recommends that manufacturers define the security needs a component must meet and verify, on a risk-based basis, whether it meets them. Relevant evidence may include:
- Technical specifications and interface documentation.
- Security documentation and vulnerability-handling information.
- Conformity or assurance documentation from the component manufacturer.
- Testing by the final-product manufacturer, where appropriate.
These are examples of implementation practice, not a fixed statutory procurement checklist. The appropriate depth of verification depends on the component, the final product, the intended use and the risks identified.
Should manufacturers ask suppliers for an SBOM
The Act requires a manufacturer to create an SBOM for its own product. It does not expressly require every purchaser to obtain an SBOM from every supplier.
A supplier SBOM can nevertheless be valuable evidence. It can help a manufacturer understand a purchased component's software content, identify known vulnerabilities and build the SBOM for the complete product. It may sit alongside supplier declarations, technical documentation, security requirements, update commitments and testing evidence.
However, a supplier SBOM does not transfer responsibility for the complete product. Nor does supplier conformity evidence automatically prove that the final product conforms. The final-product manufacturer must still assess the product's cybersecurity risks and exercise appropriate due diligence for integrated components.
Handling a vulnerability in an integrated component
Article 13(6) creates an important upstream hand-off. If a manufacturer identifies a vulnerability in an integrated component, it must report that vulnerability to the person or entity that manufactures or maintains the component. It must also address and remediate the vulnerability under the applicable requirements.
If the final-product manufacturer develops a relevant modification, it must share the code or documentation with the component manufacturer or maintainer where appropriate, including in a machine-readable format where appropriate.
This upstream communication is distinct from regulatory reporting under Article 14. Article 14 has separate triggers for actively exploited vulnerabilities and severe incidents. Not every vulnerability creates an Article 14 notification duty, so product teams should keep the component-maintainer escalation process separate from their regulatory reporting assessment.
A machinery example
A machinery manufacturer integrates a purchased controller into a production system and places the complete machine on the market under its own name. The controller supplier may provide technical documentation, update information, security evidence and, where available, an SBOM for the controller.
The machinery manufacturer should use that material to support its own work. It must assess how the controller affects the security of the complete machine, document the relevant evidence, test the integration where appropriate, and ensure that suitable remediation reaches the operator during the support period.
If a vulnerability is found in the controller, the supplier may develop the component-level correction. The machinery manufacturer still needs a product-level process to evaluate, integrate, validate and deliver the correction safely for the complete machine.
Practical evidence to maintain
A workable implementation approach is to maintain clear hand-offs across engineering, procurement, product security and suppliers. This may include:
- A record of the actual economic-operator role for each product.
- The product cybersecurity risk assessment and decisions arising from it.
- Component inventories and the SBOM for the complete product.
- Security, update and vulnerability-handling evidence obtained from suppliers.
- The rationale for component verification and any tests performed.
- A process for receiving, assessing and remediating vulnerabilities.
- Contact routes for reporting integrated-component vulnerabilities to maintainers.
- A separate process for assessing Article 14 reporting triggers.
- Records showing how security updates and vulnerability information are managed throughout the support period.
The Commission's manufacturer overview is a useful accessible cross-check, but the Regulation remains the controlling legal text. In practice, the important operational question is not whether a supplier has supplied a single document. It is whether engineering, procurement, product security and the supplier can provide the evidence, decisions, updates and escalation paths needed to manage the cybersecurity of the complete product.