Open-source software under the CRA | who carries the duties

Does the Cyber Resilience Act cover our open-source software?

Free and open-source software is in scope of the Cyber Resilience Act only when it is placed on the market, and under the Commission's guidance the obligations usually fall on the maintainer who publishes the software and controls its releases and distribution. Article 3(48) defines free and open-source software by open sharing of source code under a license that allows free access, use, modification and redistribution, and the Commission's guidance (C(2026) 5252, section 3) adds that code shared only with paying customers or a limited group does not qualify. Most duties for in-scope products apply from 11 December 2027, so the question is not only whether the software is covered but also when your obligations start. The answer depends on how the software is charged for, distributed and used. Charging for the software itself, such as for precompiled binaries, places it on the market and makes the publisher a manufacturer (guidance section 3.2.1). The same applies where the software is used to monetize other products or services, or where its use requires processing personal data for purposes other than security, compatibility or interoperability (section 3.2.2). Paid support or consultancy around freely available software does not by itself place it on the market, but a paid enterprise edition under a commercial agreement does (section 3.2.3). Donations, third-party sponsorship and paid development work are generally not enough on their own (sections 3.2.4 and 3.2.5), though the donation position changes if access to updates is in practice conditioned on giving money.

Start with a written inventory: for each repository, release channel and commercial offering, record who publishes it, whether anyone pays for the software or its updates, and whether a free community version and a monetized version exist side by side. A legal person publishing both is a steward for the community version and a manufacturer of the monetized one (sections 3.2.1 and 3.3), so the two may carry different duties. Integrators that embed open-source components have their own due diligence duties under Article 13(5) and 13(6). An implementation partner can help collect this evidence and prepare the documentation, but only an independent assessor or notified body issues conformity outcomes. Confirm the current classification with qualified legal counsel and against the guidance text before you rely on it.

Who carries the obligations: maintainers, contributors and stewards

Under the Commission guidance, responsibility for free and open-source software sits with the maintainers who publish it and control its releases and distribution. A maintainer is the party that decides what goes into a published version, signs or tags releases and makes the software available to others. Where that party is a legal person and the software is placed on the market, the guidance treats it as a manufacturer, so the full set of manufacturer duties can apply once the software is in scope.

Publishing control: The obligation follows whoever decides what is released and how it is distributed, not whoever wrote the code.
Charging for the software: Selling precompiled binaries or a licensed build places the software on the market, which can make the publisher a manufacturer.
Monetized use: Using the software to sell other products or services, or requiring personal data processing for non-security purposes, can also place it on the market.
Paid support: Optional paid support or consultancy around freely available code does not by itself place it on the market, but a paid edition under a commercial agreement does.
Check first: Confirm which entity publishes each release artifact and whether any artifact is sold, licensed or gated behind payment or donations.

Which commercial models place open-source software on the market

The Commission guidance treats the commercial model around a free project as the deciding factor, not the license alone. Each card below covers one model, the guidance position on it, and the question to put to your own arrangement before deciding whether your open-source software is on the market.

Priced precompiled binaries

Charging a price for the software itself, including for precompiled binaries, places it on the market. The publisher then becomes a manufacturer for that software and carries the full set of obligations. Check whether anyone pays to obtain a built artifact, installer or container image, even if the source code remains freely available. If a fee is attached to the download, treat the project as placed on the market and plan for the manufacturer route.

Monetizing other products or services

Open-source software is also placed on the market when it is used to monetize other products or services, or when its use requires processing personal data for purposes other than security, compatibility or interoperability. Ask whether the software is a funnel for a paid product, a dependency of a billed service, or a component that generates revenue through data collection. An illustrative case would be a free client that only works with a paid cloud account, which needs review against this test.

Optional paid support and consultancy

Offering optional paid support or consultancy around freely available open-source software does not, by itself, place it on the market. The test is whether the support is optional and separate from access to the code and its releases. Confirm that the software can be used and updated without buying a contract, and that support is sold as a service rather than as a condition for receiving security fixes.

Paid enterprise editions

A paid edition or enterprise version under a commercial agreement places the software on the market, even when a free community version exists alongside it. The publisher is a steward for the community version and a manufacturer for the commercial edition. Check which features, updates or security fixes sit only in the paid build, and confirm that each edition is documented and supported separately.

Donations and sponsorship

Donations made without intent to make a profit are unlikely to place open-source software on the market, unless access to the software, essential features or updates is in practice conditioned on donating. Third-party funding, sponsorship and paid development work do not by themselves place it on the market, and not-for-profit organizations that use all earnings after costs for not-for-profit objectives are in the same position. Check whether a donor tier unlocks anything that free users cannot obtain.

Paid development under a sponsor agreement

Paid development work commissioned by a company does not, by itself, place the project on the market. The question is who controls releases and distribution. If a sponsor takes over release decisions, or the sponsor's private fork is the only version users receive, the analysis changes. Review the contract for clauses on release control, exclusive features and distribution rights before accepting funding.

How open-core companies split between steward and manufacturer duties

An open-core company that publishes a free community version and a monetized version of the same software holds two roles at once. Under the Commission's guidance, the legal person is a steward for the community version and a manufacturer for the monetized version. The split is set by what is placed on the market, not by the company's business model as a whole, so the first task is to list every release channel, edition and commercial agreement and assign each one to a role. A paid enterprise build sold under a commercial agreement sits on the manufacturer side, while the public repository that anyone can clone sits on the steward side.

The split changes how release work is organized. The monetized edition carries the full manufacturer load: an Annex I risk assessment, technical documentation, a conformity assessment route, an EU declaration of conformity, CE marking and the Article 14 duty to report actively exploited vulnerabilities, with the support period defined for that product. Teams should confirm whether the two editions share code, build pipelines and vulnerability triage, and if they do, decide which evidence set each release produces. Where the enterprise edition ships a community component under a different version, document which version it came from so the manufacturer file and the steward policy point to the same source.

The steward regime is lighter. Under Article 24, stewards must keep a documented cybersecurity policy, cooperate with market surveillance authorities and report actively exploited vulnerabilities and certain severe incidents. The Commission states these obligations apply from 11 December 2027, and Article 64(10)(b) excludes fines for stewards. Ask counsel to confirm in writing which edition each release belongs to, and track the 11 December 2027 date against the manufacturer obligations, which already apply to the commercial edition on their own timetable.

What manufacturers that integrate open-source components must do

A manufacturer that builds its product on open-source components keeps the full set of CRA obligations for that product, even though the components are maintained by others. The cards below cover the integrator's due diligence, the vulnerability reporting and fix sharing duties, and the attestation option that can support them.

Due diligence on each component

Article 13(5) requires the manufacturer to exercise due diligence when integrating a component that is not its own, so the product does not become less secure. In practice this means knowing which open-source components ship in the product, which version each one is, and whether the component is actively maintained. Check the maintainer's security practices and release history before adoption, and record the outcome in the risk assessment for the product.

Reporting component vulnerabilities upstream

Under Article 13(6), when a manufacturer finds a vulnerability in an open-source component, it must report it to the person or organization maintaining that component. The duty applies to the integrator's discovery, not only to vulnerabilities the maintainer already knows about. Set up a route for these reports, such as the maintainer's security contact or disclosure process, and keep a record of each report and its date.

Sharing fixes developed for components

If the manufacturer develops a fix for a vulnerability in an open-source component, Article 13(6) requires it to share that fix with the maintainer. Integrators often patch locally to ship a product quickly, so this duty can be missed. Decide who in engineering owns upstream contributions, and make sure local patches for components are tracked so they can be offered back.

Keeping component records current

The integrator must know what its product contains to meet the due diligence, reporting and fix sharing duties. A software bill of materials (SBOM) for each product version is the usual record, and it should list direct and transitive open-source components with their versions. Confirm with your own tooling that the SBOM is regenerated on each release, because a stale inventory makes it impossible to tell whether a newly disclosed flaw affects the product.

Attestation programs under Article 25

Article 25 empowers the Commission to set up voluntary security attestation programs for free and open-source software by delegated act. Such a program would let developers, users or third parties assess a component against some or all of the essential requirements, which can support an integrator's due diligence. No such program is in place as this page is written, so confirm the current status with the Commission before relying on one.

Responsibility stays with the integrator

The duties in Article 13 sit with the manufacturer that places the integrated product on the market, for that product. The maintainer of a component does not take them over by publishing the component, and the integrator cannot pass them to the maintainer by contract alone. Document who in the organization owns each duty for each product, so that a contributor or outside maintainer is never assumed to be carrying a manufacturer obligation.

Can free open-source products use self-assessment in important categories?

Yes, but only under a specific condition. Article 32(5) of the Cyber Resilience Act lets a free and open-source product that falls in an Annex III important category (class I or class II) use module A self-assessment instead of a notified body, provided its technical documentation is made public when the product is placed on the market. The condition is the whole point of the provision. A product that qualifies for the route but keeps its technical file private does not get the benefit, and the publisher must treat publication as a release deliverable, not an afterthought. Before relying on this route, confirm the product's category against Commission Implementing Regulation (EU) 2025/2392, which gives the technical description of each Annex III category. A product that is only loosely related to a listed category may still be classed as important, or may not be classed that way at all, so the category check comes first.

Publishing the technical documentation means making available to the public the file that the manufacturer would otherwise keep for market surveillance authorities. For a maintainer, that usually covers the cybersecurity risk assessment, the list of essential requirements applied, the vulnerability handling process, the software bill of materials, and the test results that support conformity. Practical questions to settle include where the documents live, how they are versioned against each release, whether they are licensed for reuse, and how a reader can tell which version applies to a given binary or package. Confirm with the standard-setting work and your own legal advice which parts must be published in full and which may be summarized, because the regulation sets the duty but the detail depends on the final guidance and harmonized standards.

The difference from a notified body route is who checks the file and when. Under module A, the maintainer assesses conformity alone, drafts the EU declaration of conformity and applies CE marking, while the public documentation lets integrators, users and authorities review the evidence. A notified body route, required for class II and critical products and for class I products where harmonized standards are not fully applied, adds an independent body that examines the technical documentation or the quality system before the product is placed on the market. Self-assessment does not remove the duty to be accurate. An independent auditor or notified body is not required for this route, but a maintainer that wants third-party confidence can still commission an assessment of the public file from a qualified outside reviewer, and the cost of that choice should be budgeted and quoted in writing.

How to check your open-source scope before December 2027

This sequence turns a loose question about open-source use into a documented scope decision for each product and release channel. It ends with a role assignment per product and a plan for the steward or manufacturer duties that follow from it.

Map every repository and release channel
Engineering and product owners list every public repository, package registry, container image, installer and download page that carries code your organization publishes or maintains. Include forks you distribute and components bundled into commercial products. The output is a single inventory with one row per artifact and an accountable owner for each row. You know this step is done when the inventory reconciles with what your release pipelines actually publish, and when no channel is left unassigned.
Record licence and distribution model
For each inventory row, legal or compliance staff record the licence under which the code is shared and whether the code is open to anyone or only to a limited group, customers or paying parties. Note whether binaries are free, sold, bundled, or made available only after registration. The Commission's guidance treats code shared only with paying customers or a limited group as outside the open-source definition, so this distinction matters. The output is a licence and distribution record per row. It is complete when every row states who can access the source and on what terms.
Record every commercial arrangement
Finance, sales and partnerships teams list every arrangement that touches the software: paid binaries, paid editions, enterprise licences, support contracts, consultancy, sponsorships, donation campaigns, and any product or service that uses the software to generate revenue. Include funding from third parties and paid development work. Record whether access, essential features or updates depend on a payment or donation. The output is a commercial register linked to the inventory rows it affects. Confirm each entry with the contract or payment record, not with memory.
Assign the role for each product
Using the licence, distribution and commercial records, the compliance lead decides, for each product and release channel, whether your legal entity is a steward, a manufacturer, or neither. A free community version published by a legal person is treated differently from a monetized version of the same software, and a natural person's free version is out of scope. Contributors who submit changes without control over releases are not subject to the regulation. The output is a role assignment per product with the controlling legal entity named. Legal review should sign off each assignment before it is relied on.
Document the reasoning for each decision
For every role assignment, the team writes a short decision record that cites the licence, the distribution facts, the commercial arrangement and the Commission guidance section relied on. Record open questions separately, with an owner and a date for resolution. Store the records where auditors and market surveillance authorities could ask to see them. The output is a dated decision file per product. It is complete when a reviewer who did not take part can follow each conclusion from the evidence to the role.
Plan steward or manufacturer duties
For products assigned to the steward role, the team plans the documented cybersecurity policy, cooperation with authorities, and the reporting of actively exploited vulnerabilities and severe incidents that Article 24 describes, noting that the Commission states these apply from 11 December 2027. For products assigned to the manufacturer role, the team starts the risk assessment, Annex I work and vulnerability handling plan. For any product that integrates third-party open-source components, it plans component due diligence and vulnerability reporting to maintainers. The output is a duty plan per product with named owners. It is complete when each duty maps to a responsible team and to the decision record that triggers it.
Review scope when commercial terms change
Scope is not fixed. Business model changes, new paid editions, new donation drives, or a change in who controls releases can move a product from one role to another. Assign an owner to review the inventory, commercial register and decision records whenever a product launch, pricing change or governance change occurs. The output is a dated review log that shows when each decision was last confirmed. Confirm with your own legal counsel how often this review should run for your portfolio, since the guidance does not set a fixed cycle.

Which role applies to each open-source business model

This table compares common open-source business models against the likely CRA role under the Commission's guidance, the duties that follow, and the points to confirm with counsel or an assessor. Read each row as a starting position: the role depends on who publishes the software, who controls releases, and whether a commercial agreement or paid edition exists. The main takeaway is that charging for the software itself or selling a commercial edition usually creates manufacturer duties, while support, donations and third-party funding alone usually do not.

Business model	Likely role under the guidance	Main duties and what to confirm
Community project under a not-for-profit	Steward for the community version if the publisher is a legal person; not placed on the market where all earnings go to not-for-profit objectives	Steward duties in Article 24 apply from 11 December 2027. Confirm that all earnings after costs stay within not-for-profit objectives and that no paid edition exists.
Maintainer publishing precompiled binaries	Manufacturer, because charging for the software itself places it on the market	Full manufacturer obligations including Annex I requirements, vulnerability handling and Article 14 reporting. Confirm whether free binaries and paid binaries are treated differently with counsel.
Paid support only	Generally not placed on the market by the support contract alone, where the software stays freely available	Confirm that the software is not sold, bundled or made available only through a commercial agreement, and that no paid edition is offered.
Enterprise edition under commercial agreement	Manufacturer for the enterprise edition; the community version may still be a steward or out of scope depending on the publisher	Full manufacturer duties for the commercial product. Confirm which code, features and updates sit in each edition and whether the boundary holds.
Open-core with community and paid versions	Steward for the community version and manufacturer for the monetized version when a legal person publishes both	Steward duties for the community version and manufacturer duties for the paid version. Confirm feature boundaries and whether essential features or updates depend on payment.
Donation-funded project	Generally not placed on the market where donations are not intended to produce profit	Confirm that access to the software, essential features and updates is not in practice conditioned on donating. Third-party sponsorship alone does not change the role.

Who does what: your team, an implementation partner and the assessor

Your organization keeps the legal role under the regulation and every decision that makes it the manufacturer, steward or other operator of a product. Under the Commission's guidance on free and open-source software, that role follows from who publishes the software, controls releases and distribution, or charges for it. Those facts are yours to establish, and no partner can establish them for you.

Legal role determination: Decide whether you are a steward, a manufacturer, or out of scope for each product, based on how you publish, monetize and distribute it.
Product and risk decisions: Own the cybersecurity risk assessment, the essential requirements you apply, and any justification for requirements you treat as not applicable.
Declarations and marking: Sign the EU declaration of conformity and affix CE marking where the role requires it.
Support period and disclosure policy: Set the support period and the public vulnerability handling commitments that users will rely on.
Reporting decisions: Decide what is actively exploited or a severe incident, and make the Article 14 notifications through the single reporting platform.

Confirm these decisions in writing with legal counsel before you ask a partner to build evidence around them.

Mistakes that put open-source projects in scope by accident

Most open-source projects fall outside the Cyber Resilience Act, but a few commercial decisions can pull them in without anyone deciding to. The mistakes below share one pattern: a project that is free in principle becomes placed on the market through a release, a channel, a partnership or a license choice. Check each one before shipping, because the Commission's guidance treats the publisher's conduct, not the project's label, as the trigger.

Paid binary on a release page

Charging for precompiled binaries, even when the source code stays free, places the software on the market and makes the publisher a manufacturer. A release page that sells a convenience build, installer or signed package is the most common way a free project crosses that line. Check every paid download link and storefront listing and confirm which artifacts carry a price tag before the next release.

Sponsor-gated update channel

If access to security fixes, essential features or updates depends on a donation or sponsorship tier, the Commission's guidance treats the donation as conditional and the project as placed on the market. This often happens quietly, through a private package repository or a sponsors-only branch that carries patches first. Make sure security updates reach every user on the same terms as the public release, or document why no condition applies.

Commercial partner bundling the project

A vendor that packages the project into a paid appliance, hosted service or product line can place it on the market, even when the upstream maintainers never sold anything. Use of FOSS to monetize other products or services is itself a placement trigger. Ask partners to disclose bundling and resale terms in writing, and review any commercial reuse of the project before it appears in their catalog.

License that blocks redistribution

The regulation's definition of free and open-source software depends on rights to access, use, modify and redistribute the code. A license that restricts redistribution, or limits sharing to a defined group of customers, may fall outside that definition, which changes the analysis for the whole project. Read the license against the four freedoms and confirm that no clause limits redistribution before relying on the open-source exclusion.

Company contributor assuming maintainer duties

Employees who submit pull requests or hold commit access without control over releases and distribution are not subject to the regulation. Problems arise when a company contributor begins cutting release tags, publishing packages or answering vulnerability reports on the project's behalf, which takes on the maintainer role. Record who controls release and distribution and keep those permissions with the project's maintainers.

Paid edition beside a free version

Publishing a free community version and a monetized version of the same software creates two roles at once: a steward for the community version and a manufacturer for the paid one. Teams often assume the free edition shares the paid edition's status, or the reverse. Map each edition, package and repository to its role and document which obligations attach to which edition.

Questions open-source teams ask about the CRA

Does a free community edition of our open-source project need a CE mark?

It depends on who publishes the software and how it reaches users, and the answer changes if money is involved. Under the Commission's guidance, a legal person that publishes a free community version is a steward for that version, while a free version published by a natural person is out of scope. Charging for the software itself, including precompiled binaries, places it on the market and makes the publisher a manufacturer. Manufacturers carry conformity assessment and CE marking duties. If you publish both a free community edition and a monetized version, treat each artifact separately and record the role you hold for each. Check your reasoning against section 3 of the Commission guidance, and have counsel confirm any conclusion that affects your business model.

Do contributors to an open-source project carry CRA duties?

Generally no. The guidance places responsibility on the maintainers who publish the software and control its releases and distribution. Contributors who submit pull requests or hold commit access without that control are not subject to the regulation. For projects with many committers, the practical task is to identify the people who can cut a release, sign artifacts or push to distribution channels, because those are the people who carry the publishing role. Write down who holds release authority and how that authority is granted and revoked. That record is the evidence you will need to show your role. A company that employs contributors still has to decide which legal entity publishes each release, since that entity holds the duties.

What drives the cost of an open-source steward compliance programme?

The main cost driver is the governance of the project, not the size of the codebase. Steward duties under Article 24 include a documented cybersecurity policy, cooperation with authorities, and reporting of actively exploited vulnerabilities and certain severe incidents. One-time costs include drafting the policy, designing the intake and reporting workflow, and defining who decides what. Recurring costs include reviewing reports, keeping the policy current, and maintaining dependency tracking. Costs rise with the number of maintainers who hold release authority, the number of distribution channels, and any commercial edition that moves the entity toward manufacturer duties. Ask any quote for named deliverables, who performs each task, what recurs, and what is excluded. DeployOpen does not publish a price list, and a quote follows from the written scope.

Does paid support for an open-source project bring it into scope?

Not by itself. Under the guidance, optional paid support or consultancy around freely available software does not place it on the market. A paid edition or enterprise version delivered under a commercial agreement does. Other triggers include charging for the software itself, using the software to monetize other products or services, and requiring personal data processing for purposes other than security, compatibility or interoperability. Donations made without intent to profit are unlikely to trigger the regulation, unless access to the software, essential features or updates is in practice conditioned on donating. Third-party sponsorship and paid development work do not trigger it on their own. Map each revenue stream against these tests in writing and keep the record with your classification file.

When do open-source steward obligations start to apply?

Steward obligations apply from 11 December 2027, which is the general date of application set by Article 71(2). Article 64(10)(b) excludes stewards from fines. Two other dates matter if your project feeds a commercial product. The Article 14 reporting obligations apply from 11 September 2026, and under Article 69(3) they apply to in-scope products whenever they were placed on the market. Article 14 is a manufacturer duty, so a manufacturer that ships a product built on your project is already under that reporting clock. Plan your steward programme to be in place by the 2027 date, and confirm with your downstream manufacturers which reporting duties they expect you to support.

Can our team run CRA readiness for open-source work ourselves?

Yes for many steps, provided the team has time and clear ownership. Internal engineers can usually own the scope classification, the vulnerability intake process, the SBOM and the release records. Independent evidence is harder to produce alone. Products in class I, class II or the critical categories may need a notified body, and only independent auditors, assessors or certification bodies issue reports or certificates. An implementation partner can prepare systems, controls and evidence, including hardening, documentation and testing, under a fixed written scope. Decide which tasks stay in-house, which need outside help, and who signs off the risk assessment before work starts.

What should we ask a partner before hiring one for CRA work?

Start with roles. Ask who issues any report or certificate, and confirm that the partner prepares systems and evidence while an independent assessor makes the determination. Then ask for:

A written scope listing deliverables, exclusions, and who performs each task.
Examples of work on self-hosted open-source platforms, described without client names unless the client agrees.
How the risk assessment is documented, and how requirements judged not applicable are justified.
What happens after delivery, including support, upgrades and retainers, and which costs are one-time and which recur.
Where the work runs and what access the partner needs inside your infrastructure.

Request a quote that follows from that written scope and compare proposals on the same deliverables.

How DeployOpen prepares open-source compliance evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Cyber Resilience Act work, we help you establish which open-source software you publish, distribute or monetize, and prepare the systems and evidence that show how that role is handled. Assessment and certification decisions remain with independent bodies.

How we scope

We confirm which open-source projects you publish, who controls releases, and whether any edition is monetized.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Scope documents the role per project: steward, manufacturer, or out of scope, with reasons for each.

How we build

We set up release, signing and distribution controls for the projects you maintain and publish.
We build component inventories and SBOM generation into your build pipeline for shipped software.
We run security testing on published code and deployed platforms, and record the findings and fixes.

How we hand over

You receive technical documentation, the cybersecurity policy and the vulnerability handling records for your scope.
Evidence is organized per project so your legal and compliance teams can review the role decisions.
Your organization keeps ownership of its controls, and any declaration or certification is issued by you or an independent body.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover updated inventories, new releases and reviews when a project's monetization model changes.
We confirm current dates and obligations with the official sources and your legal advisers before each milestone.