How Downstream Manufacturers Should Handle Open Source Components

Article 13(5) Makes Open-Source Component Due Diligence Explicit

Article 13(5) requires manufacturers to exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements. The provision expressly includes free and open-source software components that have not been made available on the market in the course of commercial activity. A manufacturer therefore cannot skip component security analysis merely because the dependency came from a community repository rather than a commercial supplier.

• Third-party component due diligence is mandatory.
• Open-source components are expressly covered.
• Non-commercial upstream supply does not remove the downstream duty.
• The finished product remains the manufacturer's responsibility.

Evaluate the Component Before Integration

Due diligence should begin before the dependency becomes deeply embedded in the product. The manufacturer should understand what the component does, which privileges it receives, what data it processes, how actively it is maintained, which versions are supported and whether known vulnerabilities or architectural limitations are relevant to the product's cybersecurity risk assessment. The CRA does not prescribe a single scoring method for open-source projects, so the depth of evaluation should be proportionate to the component's role and the risk it creates in the finished product.

• Understand component functionality.
• Identify privileges and trust boundaries.
• Review maintenance and version status.
• Review known vulnerabilities.
• Connect the component to the product risk assessment.

An Open-Source Licence Does Not Transfer Responsibility Upstream

The fact that a dependency is distributed under a free and open-source licence does not make upstream volunteers responsible for the downstream manufacturer's commercial product. The manufacturer decides to integrate the component and must ensure the resulting product complies with the CRA. Upstream project information can support that work, but the manufacturer must make its own risk, testing and remediation decisions for the exact component version and product architecture it uses.

• Licence terms do not replace CRA role allocation.
• The downstream manufacturer owns its product decision.
• Upstream security information is evidence, not a transfer of responsibility.
• Assess the exact version and integration context.

Track Open-Source Components in the Product SBOM

Annex I Part II requires manufacturers to identify and document vulnerabilities and components contained in their products, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies. Open-source dependencies therefore need to be visible in the manufacturer's component records. An SBOM supports vulnerability response by allowing the manufacturer to determine rapidly whether a disclosed issue affects a shipped product or supported version.

• Include relevant open-source dependencies.
• Use machine-readable component information.
• Cover at least top-level dependencies.
• Associate dependencies with product versions.
• Maintain the information as dependencies change.

Monitor Dependencies After the Product Is Released

Component due diligence is not a one-time procurement check. Article 13(7) requires manufacturers to systematically document relevant cybersecurity aspects, including vulnerabilities they become aware of and relevant information provided by third parties. The cybersecurity risk assessment should be updated where applicable. A manufacturer therefore needs an ongoing mechanism for learning about vulnerabilities in significant open-source dependencies during the product's support period and determining their effect on supported product versions.

• Monitor upstream security information.
• Track vulnerabilities against shipped versions.
• Document relevant third-party information.
• Update the risk assessment where applicable.
• Retain evidence of remediation decisions.

Report Identified Component Vulnerabilities Upstream

Article 13(6) requires a manufacturer that identifies a vulnerability in an integrated component, including an open-source component, to report that vulnerability to the person or entity manufacturing or maintaining the component. The requirement supports coordinated remediation across the software supply chain. A downstream manufacturer should maintain usable upstream contact information or project security channels for significant dependencies so it can fulfil this duty when a vulnerability is discovered internally.

Upstream Notification Does Not Replace Downstream Remediation

The same Article 13(6) provision requires the manufacturer to address and remediate the component vulnerability in accordance with Annex I Part II. The manufacturer cannot simply send an issue upstream and wait indefinitely while its own product remains exposed. Depending on the circumstances, remediation can involve upgrading the dependency, backporting an upstream patch, disabling vulnerable functionality, changing configuration, applying a local fix or otherwise reducing the product risk while a durable correction is developed.

• Notify upstream.
• Assess the impact on the finished product.
• Remediate the downstream product.
• Test the chosen fix.
• Provide security updates where required.

Manufacturer-Developed Fixes May Need to Be Shared Upstream

Where the manufacturer develops a software or hardware modification to address a vulnerability in the integrated component, Article 13(6) requires the relevant code or documentation to be shared with the person or entity manufacturing or maintaining the component where appropriate. The provision also refers to machine-readable format where appropriate. The goal is to support correction at the component level rather than allowing a useful security fix to remain only inside a proprietary downstream integration.

• Share relevant fixes where Article 13(6) requires it.
• Code can be relevant.
• Technical documentation can be relevant.
• Machine-readable form can be appropriate.
• Coordinate disclosure responsibly.

Forks and Local Patches Need Their Own Control

Manufacturers sometimes maintain patched forks of open-source dependencies. A fork can solve an immediate vulnerability but also create long-term maintenance risk if it diverges from upstream releases. The manufacturer should record local modifications, map them to upstream versions and determine how future security fixes will be merged. Where a local patch addresses a vulnerability in the underlying component, Article 13(6) should also be considered for upstream sharing.

• Record local patches.
• Track the upstream base version.
• Monitor divergence from upstream.
• Plan future security merges.
• Consider Article 13(6) fix sharing.

Voluntary Security Attestation Can Support Due Diligence

Article 25 allows the Commission to establish voluntary security attestation programmes for qualifying free and open-source software specifically to facilitate the Article 13(5) due diligence of manufacturers integrating those components. Such an attestation can become one source of evidence about an upstream component. It does not remove the downstream manufacturer's need to consider its own integration architecture, configuration, product risks and supported version.

• Article 25 is intended to facilitate due diligence.
• Attestation can provide structured upstream evidence.
• Participation is voluntary under the Article 25 framework.
• Product-specific manufacturer analysis remains necessary.

Create an Open-Source Component Acceptance Record

For material dependencies, the manufacturer should preserve a concise component acceptance record. It can identify the component, source, licence, selected version, intended function, maintainer or project contact, known vulnerabilities, security evaluation, SBOM entry, local modifications, update method and rationale for integration. The record should connect to the wider cybersecurity risk assessment and be revisited when the component version or product architecture changes.

• Record component identity and version.
• Record project and maintainer information.
• Record security evaluation.
• Record local modifications.
• Connect the component to the SBOM.
• Review after upgrades or architectural changes.

Treat Open Source as a Managed Product Dependency

The most reliable CRA approach is to treat important open-source dependencies as managed product dependencies rather than anonymous code copied into the build. Ownership should exist for version selection, vulnerability monitoring, upgrade decisions, upstream coordination and technical documentation. This makes the manufacturer's due diligence demonstrable and helps security teams react quickly when new vulnerabilities affect the open-source ecosystem.

• Assign dependency ownership.
• Maintain version visibility.
• Maintain upstream contact routes.
• Monitor vulnerability information.
• Plan component upgrades.
• Retain compliance evidence.