Moving Forward with Clear Technical Definitions Under the CRA

The European Commission has just published the Implementing Regulation defining the technical description of “important” and “critical” products with digital elements under the Cyber Resilience Act (CRA).
You can find the full text here: Regulation (EU) 2025/2392 – Technical Description of Important and Critical Products.

This is a significant moment in the CRA journey. For the first time, manufacturers, integrators, and open source communities have a clear, legally binding definition of which technologies fall into the higher-risk categories. For anyone building or maintaining software used across Europe, this clarity matters.

From the perspective of the Open Regulatory Compliance (ORC) Working Group, this regulation is especially important for one reason: it finally gives open source stewards and maintainers the information they need to understand where their work fits within the CRA framework.

Why this matters for open source

Many of the technologies listed as “important” are widely built, maintained, or influenced by open source communities: browsers, operating systems, VPN clients, identity systems, network tools, package managers, secure-element firmware… the list is long.

Until now, projects had to guess whether they would be treated as “important” under the CRA, and uncertainty is never a good foundation for long-term planning.

This new regulation does two things:

1. It removes ambiguity.
   Projects now know whether their core functionality matches a regulated category. This helps maintainers and foundations anticipate documentation needs, security-process expectations, and integration paths for manufacturers who rely on their work.

2. It reinforces the need for structured governance in these cases.
   As CRA obligations become clearer, open source projects will increasingly depend on strong governance, documented processes, and reliable vulnerability-handling mechanisms. This is exactly why ORC exists: to help communities and ecosystems prepare without overwhelming individual contributors.

The Practical Impact for FOSS Projects

With the technical descriptions officially published:

• Open source projects can start aligning documentation, security policies, SBOM workflows, and governance practices with the CRA reality.

• Foundations and stewards gain a clearer mandate to provide structured processes that manufacturers can trust.

• Manufacturers now have an easier path to determine when and how they can rely on open source components in regulated contexts.

Open source will play a central role in CRA compliance, but only if communities can demonstrate predictable, transparent, and trustworthy security practices. Regulation (EU) 2025/2392 gives us a shared starting point.

ORC’s role moving forward

At ORC, we’ve spent the last year working to ensure that open source perspectives are reflected in CRA implementation. This new regulation includes elements that our community actively contributed to, a small but meaningful sign that the European Commission understands the importance of open source in Europe’s digital infrastructure.

Now the real work begins:

• refining our guidance, including the due diligence processes for manufacturers integrating open source technologies,

• expanding community-driven best practices,

• maturing the attestation model under Article 25,

• and supporting maintainers and stewards as they navigate the new landscape.

The publication of these technical descriptions is not the end of the discussion; it’s the beginning of coordinated, practical implementation. Open source is part of Europe’s backbone, and the CRA gives us an opportunity to reinforce that role with clarity, structure, and shared responsibility.

If you care about the future of open source in Europe, this is the moment to get involved. The ORC Working Group is already deep into the practical work. Be part of our regular discussions and join our events, like Code and Compliance FOSDEM Edition.