The EU Cyber Resilience Act and Open-Source Software: What Businesses Need to Understand

The EU Cyber Resilience Act (CRA) establishes mandatory lifecycle cybersecurity requirements for products with digital elements—including standalone software and connected hardware—placed on the European Union market. Open-source software is neither a blanket exemption nor a single regulatory bucket. Under the CRA, your obligations depend on the economic role your organisation plays: whether you develop community code outside commercial activity, act as an open-source software steward, monetise an open-source platform, or embed open-source libraries inside a commercial product.

The practical takeaway: Businesses do not need to wait until the full regime applies in December 2027 to take control. With vulnerability and incident reporting obligations already active from September 2026, the smart move is to build practical engineering and operational foundations now: maintain a clear software and component inventory, clarify your economic role for each product, define 24-hour and 72-hour vulnerability reporting workflows, establish clear security support periods, and assign accountable ownership across your software stack. The European Commission’s July 2026 implementation guidance provides specific clarity on commercial activity, substantial modifications, support periods, and free and open-source software.

Why this matters

For years, software security was treated largely as a contractual matter between vendors and buyers. If a product shipped with unpatched dependencies or opaque components, market pressure—not product-safety law—was the primary mechanism for accountability. The EU Cyber Resilience Act changes that baseline. It brings CE-marking principles and mandatory lifecycle security obligations to software and connected products sold or distributed commercially into the EU market.

Two dates anchor the operational timeline:

• 11 September 2026: Reporting obligations apply for actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
• 11 December 2027: The main essential cybersecurity requirements—covering secure-by-design development, vulnerability handling, technical documentation, support periods, and conformity assessment—take full effect.

Note: This article provides operational and strategic context only and does not constitute legal advice. Organisations should take qualified legal advice regarding their specific products, markets, and regulatory roles.

For CEOs, CTOs, and business owners, the core question is no longer simply ‘Do we use open-source software?’ Almost every modern business does. The real question is: ‘What software do we supply, customise, host, or rely upon; how is it monetised or delivered; and who is accountable for its security across its working life?’

How the CRA treats open-source software

One of the most common misunderstandings among leadership teams is the belief that ‘open source is exempt from the CRA.’ In reality, the regulation draws a deliberate boundary between non-commercial community development and commercial supply.

1. Non-commercial open-source contributors: Developers who write, patch, or share free and open-source software outside the course of commercial activity are not treated as manufacturers under the CRA. Contributing a bug fix to an upstream project or publishing an open library without monetising it does not, by itself, trigger manufacturer obligations.
2. Commercial manufacturers incorporating open source: When a business integrates open-source libraries, frameworks, or operating systems into a commercial software product or connected device placed on the EU market, that business is the manufacturer of the final product. You do not pass regulatory responsibility upstream to volunteer maintainers; you are responsible for ensuring the complete product—including its open-source dependencies—meets the CRA’s essential security and vulnerability-handling requirements.
3. Commercial monetisation of open-source products: If an organisation develops and supplies an open-source application in the course of commercial activity—for example, charging for the product, charging for essential technical support that goes beyond basic cost recovery, or tying the software to a paid commercial platform—it may fall within scope as a manufacturer.
4. Open-Source Software Stewards: The CRA introduces a distinct, lighter-touch category for legal entities (such as foundations or corporate sponsors) that systematically support the development of specific open-source products intended for commercial use without monetising them directly. Stewards are not subject to full CE-marking or product conformity assessments, but they must establish a cybersecurity policy, cooperate with market surveillance authorities, and report actively exploited vulnerabilities or severe incidents to the extent they are involved.
5. Pure SaaS vs downloadable or on-premise software: Remotely hosted Software-as-a-Service (SaaS) is generally outside the CRA’s product scope unless it forms an essential remote data-processing component of a regulated hardware or software product (such as a cloud backend required for a smart device or desktop agent to function). However, self-hosted software packages, downloadable agents, container images distributed to customers, and substantially modified distributions can fall squarely within scope.

What counts as a ‘substantial modification’?

A critical trap for technology consultancies, value-added resellers, and enterprises that fork open-source software is the concept of substantial modification. Under the CRA and the European Commission’s July 2026 guidance, anyone who modifies a product already placed on the market in a way that affects its compliance with essential cybersecurity requirements—or changes the intended purpose for which the product was assessed—can assume the legal obligations of the manufacturer for that modified product.

Routine security patches and minor configuration adjustments designed to maintain existing safety do not normally constitute a substantial modification. However, adding new network-facing modules, altering authentication models, embedding new third-party subsystems, or repackaging an open-source project under your own commercial brand and distributing it to customers can shift the compliance burden onto your shoulders. Knowing where custom configuration ends and product modification begins is essential for both engineering and commercial teams.

A practical approach

1. Identify your role and product scope

Start with a clear, honest map of what your organisation builds, distributes, hosts, and uses. Do not let engineering and legal teams work from different assumptions.

• Catalogue every software artefact: List customer-facing applications, downloadable agents, container images, plugins, firmware, and hosted platforms supplied to clients in the EU.
• Classify your role per artefact: Determine whether you act as a manufacturer, importer, distributor, open-source steward, pure-play SaaS operator, or internal deployer.
• Flag forks and custom distributions: Identify any open-source packages that your team modifies, rebrands, or bundles into client deliverables, and review whether those changes could be classed as substantial modifications.

2. Build component and ownership visibility

You cannot secure or report on components you do not know you have. Visibility across your dependency tree is the foundation of CRA readiness.

• Generate and maintain Software Bills of Materials (SBOMs): Integrate automated SBOM generation into your build and release pipelines so every shipped version has an accurate machine-readable record of its direct and transitive dependencies.
• Assign a named owner to every product and repository: Unowned software is unmanaged risk. Every internal platform, customer deliverable, and open-source fork should have an accountable technical and business owner.
• Assess upstream project health: For critical open-source dependencies, check whether the project has active maintainers, a documented security disclosure policy, regular releases, and a realistic path for patching or replacement if the project stalls.

3. Define vulnerability and reporting workflows

Because the CRA’s reporting rules apply from 11 September 2026, incident and vulnerability escalation cannot remain an informal chat-channel exercise. Under the CRA framework, manufacturers must notify both the designated CSIRT coordinator and ENISA via the single reporting platform within strict timelines when an actively exploited vulnerability or severe incident occurs:

• 24-hour early warning: An initial notification within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident affecting product security.
• 72-hour notification: A more detailed follow-up within 72 hours providing an assessment of the vulnerability or incident, its severity, impact, and any initial mitigating measures.
• Final report: A complete report within 14 days after a corrective measure is available (for vulnerabilities) or within one month (for severe incidents), alongside timely security advisories to affected users.

Run a tabletop exercise using a realistic scenario—such as a zero-day exploit disclosed in an open-source authentication or logging library embedded in your product—to verify that your team can identify affected versions, assess exploitability, and draft accurate notifications within 24 hours.

4. Plan support periods and lifecycle commitments

Under the CRA, manufacturers must define and clearly communicate a support period during which vulnerabilities will be handled and security updates provided—typically at least five years, or the expected lifetime of the product if shorter.

• Define version and end-of-life policies: Stop allowing customers to run indefinitely on unmaintained branches without clear lifecycle boundaries.
• Separate security updates from feature upgrades: Where feasible, ensure customers can apply critical security patches automatically or without being forced into disruptive functional migrations.
• Align open-source lifecycles with commercial promises: Do not sign a five-year customer support contract on top of an open-source framework version whose upstream community support expires in nine months, unless you have budgeted for long-term maintenance or timely migration.

Practitioner detail

To turn regulatory language into day-to-day engineering discipline without slowing down product delivery, integrate the following controls into your standard operating rhythm:

• Automated Software Composition Analysis (SCA) at build time: Block or flag builds that introduce dependencies with known exploitable vulnerabilities, unapproved licences, or abandoned upstream repositories.
• Release-to-deployment traceability: Maintain a clean link between source commit, build artefact, SBOM record, and customer deployment. When a CVE drops on a Friday afternoon, your team should be able to query which products and customer environments run the affected version in minutes rather than days.
• Coordinated Vulnerability Disclosure (CVD) policy: Publish a clear security disclosure channel so researchers, customers, and upstream projects have a direct, monitored path to report flaws to your team.
• Upstream contribution discipline: When your engineers fix a security or stability issue in an open-source dependency, contribute the patch upstream wherever possible. Maintaining private forks drifts quickly and multiplies your long-term maintenance cost.
• Evidence-ready documentation: Store risk assessments, architectural threat models, SBOMs, and vulnerability remediation logs alongside each product release so conformity evidence is generated automatically as part of normal work.

Common mistakes to avoid

• Assuming ‘open source’ means ‘out of scope’: The exemption protects non-commercial community development, not commercial products built from open-source parts. If you sell or commercially supply the software, you own the product security obligation.
• Treating self-hosted open source as ‘free of governance’: Even when you deploy open-source platforms purely internally—outside the CRA’s manufacturer rules—assuming the community handles your security is dangerous. You still own the risk of your hosting architecture, identity controls, patch cadence, backup testing, and data governance.
• Waiting until late 2027 to start: Building clean dependency inventories, refactoring legacy libraries that no longer receive upstream patches, and training teams on 24-hour reporting workflows takes months of steady operational work.
• Generating SBOMs that nobody reads: Creating static compliance files that sit in a folder without being connected to vulnerability alerting, exploitability triage, and release management adds paperwork without reducing risk.

Closing thought

The point of preparing for the EU Cyber Resilience Act is not to create a heavier bureaucracy, a longer policy manual, or fear around open-source software. Open-source platforms remain one of the strongest ways for modern businesses to avoid vendor lock-in, control costs, and innovate quickly. The goal is simply to pair that freedom with grown-up operational discipline—so the people responsible for your systems know what is inside them, who owns each layer, and how to respond calmly when a vulnerability emerges.

Need help establishing practical open-source lifecycle controls, component visibility, vulnerability workflows, and managed platform operations? Managed Company can help turn security and resilience requirements into a workable OSSaaS operating model. Explore Open Source SaaS support.