Cyber Resilience Act and Open Source: turning a regulatory obligation into strategic leverage

1 December 2025

In a nutshell, the Cyber Resilience Act (CRA) combines three success factors that turn this regulatory obligation into strategic leverage:
1️⃣ Standardisation: the CRA harmonises cybersecurity in the EU (2026-2027) and clarifies responsibilities along the entire software chain.
2️⃣ Protection of community Open Source: non-commercial community projects are excluded from these obligations, fostering innovation and the role of Open Source Stewards.
3️⃣ Transformation through compliance: SBOMs, vulnerability management and process integration become levers of resilience and trust within the digital ecosystem.

Since the publication of the Cyber Resilience Act (CRA) at the end of 2024, digital actors have a clear horizon regarding the cybersecurity requirements applicable to the digital products they place on the market in the European Union (end of 2026 for some, end of 2027 for all others). Last year we published a guide dedicated to the CRA in the context of Open Source practice.

Across three recent interventions -- a Numeum internal webinar, an inno³ & SMILE webinar, and a panel with Stéfane Fermigier (CNLL) at Red Hat Summit -- a positive message has been shared about these new directives. The CRA harmonises practices and reformulates responsibilities around software chains, while opening new perspectives to structure innovation around open models. This regulation should therefore not be seen as another constraint but, on the contrary, as an accelerated and smoother standardisation driven by a legislator aware of the need to support the transition.

These good practices lead to implementing a compliance approach (which is not yet a culture universally shared) within each organisation, but also to anticipating and equipping the human and organisational processes needed to operate such management through dedicated policies. This compliance rests on two pillars: implementing dedicated processes within the organisation, and being able to trace and demonstrate what has been done. Defining a cybersecurity policy aligned with CRA obligations inevitably leads to drawing closer to -- or designing -- an internal Open Source policy: both rely on an exhaustive knowledge of the components (Open Source or otherwise) used, on the definition of processes adapted to the typologies of products marketed and their operating models, and on processes overseen by a dedicated body (often called an OSPO, for Open Source Program Office).

A few of these points are developed below.

An asserted and confirmed power to regulate the internal market

The CRA embodies an approach to internal market regulation in line with Regulation 2019/1020 on market surveillance and product compliance (which complements the New Legislative Framework of 2008).

It places cybersecurity at centre stage, in continuity with general regulations such as NIS (2016), the Cybersecurity Act (2019), NIS 2 (2022), and with sector-specific regulations applicable to financial services (such as the Digital Operational Resilience Act -- DORA, applicable from 2025), payments and medical or radio equipment, etc.

To these are added cross-cutting texts with pronounced sectoral effects, such as the Artificial Intelligence Act (AI Act) of 2024, which sets requirements for high-risk systems, or the CER Directive (2022) strengthening the resilience of critical entities in sensitive sectors. Together, they impose a number of good practices, the failure to comply with which may serve as a basis for compensation under the 2025 New Product Liability Directive (NPLD) (in French).

This apparent complexity, which reflects the complexity of our digital society, is not necessarily synonymous with unnecessary heaviness:

On the one hand, a certain harmonisation can be observed across these complementary texts. The omnibus package presented by the European Commission on Wednesday 19 November 2025 -- which only partially and incidentally covers these aspects -- reflects this trend towards harmonisation and simplification.
On the other hand, these various frameworks simplify by harmonising heterogeneous practices. Lastly, digital tools are also an ally to understand and reduce this complexity, enabling the creation of tools that share processing and automate it.

The Hermine-FOSS project, although initially designed to address the complexity of the Open Source legal ecosystem, is a good example of a tool that makes it possible to aggregate exhaustive knowledge of all third-party components used (by version, by product, by product category), to automate licence (contract) processing, and to automatically implement a number of policies within the organisation.

For a deeper dive on this topic, and to develop in particular the perspectives associated with a harmonised management of cyber × Open Source × sustainability compliance risks, see the panel “Cybersecurity and Open Source compliance: towards a unified, tooled approach around SBOMs” organised at OSXP 2025.

Regulatory evolution that clarifies responsibilities along the software chain

The CRA standardises a number of good practices that become mandatory for any economic actor operating on the European market:

the establishment of complete technical documentation, including a complete software bill of materials (SBOM, in a format such as SPDX or CycloneDX);
continuous management of vulnerabilities for at least five years;
a cybersecurity policy aligned with DevSecOps practices.

These obligations respond to a shared finding: today’s software chains are complex, largely cross-cutting and often insufficiently documented. Recent incidents (Log4Shell, XZ, NPM compromises) have brought to light critical dependencies which, for lack of support, weaken the entire ecosystem.

The diagram below helps identify the organisation’s products that are potentially in scope of the CRA (with more or less significant obligations depending on the product categories concerned):

[Image to be added -- see French source]

The CRA includes a list of specifically responsible persons (it being understood that the rest of the responsibilities will follow the usual contractual play):

[Image to be added -- see French source]

In the longer term, a collective grasp of these issues, supported by precise knowledge of components and supply chain actors, may make it possible to aim for genuine organisational resilience. This can be achieved through information that is shared and collectively monitored. It is on this axis -- combining a community and an industrial approach -- that we are currently working jointly, inno³ and Examin, to propose automatable arrangements for measuring and steering resilience (drawing both on the first indicators published in France and across Europe). This harmonisation and objectivisation of security measures will further enable the development of reliable and representative indices, allowing actors to choose the solution best suited to their security needs.

An Open Source exception designed to preserve the capacity to innovate

The CRA upholds a strong principle: community Open Source projects, where they are not the subject of a directly linked commercial activity, remain outside its scope. This carve-out is intended to preserve the dynamic of digital commons and the innovation that characterises these open ecosystems. It is also, in a sense, recognition of a limit to market-based regulation when faced with practices that exceed it and which, under certain conditions, can sometimes compensate for market failures (and therefore do not require the same regulation).

This distinction opens the way to hybrid models:

community distribution: through a dedicated structure or within an organised collective;
commercial offerings that are supported, documented and maintained -- which helps clear up some grey areas between community offerings and the commercial offerings of certain vendors;
structuring of trusted open ecosystems. The CRA recognises a new and structuring role of Open Source Steward, presented as a trusted partner of regulators.

These approaches are aligned with inno³’s work on governance, Open Source compliance and distribution strategies. They question and refine certain typologies of actors, some of which are more strongly disrupted, such as research centres (in French).

From compliance to organisational transformation

CRA compliance goes well beyond the legal reading. Organisations have to rethink themselves, both in their internal organisation and in their external relationships.

Internally, this means:

formalising a cybersecurity policy in line with the CRA and articulated as far as possible (in terms of tooling and processes) with the existing Open Source policy;
integrating SBOM automation into CI/CD pipelines;
raising internal awareness and clarifying roles and responsibilities (Open Source coordinator, CISO, lawyers, product teams);
extending analysis to transitive dependencies.

Externally, the focus will be on how to:

contractualise the supply of SBOMs and the remediation of vulnerabilities;
strengthen relationships with upstream projects (the original Open Source projects), in order in particular to be informed of potential security flaws and, conversely, to be able to inform the project of such flaws and to share the necessary patches;
ensure coordination of patches and security information.

Towards an open, interoperable and tooled compliance chain

These reflections highlight a common need: to have a unified, open and interoperable compliance chain, linking transparency, vulnerability management, regulatory requirements and contribution to the Open Source commons.

This is precisely the ambition of the ConCyOS consortium (Open Source Compliance and Cyber) launched in 2025 and bringing together Thales, inno³, Examin and INRIA, to equip the production and circulation of SBOMs, improve interoperability among actors, strengthen trust in Open Source components (on cyber, OS licence compliance, and maintainer maturity issues), and integrate compliance frameworks into industrial practice.

Conclusion

The entry into force of the CRA accelerates the transformation of industrial practice. Far from being a mere constraint, this evolution opens an opportunity: defining and adopting standards that put sustainability, security and compliance at the heart of digital projects.

The collective challenge remains to develop open tools, to strengthen cooperation within and with communities, and ultimately to consolidate trust frameworks that allow Open Source to remain a driver of innovation, resilience and sovereignty. These various axes are an integral part of our research strategy at inno³, and will be developed over the next three years. In this spirit of openness and contribution to the ecosystem, we will share in the coming months the reflections carried out with our partner Examin in order to develop them through an open and community-driven approach.