Tech Support
Documentation
Login
Contact Us
Go straight to an AI summary of this blog post instead 
Key Takeaways
- Article 13(5) of the Cyber Resilience Act (CRA) requires due diligence on third-party components, open source included.
- Breaching Article 13 risks fines up to EUR 15 million or 2.5% of global annual turnover, whichever is higher.
- Non-binding Recital 34 ties due diligence to component risk and names four possible actions, but the method is yours to choose and document.
- Per the European Commission’s guidance, you don’t take on an open source component’s own CRA compliance when you integrate it. Your product’s compliance still covers the component, including handling its vulnerabilities for your support period, even after upstream stops fixing it.
- Recital 34’s actions don’t ask whether a package was built from its published source or carries injected code, so your own risk assessment decides how far to check both.
If your product ships open source components, the Cyber Resilience Act (CRA) requires you to exercise due diligence on them from 11 December 2027. The European Commission’s non-binding guidance adds that maintainers who don’t supply their open source components commercially owe you nothing under the CRA. Article 13(5) extends your due diligence duty even to those components, so a library its maintainer doesn’t monetize still counts.
How much due diligence is enough? The CRA leaves that open, and Recital 34 scales the level to the component’s risk and lists example actions without requiring any one of them. None of those actions asks whether the package your product runs on was built from its published source or carries code that doesn’t belong there. The call is yours, and falling short can draw administrative fines (Article 64(2)).
What the Cyber Resilience Act Says About Components You Didn’t Write
The EU Cyber Resilience Act, Regulation (EU) 2024/2847, puts the due diligence duty on manufacturers. A product with digital elements is a software or hardware product, including software or hardware components placed on the market separately (Article 3(1)). Article 3(13) defines a manufacturer as a natural or legal person who develops or manufactures such products, or has them designed, developed or manufactured, and markets them under its name or trademark. The definition applies whether the product is sold, monetized or given away.
A component is software or hardware intended for integration into an electronic information system (Article 3(6)), so an open source library your product is built on will generally qualify. Under Article 2(1), the CRA reaches products made available on the market whose intended purpose or reasonably foreseeable use includes a data connection to a device or network.
Article 3(22) defines “making available on the market” as supplying for distribution or use on the EU market in the course of a commercial activity, whether paid or free of charge. Supplying something for free can still be commercial. For open source, what matters is whether the publisher monetizes it, for example, by charging for it, making access to releases or updates depend on payment, or using it to sell other services (Recital 18; Commission guidance, section 3.2). A library its maintainer supplies outside a commercial activity isn’t covered as a product, but it’s still a component in yours.
Article 13(5) requires manufacturers to exercise due diligence when integrating components sourced from third parties, so those components don’t compromise the cybersecurity of the product. It expressly includes free and open source components that haven’t been made available on the market in the course of commercial activity. Article 13 applies from 11 December 2027 (Article 71(2)).
Breaching Article 13 can draw administrative fines of up to EUR 15,000,000 or, for an undertaking (EU-speak for a business), up to 2.5% of its total worldwide annual turnover for the preceding financial year, whichever is higher (Article 64(2)).
Compensation for damage from defective products falls under a separate regime, Directive (EU) 2024/2853, the Product Liability Directive. Recital 31 calls it complementary to the CRA and says a lack of security updates that causes damage could trigger a manufacturer’s liability under it.
What Due Diligence Does and Doesn’t Pin Down
The Cyber Resilience Act requires manufacturers to exercise due diligence, and the non-binding Recital 34 is where the text gets more specific. It says the appropriate level depends on the nature and level of cybersecurity risk associated with a component, and that due diligence should take into account one or more of the four listed actions (Table 1). The Commission’s FAQ on the CRA, a question-and-answer document separate from its guidance, adds further examples.
Table 1. Actions the sources name for due diligence on a component
| Action | Source | Basis |
|---|---|---|
| Where applicable, check that the component’s maker has demonstrated conformity with the CRA, for example, through the CE marking | Recital 34 | Recital (interpretive) |
| Check that the component receives regular security updates, for example, through its update history | Recital 34 | Recital (interpretive) |
| Check that the component is free from vulnerabilities registered in the European vulnerability database or other public vulnerability databases | Recital 34 | Recital (interpretive) |
| Carry out additional security tests | Recital 34 | Recital (interpretive) |
| Run software composition analysis, isolate highly critical components, review the component’s software bill of materials (SBOM) when available, check its support period, verify its intended purpose fits the manufacturer’s use, or assess its maker’s security posture | Commission FAQ, answer 4.4.2 (version 1.4, 4 September 2026) | Commission FAQ (non-authoritative) |
Note: The Commission’s FAQ says its replies don’t add any requirements and that its views aren’t authoritative.
Recital 34 says “one or more,” so it doesn’t treat any single action as mandatory. Neither it nor Article 13(5) prescribes a method, a depth, or a record format.
Annex VII lists what the technical documentation must contain. It lists the risk assessment, the description of how software components feed into the overall system, and the test reports, but it has no item of its own for component due diligence. That doesn’t mean due diligence goes unrecorded. Article 13(7) still requires manufacturers to systematically document relevant cybersecurity aspects of the product, in proportion to its nature and cybersecurity risks.
With the level set by risk and the method left open, your own reasoning determines how much due diligence each component receives. The Commission’s guidance (points 170 and 171) splits the duty into two steps: use your product’s risk assessment to identify what the product needs from each component, then verify that the component provides it. A note of that verification, written when the component goes in, is more reliable than one reconstructed years later, because Article 13(5) ties the duty to integration.
What Stays With You and What Doesn’t
The Commission’s guidance of 27 July 2026 states that manufacturers that integrate open source components are not responsible for those components’ individual CRA compliance, even when they contribute source code to their maintenance (point 86). They keep their own obligations for the product, including due diligence under Article 13(5), as well as reporting vulnerabilities and sharing fixes under Article 13(6) (point 88).
Upstream stewards and maintainers have much lighter CRA duties than manufacturers. Article 3(14) defines an open source software steward as a legal person, other than a manufacturer, that has the purpose of systematically supporting, on a sustained basis, the development of specific free and open source products intended for commercial activities, and that ensures their viability. Article 24 gives stewards a light-touch regime: a documented cybersecurity policy, cooperation with market surveillance authorities and, in limited cases, parts of Article 14 reporting on exploited vulnerabilities and incidents (Article 24(3)). The guidance adds that maintainers of components that haven’t been made available on the market bear no obligations to the manufacturers that integrate them (point 87).
Your duties don’t stop at integration. Article 13(6) requires you to report a vulnerability you identify in a component to whoever manufactures or maintains it, to remediate it, and to share the relevant code or documentation if you built a fix. Article 13(8) requires that vulnerabilities in the product, including its components, be handled effectively throughout the support period you set. That period must be at least 5 years unless the product is expected to be in use for less than 5 years. Under the CRA, neither stewards (Article 24) nor maintainers of components that haven’t been made available on the market (point 87) owe you a support period, so a component version can stop getting upstream fixes while your product’s support period still has years to run.
The Listed Actions Don’t Ask How a Package Was Built
Three of the four actions in Recital 34 look at a component’s published record. They ask whether its maker has demonstrated conformity, whether it receives regular security updates, and what the vulnerability databases say about it. The fourth, additional security tests, is the only one that has you test the component yourself.
A component’s record describes how a project behaves, but it doesn’t say whether the package your product ends up running was built from the source the project publishes, or whether it carries code that doesn’t belong there. Build provenance and injected code do not appear anywhere among the actions in Recital 34 or in the examples in the Commission FAQ. Yet both directly affect whether a component compromises the product’s cybersecurity, the outcome that Article 13(5) exists to prevent.
Article 13(5) leaves the method open, so how you check provenance and look for injected code is up to you. Verifying a package against its source and screening it for malicious code before it enters your environment are two options. An SBOM lists what a product contains, but listing a package doesn’t verify how it was built or what code it carries. Your risk assessment should tell you how much of this each component needs.
Checking Packages Before They Reach Your Environment
TuxCare’s SecureChain screens the source code of open source packages it covers for known malware, suspicious code patterns, and other supply chain risks, then rebuilds the packages from that screened source code inside hardened, isolated build environments. Packages that fail screening are stopped before they reach your environment. Each package comes with an SBOM, a VEX document, and SLSA Level 3 provenance, a record of the source and build that produced it.
For components that are still actively maintained, SecureChain ships fixes in rebuilt packages under a service-level agreement as new vulnerabilities come up. Once upstream maintenance ends, TuxCare’s Endless Lifecycle Support keeps addressing vulnerabilities at every severity level, from critical ttolow, in the specific versions you run.
Can’t confirm what’s inside the packages you ship? See how SecureChain verifies them before they land in your builds.
FAQ
Who Is Affected by the Cyber Resilience Act?
The Cyber Resilience Act (CRA), the EU’s product cybersecurity regulation, covers products with digital elements that are made available on the EU market in the course of a commercial activity and whose intended purpose or reasonably foreseeable use includes a data connection to a device or network (Articles 2(1) and 3(22)). Duties fall mainly on manufacturers. Importers, distributors, and open source software stewards have separate duties (Articles 19, 20, and 24).
When Do the Cyber Resilience Act’s Provisions Apply?
The Cyber Resilience Act (CRA) entered into force on 10 December 2024. Chapter IV, on notifying conformity assessment bodies, has applied since 11 June 2026, and Article 14, on manufacturer reporting, since 11 September 2026. The rest applies from 11 December 2027 (Article 71(2)).
Does the CRA Replace Product Liability Rules?
No. Recital 31 of the Cyber Resilience Act (CRA) calls Directive (EU) 2024/2853, the Product Liability Directive, complementary. That Directive covers compensation for damage caused by defective products, while the CRA establishes manufacturers’ duties backed by administrative fines (Article 64). Article 65 applies EU rules on representative actions to infringements that harm or may harm consumers’ collective interests.
Can Manufacturers Use Open Source Software From Maintainers the CRA Doesn’t Bind?
Yes, as long as the manufacturer exercises due diligence so that those components don’t compromise the product’s cybersecurity. Article 13(5) of the Cyber Resilience Act (CRA) expressly covers open source components that haven’t been made available on the market commercially, and Recital 34 says the level depends on the component’s risk.
Do Manufacturers Have to Report Component Vulnerabilities to the Maintainer?
Yes, once they identify one. From 11 December 2027, Article 13(6) of the Cyber Resilience Act (CRA) requires a manufacturer to report a vulnerability in an integrated component, including an open source one, to whoever manufactures or maintains it, and to remediate it. If the manufacturer develops a fix, it must share the relevant code or documentation. This is separate from Article 14 reporting to authorities, which has applied since 11 September 2026.
