When a FOSS Patch Becomes a Legal Obligation: CRA Vulnerability Handling and the New Responsibility of Integrators

The Cyber Resilience Act (CRA) introduces a subtle but profound shift in how manufacturers must think about open source software. For years, integrating free and open-source software (FOSS) into products largely meant relying on upstream maintainers for fixes, monitoring vulnerabilities, and updating when patches became available. Under the CRA, that passive model no longer holds. In certain situations, a vulnerability in an open-source component does not merely create a technical issue, it creates a legal obligation to act.

This is the moment when a FOSS patch becomes more than a good practice. It becomes a regulatory duty.

From Passive Consumption to Active Responsibility

Under Annex I, Part II of the CRA, manufacturers must address and remediate vulnerabilities without delay during the product’s support period. This obligation applies to the product “in its entirety,” including all integrated components.

The European Commission’s FAQ clarifies this further. If a manufacturer integrates a component, including a free and open-source component and identifies a vulnerability, it must address and remediate it. If the original maintainer does not provide a fix, is no longer active, or no longer supports the component, the integrating manufacturer cannot simply point upstream. It must mitigate the risk through other means, such as disabling functionality, replacing the component, or developing a patch itself.

This fundamentally changes the governance model of open source in regulated products. Integration now implies stewardship.

Article 13(6): The Obligation to Share the Fix

The shift does not stop at remediation. Article 13(6) introduces an additional requirement: where a manufacturer develops a patch for a component, it must share that patch with the person or entity maintaining the component.

This provision reinforces coordinated vulnerability handling and ecosystem resilience. But it also introduces new legal and operational considerations. A manufacturer that modifies an open-source component to meet CRA obligations is no longer merely consuming upstream code, it is contributing to it under regulatory pressure. The patch is not optional goodwill. The law may require it.

Copyleft Meets Compliance

For components under copyleft licenses such as GPL, LGPL, AGPL, or MPL, the interaction becomes even more nuanced. A security patch may constitute a derivative work. Distribution of the modified component, whether in firmware, embedded systems, or downloadable updates, may trigger corresponding source code and notice obligations.

In many cases, regulatory and licensing requirements will align: both encourage transparency and upstream collaboration. But the alignment is not always seamless. Manufacturers must consider whether their remediation strategy affects distribution obligations, confidentiality concerns, or export control sensitivities.

The CRA does not override open source licensing. It operates alongside it. This means vulnerability remediation decisions now sit at the intersection of regulatory compliance and copyright law.

When Upstream Support Ends

The CRA also addresses scenarios where integrated components reach the end of their support period. Even if the manufacturer continues its product support period—which in many sectors must last at least five years—it still needs to handle vulnerabilities in unsupported components.

The Commission’s guidance makes clear that in such cases, the manufacturer may need to replace the component or develop a patch on its own. The absence of upstream maintenance does not relieve the manufacturer of its obligations.

This has major implications for long-lived industrial systems, embedded devices, and products with extended lifecycles. Component selection is no longer just about functionality and cost. It is about long-term maintainability and risk allocation.

Supply Chain Visibility Becomes Essential

These obligations elevate the role of Software Bills of Materials (SBOMs) and Software Composition Analysis (SCA). Without accurate visibility into integrated components, their versions, and their support status, a manufacturer cannot meaningfully assess whether a vulnerability creates a remediation obligation.

An SBOM is no longer just a transparency artifact. It becomes a compliance instrument. It allows manufacturers to identify affected products quickly, evaluate whether upstream patches exist, assess licensing consequences of developing their own fixes, and document remediation decisions for market surveillance authorities.

This way, SBOM-driven governance transforms regulatory risk into manageable engineering workflows.

A New Governance Model for FOSS

The CRA does not discourage using open source components. On the contrary, it explicitly recognises and accommodates free and open-source components. But it restructures responsibility.

Where manufacturers integrate FOSS into products placed on the EU market, they assume responsibility for its cybersecurity posture during the support period. If a vulnerability emerges and no upstream fix is forthcoming, the obligation to act remains. In certain cases, the manufacturer must create and share a patch, not just as best practice but as a requirement.

This is a new reality for product manufacturers. Open source remains a powerful driver of innovation, but in regulated markets, manufacturers must now embed it within structured vulnerability handling, licensing awareness, and lifecycle governance.

At Bitsea, we help organizations navigate this evolving landscape by combining SBOM-driven transparency, deep open-source auditing, vulnerability analysis, and regulatory expertise. This ensures that when a FOSS patch becomes a legal obligation, the manufacturer addresses it strategically, compliantly, and with full supply chain visibility.