Are we responsible for vulnerabilities in third-party components?

For your product, yes. The CRA requires vulnerabilities of the product “including its components” to be handled effectively. Who wrote the component makes no difference. On top of that, the regulation expects you to pass a fix you developed to whoever produces or maintains that component.

When does our component become a product of its own?

As soon as you place it on the market separately. The definition of a Product with digital elements explicitly includes components being placed on the market on their own. Whether it reaches end users or only other manufacturers is irrelevant. Marketing it independently brings the full set of obligations.

Does this apply to libraries given away free of charge?

Being free is no shield in itself: the manufacturer definition expressly covers marketing free of charge. For the open-source world, however, the CRA provides a separate and much lighter role, that of the open-source software steward, who is explicitly not a manufacturer. Non-commercial open-source development is therefore not pulled into manufacturer obligations.

Cyber Resilience Act

Component

Legal definition Art. 3(6) CRA

“software or hardware intended for integration into an electronic information system”

Regulation (EU) 2024/2847, Art. 3(6) CRA

A component is Software or Hardware meant for integration into an electronic information system. That is one of the shortest definitions in the regulation, and its decisive word is intended. Purpose counts, not size. A single library qualifies just as much as a full operating system embedded in a device.

The decisive fork

The Cyber Resilience Act (CRA) treats components completely differently depending on how they are marketed:

Built in and not marketed separately, the component is part of the product. Responsibility sits with the manufacturer of the product it is in.
Placed on the market separately, the component is itself a product with digital elements. Its supplier is its Manufacturer, with all the obligations.

The same library can therefore be both at once: a product in the hands of its supplier, and a component in the hands of whoever builds it in.

Why responsibility does not disappear upstream

A common misconception holds that responsibility for a bought-in component rests with the supplier. That is true for the supplier’s product, but not for yours. The CRA expressly requires vulnerabilities of the product including its components to be handled.

This is exactly where the Software Bill of Materials (SBOM) comes in: without a reliable record of the building blocks inside, the obligation cannot be met, because even the question “are we affected?” has no answer.

The return path to the component maker

The CRA contains a rule that gets little attention in practice: where a manufacturer has developed a software or hardware change to fix a vulnerability in a component, it shares the relevant code or documentation with the person or entity producing or maintaining that component, in a machine-readable format where appropriate.

The duty to repair your own product thus turns into a contribution to the supply chain. If you are patching anyway, plan the route back to the project at the same time.

What this means for procurement

Because responsibility for built-in components stays with you, the selection question shifts: not only function and licence matter, but how long a component is maintained and how quickly security information about it becomes available. The CRA explicitly names the support periods of integrated third-party components that provide core functions as a factor manufacturers may consider when setting their own Support period.

Practical questions

: For your product, yes. The CRA requires vulnerabilities of the product “including its components” to be handled effectively. Who wrote the component makes no difference. On top of that, the regulation expects you to pass a fix you developed to whoever produces or maintains that component.
: As soon as you place it on the market separately. The definition of a Product with digital elements explicitly includes components being placed on the market on their own. Whether it reaches end users or only other manufacturers is irrelevant. Marketing it independently brings the full set of obligations.
: Being free is no shield in itself: the manufacturer definition expressly covers marketing free of charge. For the open-source world, however, the CRA provides a separate and much lighter role, that of the open-source software steward, who is explicitly not a manufacturer. Non-commercial open-source development is therefore not pulled into manufacturer obligations.

This glossary is for orientation and does not constitute legal advice. The wording of Regulation (EU) 2024/2847 prevails.