CRA Vulnerability and SBOM Obligations along the Supply Chain

  • Markus Müller
  • Published on
  • 9 min read

If you buy a machine, you buy the machine. Not the controller inside it, not the bus system, not a supplier's embedded firmware. This distinction regularly causes confusion under the Cyber Resilience Act (Regulation (EU) 2024/2847), or CRA. The most common question is “What does a manufacturer have to do?” The question that really matters is a different one: who in the supply chain delivers what to whom, and who fixes a vulnerability in the end?

If you build a machine and install a controller in it, you are responsible toward your operator for the vulnerabilities and updates of the whole machine. The controller manufacturer supplies you with its component, its evidence, and its updates. It does not travel to your customer to close a software flaw in the installed controller. That is your job as the manufacturer of the machine.

This article places the CRA roles along the supply chain. It focuses on what causes the most friction in practice: the relationship between supplier and manufacturer.

For a full overview of all obligations of manufacturers, see our main CRA page.

Contents
  1. CRA roles at a glance
  2. What an SBOM is under the CRA
  3. When does an internal component fall under the CRA itself?
  4. What evidence and which SBOM you need from your suppliers
    1. Should you ask your suppliers for an SBOM?
  5. Machinery example: the machine is the product, not the controller
  6. What machine builders should do now

CRA roles at a glance

The CRA distinguishes economic operators by their position in the supply chain. The manufacturer carries the largest set of obligations. Importers and distributors mainly have checking duties and must pass on information.

TaskManufacturerImporterDistributor
Draw up a software bill of materials (SBOM)yesnono
Remediate vulnerabilities and provide updatesyesnono
Check conformity (CE marking, documentation)establishes itchecks before placing on the marketchecks when making available
On becoming aware of a vulnerabilityhandles and reports itinforms the manufacturerinforms the manufacturer
Report actively exploited vulnerabilities to authoritiesyesno (informs the manufacturer)no (informs the manufacturer)

The manufacturer carries the substantive obligations for vulnerability handling and the SBOM. Before placing a product on the market, the importer checks, among other things, the CE marking, the technical documentation, and the conformity assessment. If it becomes aware of a vulnerability, it informs the manufacturer without undue delay. The distributor checks the CE marking and whether the manufacturer has met its obligations. It also reports any vulnerability it becomes aware of to the manufacturer.

One point matters for the supply chain. Anyone who places a product on the market under their own name or trademark, or substantially modifies it, is considered a manufacturer. The full obligations of manufacturers then apply. This often affects machine builders, as explained below.

What an SBOM is under the CRA

A software bill of materials (SBOM) is an inventory of the software components of a product. The CRA requires the manufacturer to identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format. The legal minimum depth is limited: the SBOM must cover “at the very least the top-level dependencies” of the product. At this point, the law does not require a complete analysis down to the last transitive dependency.

The SBOM is not a public document. The manufacturer does not have to publish it, only provide it to the market surveillance authority on reasoned request. There is no obligation to hand the SBOM over to users either. The information requirements only ask the manufacturer to state where the SBOM can be accessed, if it decides to make it available.

The SBOM is therefore first and foremost an internal tool. This is exactly where the supply chain question begins: if you integrate third-party components, how do you know what is inside them?

When does an internal component fall under the CRA itself?

The CRA defines a product with digital elements as a software or hardware product, including components that are placed on the market separately. The decisive criterion in the text of the regulation is therefore whether the component is made available on the market separately.

It follows that a controller sold on the open market is a CRA product of its own manufacturer. It is marketed on its own, so the controller manufacturer carries the obligations of a manufacturer for it. If a component is only built into your machine and not offered on the market separately, it is not a product with digital elements in its own right. What is placed on the market is then the machine, and the obligations of manufacturers apply to the machine, including this component.

In practice, this means: if you buy a controller that is available on the market, it is a CRA product in its own right with its own manufacturer. As soon as you integrate it into your machine, it becomes an integrated third-party component for you, and specific due diligence obligations apply to it.

What evidence and which SBOM you need from your suppliers

This is the core of the supplier relationship. If you integrate components from third parties, you must exercise due diligence so that these components do not compromise the cybersecurity of the overall product. This explicitly also applies to free and open-source software.

Recital 34 of the CRA spells out what due diligence means in concrete terms. The appropriate measures it names include:

  • verifying the conformity of the component (including the CE marking, where the CRA applies)
  • checking that the component receives regular security updates
  • consulting relevant vulnerability databases
  • carrying out additional security tests

The European Commission's guidance on applying the Cyber Resilience Act is not binding on economic operators. Only the Court of Justice of the European Union can give a binding interpretation of the CRA. The guidance describes two complementary obligations: the risk assessment for the overall product and due diligence for integrated third-party components. For conformity purposes, integrated third-party components are treated like external inputs, whose properties the manufacturer must verify through due diligence when integrating them. The manufacturer cannot redevelop third-party components itself, so it must check whether they deliver what its product needs from them. As evidence, the guidance names, for example, technical specifications, security documentation, or conformity and assurance documents from the component manufacturer, supplemented by the manufacturer's own functional tests where appropriate.

If the manufacturer finds a vulnerability in an integrated component, it reports it to the person or entity manufacturing or maintaining that component. It then remediates the vulnerability in line with the CRA requirements. If it has developed a fix itself, it shares the code or documentation with the component maintainer, where appropriate in a machine-readable format.

Should you ask your suppliers for an SBOM?

The CRA requires every manufacturer to draw up an SBOM for its own product. There is no explicit rule that says “request an SBOM from your supplier.” Doing exactly that is, however, a well-founded practical recommendation. The reasoning is straightforward. Recital 34 requires you to know and verify the properties of integrated components, and the guidance explicitly names documentation from the component manufacturer as suitable evidence. A supplier's SBOM is exactly that kind of documentation. It shows which parts are inside the purchased component and makes it easier for you to check vulnerability databases.

In Germany, for example, the VDMA (German Mechanical Engineering Industry Association) has published a document series on supply chain security (in German) that points in the same direction. It recommends supplier self-assessments, clear minimum requirements in the specification, and contractual safeguards for these points. If a supplier provides conformity assessments for its component, the machine builder can rely on the documented conformity for that component. This does not release the machine builder from due diligence for the overall product, but it reduces the effort for the individual component.

Where do you stand on SBOM and supplier management?

The CRA readiness check shows you in a few minutes which processes you already cover and where the biggest gaps are.

Start the readiness check

Machinery example: the machine is the product, not the controller

Take a machine builder that integrates a purchased controller into its equipment. Under the CRA, the machine is a product with digital elements that in turn consists of sub-products that are also affected by the CRA. Whoever places the overall product on the market under their own name or trademark is the manufacturer and carries the full obligations of manufacturers for the machine. The CRA requires the manufacturer to ensure that vulnerabilities are handled during the support period, for the product including its components.

Toward the operator, this means: the machine builder is responsible for the vulnerabilities and updates of the whole machine, regardless of which controller is installed. The operator should not need to see what is inside. For the operator, it is one manufacturer's machine, and that one manufacturer is the point of contact.

A hardware analogy makes this clear. A manufacturer such as Siemens or ABB does not replace a defective controller directly in the delivered machine either. The machine builder does that as part of its responsibility for the machine. The same logic applies to software updates and vulnerability handling. The component manufacturer supplies the updates for its component to you. What reaches the operator is your responsibility as the manufacturer of the machine.

Obligations along the supply chain under the CRA: the component manufacturer supplies the component, SBOM, and updates to the machine builder; the machine builder is responsible to the operator for the whole machine and reports vulnerabilities in the component to the component manufacturer

For machinery, the Machinery Regulation (Regulation (EU) 2023/1230) also comes into play. Among other things, it requires machinery to be protected against corruption and the software installed for safe operation to remain identifiable. Machinery can therefore fall under both the CRA and the Machinery Regulation at the same time. How the two acts interlock is covered separately in our article on how the CRA and the Machinery Regulation overlap.

What machine builders should do now

Supplier management is at the center. The following steps are a practical recommendation derived from the obligations described above:

  • Clarify your own role under the CRA. If you integrate and place on the market under your own name or trademark, you are, as a rule, the manufacturer within the meaning of the CRA.
  • Ask your suppliers for evidence of conformity (including the CE marking, where the CRA applies) and for the SBOM of their components. Secure these requirements by contract.
  • Build your own SBOM for your machine that covers at least the top-level dependencies.
  • Establish a process for vulnerability handling and for providing updates, including a reporting channel to the component maintainers.
  • Prepare the reporting channels for actively exploited vulnerabilities so that you can meet the legal deadlines.

If you set up these five points properly, you cover most of the CRA's supply chain requirements. You can also show the operator and the market surveillance authority that responsibility for the whole machine lies with one party: you.

Tackle CRA implementation in machine building

Secuvise supports machine builders from clarifying their role to building the SBOM and achieving CE conformity. Talk to us about your specific products.

Book a call

Choosing a CRA consultant? Here is how to find the right one.

Get the guide

Book a call

Send us your request. Together we will look at where your company stands, which questions are still open, and what the sensible next steps are.

For information on how we process your data, see our privacy policy.

Guide: How to choose the right CRA consultant

CRA consulting offers are hard to compare. One provider delivers only a gap analysis, another also supports the technical implementation, and both call themselves “CRA consultants.” If you ask the wrong questions, you end up paying for services you don't need, or you find out halfway through the project that key expertise is missing.

Our guide shows manufacturers what really matters when choosing a provider, from the expertise you need to the right pricing model and the 20 questions you should ask every provider.

What the guide covers:

  • the seven areas of expertise a complete CRA implementation requires
  • four support models depending on your in-house capacity and expertise
  • 20 specific questions for your next provider meeting
  • a red flag card for spotting warning signs quickly
  • a scoring sheet with rating guidance for a structured comparison of providers

Download it for free

Newsletter

For information on how we process your data, see our privacy policy.

Free templates: CRA reporting process

Prepare your company for the reporting obligations under the Cyber Resilience Act. You get process descriptions and templates tested in practice for:

  • reporting actively exploited vulnerabilities
  • reporting severe incidents
  • the required early warning notifications, notifications, and final reports
  • clear responsibilities, escalation paths, and deadlines

Enter your contact details and we will email you the files.

Newsletter

For information on how we process your data, see our privacy policy.

Free template: Risk assessment according to EN 50742

We use this template in our consulting projects for systematic threat assessment. You get an Excel template with:

  • a structured threat assessment for your machinery
  • a systematic way to determine safety-related security levels (SRSL)
  • documentation of vulnerabilities and protective measures

Enter your contact details and you will receive the template within minutes.

Newsletter

For information on how we process your data, see our privacy policy.

Free template: SBOM

We use this template in our consulting projects to meet the CRA requirements for the software bill of materials.

Enter your contact details and you will receive the template within minutes.

Newsletter

For information on how we process your data, see our privacy policy.

Free template: Vulnerability disclosure policy

We use this template in our consulting projects to meet the CRA requirements for vulnerability handling. You get a Word template with:

  • a structure based on EN 40000-1-3
  • predefined sections for reporting channels, response times, and responsibilities
  • safe harbor clauses for security researchers

Enter your contact details and you will receive the template within minutes.

Newsletter

For information on how we process your data, see our privacy policy.