Under the Cyber Resilience Act, the company placing the finished product on the market reports an actively exploited vulnerability in a bought-in component. Article 14 carries the reporting duty. Article 13(6) adds a report to the component maintainer.
Key takeaways
- A system integrator that assembles components and sells the result under its own name is the manufacturer of that product under the Cyber Resilience Act.
- Article 14 reporting applies from 11 September 2026, including to products already on the market. The remaining obligations apply from 11 December 2027 under Article 71(2).
- Article 13(6) requires a manufacturer that finds a vulnerability in an integrated component to report it to the person or entity manufacturing or maintaining that component.
- Annex I, Part II, point (1) requires a software bill of materials covering the top-level dependencies as a floor. A hardware inventory carries no separate CRA obligation.
- Distributors and importers file no Article 14 report, and their own duties start on 11 December 2027.
Why placing on the market decides who reports
The Cyber Resilience Act attaches obligations to the act of placing a product with digital elements on the Union market. A company that buys components, assembles them into a product, and supplies that product under its own name is the manufacturer of the finished product. Responsibility covers the product as a whole, including every component inside it.
The consequence for a system integrator is direct. When a vulnerability in an integrated component is actively exploited in the finished product, the integrator files the Article 14 notification. The component supplier files nothing on the integrator's behalf.
A company that helps a manufacturer integrate components without supplying the finished product reaches a different answer. It places no product on the market, so no Article 14 report arises for it.
What the component maintainer is owed
Article 13(6) sets a second duty that runs upstream and is separate from the Article 14 notification. A manufacturer that identifies a vulnerability in a component integrated into its product reports that vulnerability to the person or entity manufacturing or maintaining the component. Open source components fall inside the same provision.
Article 13(6) reaches further where the manufacturer builds a fix. The manufacturer shares the relevant code or documentation with the component maintainer, where appropriate in a machine-readable format.
The two duties run on different clocks. Article 13(6) states no deadline in hours. Article 14 states 24 hours for the early warning and 72 hours for the vulnerability notification.
Which role reports, and from when
| Role | Files an Article 14 report | Applies from |
|---|---|---|
| System integrator supplying the finished product under its own name | Yes, as manufacturer | 11 September 2026 |
| Component supplier placing the component on the market itself | Yes, for its own product | 11 September 2026 |
| Open source software steward involved in developing the product | Yes, under the lighter Article 24(3) regime | 11 September 2026 |
| Importer | No | Importer duties from 11 December 2027 |
| Distributor | No | Distributor duties from 11 December 2027 |
| Installer supplying no product under its own name | No | Not applicable |
Which bill of materials the CRA requires
Annex I, Part II, point (1) requires a manufacturer to identify and document the components and vulnerabilities in the product. The named instrument is a software bill of materials, in a commonly used and machine-readable format, covering the top-level dependencies as a floor.
Two limits are worth stating. The obligation names software, so a hardware inventory carries no separate CRA obligation. And top-level is a floor, so deeper transitive coverage is permitted and is often what a vulnerability question actually needs.
A hardware inventory still earns its place in practice. Article 13(6) expects a manufacturer to share a software or hardware modification with the component maintainer where it develops one, and answering which unit shipped with which part is what makes that possible.
The Regulation prescribes no SBOM format. Commonly used and machine-readable is the test, which in practice points at SPDX or CycloneDX. Our SBOM validator checks a document against the BSI baseline and the 2026 minimum elements side by side.
Which CSIRT receives the report
Article 14(7) routes the notification to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment in the Union. Main establishment means the Member State where decisions about the cybersecurity of the manufacturer's products are predominantly taken. A manufacturer with no establishment in the Union works down a four-step order based on authorised representative, importer, distributor, then users.
One submission through the ENISA single reporting platform reaches the coordinating CSIRT and ENISA at the same time. Our full answer on reporting routes covers the four-step order and the delayed dissemination cases.
Sources
- Regulation (EU) 2024/2847, Article 13
- Regulation (EU) 2024/2847, Article 14
- Regulation (EU) 2024/2847, Article 24
- Regulation (EU) 2024/2847, Article 71
- Regulation (EU) 2024/2847, Annex I
Published by Porta Regulus B.V. Our editorial policy carries the company registration.
Build the component inventory and the Article 14 report path before 11 September 2026.
Get started freeFrequently asked questions
Who files the Article 14 report when the vulnerability sits in a component we bought?
The company placing the finished product on the market files it. Buying a component in moves no duty to the supplier. The integrator reports the actively exploited vulnerability for its own product under Article 14, and Article 13(6) then requires a separate report to whoever manufactures or maintains the component.
Does the CRA require a hardware bill of materials?
Annex I, Part II, point (1) names a software bill of materials in a commonly used and machine-readable format, covering the top-level dependencies as a floor. A hardware inventory carries no separate obligation under that point. Keeping one is still practical, because Article 13(6) expects a manufacturer to share a hardware modification with the component maintainer where it develops one.
Does the CRA prescribe an SBOM format?
Annex I, Part II, point (1) sets the test as commonly used and machine-readable, and names no specific format. SPDX and CycloneDX both satisfy that test in practice. Top-level dependencies are the floor, so deeper transitive coverage is permitted.
Do open source software stewards have to report actively exploited vulnerabilities?
Article 24(3) applies Article 14(1), (3) and (8) to an open source software steward that develops the product with digital elements or provides the systems used to develop it. A steward outside that description carries no 24-hour or 72-hour duty, and voluntary reporting under Article 15 stays open. CE marking and the EU Declaration of Conformity apply to neither case.