CRA and Open Source: Who Is Responsible for Security?

A library maintained by a volunteer ends up inside a commercial product. A foundation hosts its development infrastructure. A software vendor ships that library to thousands of customers. When a vulnerability appears, who is responsible under the EU Cyber Resilience Act (CRA)?

Not necessarily the volunteer. Not automatically the foundation. And the commercial vendor cannot simply transfer its product-security obligations upstream.

Regulation (EU) 2024/2847 distinguishes between non-commercial open-source activity, open-source software stewards, and manufacturers placing products with digital elements on the EU market. Those distinctions depend on the actual activities and legal responsibilities—not just the software licence. [1][2]

This article explains the boundaries. It is an engineering-oriented explanation, not a determination of any particular organisation’s legal status.

Open source is not automatically in—or out of—scope

The CRA generally addresses products with digital elements made available on the EU market in the course of commercial activity. Free and open-source software (FOSS) is not automatically a commercial product merely because it can be used commercially. Equally, publishing source code under an open-source licence does not exempt a manufacturer that commercially supplies an in-scope product. [1][2]

Recital 18 makes several important distinctions:

• Funding or contributions from commercial manufacturers do not by themselves make upstream development commercial.
• Regular releases do not by themselves establish commercial supply.
• A non-monetised FOSS component supplied for integration by other manufacturers is treated differently from a component monetised by its original manufacturer.
• People contributing code to FOSS products that are not under their responsibility are not thereby made responsible under the CRA.

These are not universal exemptions for every sponsored or free-to-download project. Assess what is supplied, by whom, under whose responsibility, and in what commercial context. The Commission’s implementation guidance offers additional fact-dependent examples. [1][2][3]

Contributor, steward or manufacturer?

The labels are not interchangeable. An individual maintainer is not a steward simply because their project is widely used. A foundation is not necessarily a steward merely because it exists. A company can also have different roles for different products and activities. [1][2]

What makes a steward different?

Article 3(14) defines the open-source software steward as a legal person whose purpose or objective is to provide systematic, sustained support for the development of particular FOSS products intended for commercial activities, and that plays a main role in ensuring their viability. [1]

Examples of relevant support can include governance, managing development infrastructure, and coordinating project development. The role is not restricted to charitable foundations; qualifying organisations can operate in a business context. But an organisation’s title, sponsorship badge or repository ownership alone cannot settle the assessment. [1][2]

Steward status is not a reduced manufacturer certification. The CRA deliberately creates a distinct regime, and a steward acting solely in that capacity cannot affix CE marking to the FOSS product it supports. [1]

What Article 24 actually requires

Article 24 imposes three main categories of obligation on qualifying stewards:

1. Document a verifiable cybersecurity policy. It must foster secure development, effective vulnerability handling, voluntary vulnerability reporting, remediation and information sharing within the open-source community.
2. Cooperate with market surveillance authorities. On a reasoned request, provide the relevant cybersecurity-policy documentation and cooperate in mitigating cybersecurity risks.
3. Meet specified reporting and user-information obligations. Article 24(3) applies selected Article 14 provisions within carefully defined limits. [1]

The first two are legal obligations, not a mandate to buy a particular scanning platform, obtain a SLSA level, sign every commit or produce a particular SBOM format.

A practical implementation could use a SECURITY.md disclosure channel, documented triage ownership, protected release processes, vulnerability advisories, escalation contacts and a maintained record of security decisions. Those are engineering recommendations: the policy and the evidence of its operation matter more than a named tool.

The CRA also treats stewards differently in enforcement: Article 64(10) excludes them from the regulation’s administrative-fine regime. That does not remove Article 24 obligations or authority oversight. [1][2]

When upstream code becomes a commercial product

Suppose a vendor incorporates an open-source parser into a network appliance sold in the EU. The parser’s volunteer maintainer does not automatically become the appliance’s manufacturer. Under Article 13(5), the commercial vendor must exercise due diligence when integrating components from third parties, ensuring they do not compromise the security of the product. [1]

For engineering teams, this means keeping an inventory of shipped dependencies, evaluating known vulnerabilities, monitoring upstream advisories, and retaining evidence of remediation decisions. Keeping a build-time SBOM and evaluating reachability via VEX is how commercial vendors document component due diligence (see our detailed guide on SBOMs and the EU Cyber Resilience Act: Building Audit-Ready Evidence ). The manufacturer must address the security of the product it supplies, even when the affected code originated elsewhere.

Upstream collaboration remains valuable: reporting bugs responsibly, contributing patches, coordinating disclosure and funding maintenance can improve everyone’s security posture. But collaboration does not transfer manufacturer obligations to the upstream project.

The same company may publish a non-monetised open-source library and separately sell a supported product built around it. Those offerings should be assessed separately rather than assigning one blanket CRA status to the company.

Reporting dates and triggers are not identical

The CRA’s general application date is 11 December 2027. Manufacturer Article 14 reporting obligations began earlier, on 11 September 2026. The Article 24(3) reporting provisions for open-source software stewards apply from 11 December 2027. [1][4]

For manufacturers who must already comply with the 24h/72h reporting timeline, we documented the full incident intake and escalation runbook in CRA Vulnerability Reporting: Build a 24h/72h Response Workflow . That process addresses actively exploited vulnerabilities contained in their products and severe incidents affecting product security.

For stewards, Article 24(3) is not an unrestricted copy of every manufacturer duty:

• Article 14(1) applies to actively exploited vulnerabilities to the extent the steward is involved in development of the relevant product.
• Article 14(3) and (8) apply to severe incidents to the extent they affect network and information systems the steward provides for development of the relevant products. [1]

A CVE match in an upstream dependency does not automatically prove active exploitation or create a reportable event. Equally, a serious compromise of steward-provided development infrastructure can require assessment even without a published CVE. Organisations should establish reporting ownership and verify current Single Reporting Platform procedures before an incident. [1][4][5]

Six scenarios that expose the boundaries

These examples are illustrative. Their outcomes depend on facts not captured in a short description.

Scenario A — Volunteer-maintained library. An individual publishes an unmonetised library and accepts occasional community contributions. Widespread commercial use alone does not turn that individual into the manufacturer of downstream products. Check whether any separate commercial supply exists.

Scenario B — Foundation-supported project. A foundation systematically funds maintainers, governs releases and operates build infrastructure for a FOSS project intended for commercial integration. This may satisfy the steward definition. Its legal status, sustained support, role in viability and development systems require examination.

Scenario C — Company-sponsored repository. A company pays for upstream improvements but does not control or commercially supply the library. Sponsorship alone does not establish manufacturer status for that library. Examine any distinct products the company supplies.

Scenario D — Commercial appliance. A vendor sells a network appliance incorporating Linux and multiple FOSS packages. The vendor should assess manufacturer obligations for its appliance and conduct component due diligence. It cannot assume volunteer maintainers are responsible for its conformity.

Scenario E — Open-core distribution. A company offers a free community edition and a monetised enterprise edition with commercial support. Assess the actual supply and monetisation arrangements for each offering; neither the shared codebase nor the licence alone resolves the manufacturer’s role.

Scenario F — SaaS provider using FOSS. A provider runs open-source components behind a hosted service. The CRA product boundary, including any relevant remote data processing solution, must be assessed before assuming the service is either wholly covered or wholly excluded. Pure SaaS is not automatically equivalent to a product placed on the market. [1][3]

A decision tree for your project

Use the following as a triage aid, not an automatic legal classification:

flowchart TD
    A["Identify the software, supplier and activity"] --> B{"In-scope product with digital elements commercially supplied on EU market?"}
    B -->|Yes| C{"Actor places product on market as manufacturer?"}
    C -->|Yes| M["Assess manufacturer obligations"]
    C -->|Unclear| L["Further legal and factual assessment"]
    B -->|No or unclear| D{"Legal person systematically supports FOSS intended for commercial use and ensures viability?"}
    D -->|Yes| S["Assess Article 24 steward obligations"]
    D -->|No| E["Assess non-commercial or contributor position"]
    D -->|Unclear| L
    B -->|Unclear| L
    M --> F["Document product scope, role and evidence"]
    S --> F
    E --> F

A robust assessment record identifies the legal entity, product and version, commercial supply model, development and governance responsibilities, integration relationships, relevant infrastructure, and the evidence supporting the classification. Revisit it when the business model or product changes.

What engineering teams should do now

For upstream maintainers and potential stewards, establish who owns security reports, how vulnerabilities are triaged, what development infrastructure the organisation provides, and whether a documented cybersecurity policy is required. Keep the process proportional to the project’s governance and resources.

For commercial manufacturers, identify the products actually supplied, inventory third-party dependencies, track upstream security information, assess vulnerabilities in product context, and preserve release and remediation evidence. An SBOM helps with visibility; it is neither a transfer of responsibility nor proof of CRA conformity.

For both, distinguish legal obligations from implementation choices. A security policy, a signed artifact, a VEX statement and an incident runbook can support defensible engineering practice, but none independently settles the CRA classification of an actor or product.

The question is not simply “Who wrote this code?” It is “Who supplies the product, who sustains the project, and which obligations attach to each activity?” Getting that boundary right is the starting point for effective open-source security under the CRA.

At ape factory, this distinction informs how we approach software supply-chain security, secure delivery pipelines and platform engineering: build traceable controls around the products an organisation actually operates and supplies, without pushing responsibility onto upstream volunteers.

Sources

1. Regulation (EU) 2024/2847 (Cyber Resilience Act) , especially Recitals 18–20 and Articles 3, 13, 14, 24, 64 and 71.
2. European Commission — Cyber Resilience Act: Open source .
3. European Commission — CRA implementation guidance , including the guidance annex and its FOSS examples.
4. European Commission — CRA reporting obligations .
5. ENISA — CRA Single Reporting Platform launch .