The Cyber Resilience Act (CRA) is a major new piece of EU legislation that aims to bring security-by-design into how digital products are developed and brought to market across Europe. Adopted at the end of 2024 and applying from late 2027 (with some requirements coming into effect towards the end of this year), the CRA introduces baseline cybersecurity requirements for any product with digital elements placed on the EU market. This ranges from connected consumer devices to infrastructure software and secure communications systems.
The regulation aims to address long-standing security failures driven by misaligned incentives. Until now, software and hardware producers have often faced limited consequences for shipping flawed products, particularly in complex supply chains. The CRA seeks to change this by embedding security obligations directly into the lifecycle of digital products, shifting responsibility towards those who place them on the market. For open source projects and the organisations that steward and commercialise them, this represents a significant shift; while the CRA promises improved security and clearer accountability, it also raises important questions about scope, responsibility, and sustainability.
These challenges were explored in detail by Denise R. S. Almeida, Head of Policy & Compliance at Element and Data Protection Officer for the Matrix.org Foundation, in a presentation delivered at the Matrix Conference 2025. Drawing on Element’s experience developing and stewarding Matrix-based products, Denise highlighted how the CRA applies to open source software in practice and shared how organisations can begin preparing during the current implementation phase.
Watch the presentation about CRA from the Matrix Conference 2025
The CRA is a regulation, meaning it applies uniformly across all EU member states. Unlike other frameworks such as the GDPR, which are primarily assessed at an organisational level, the CRA operates at a product-by-product level. This reflects a deliberate shift in regulatory thinking; risk is no longer determined by company size, but by the nature of the product itself - particularly its ability to connect to networks, process data remotely, or form part of a wider digital supply chain.
The regulation was originally motivated by security concerns in areas such as the Internet of Things, but its scope is intentionally broad. Any product with digital components placed on the EU market must now be designed and developed with security in mind from the outset - supported by documentation, incident reporting processes and ongoing vulnerability handling.
One of the most significant and complex aspects of the CRA for open source communities is how it treats commercialisation.
In principle, non-commercial open source software is out of scope. However, many open source projects are published under permissive licences that explicitly allow commercial use. This has led to understandable concern about where responsibility lies if open source code is later incorporated into a commercial product.
Under the CRA, obligations attach to the entity that first places a product on the market with commercial intent. Publishing open source code alone does not trigger manufacturer responsibilities. If a third party forks a project and commercialises it, responsibility for CRA compliance rests with that party - not with the original developer or maintainer. This distinction is critical in ensuring that individual contributors and hobby projects are not inadvertently burdened by regulatory obligations.
The CRA introduces a clearer delineation of roles within the digital supply chain, including manufacturers, importers, distributors and open source stewards. Importantly, the role of an open source steward can only be held by a legal person, such as a company or foundation. Natural persons - individual developers - cannot be stewards under the regulation, a safeguard designed to protect volunteers and independent contributors.
Because the CRA applies at a product level, a single organisation may hold multiple roles across different products. This is particularly relevant for organisations like Element, which develops both commercial offerings and community-facing open source projects within the Matrix ecosystem.
For products first placed on the market by Element and offered commercially, such as Element Server Suite Pro, Element assumes the role of original manufacturer. This brings with it full responsibility for CRA compliance, including security requirements, incident handling and conformity assessments. These products will also carry a CE mark, which can be self-certified and signals compliance with the regulation.
By contrast, for community projects made available without commercial intent, Element acts as an open source steward rather than a manufacturer. While strong security practices remain essential, these projects do not require CE marking or the full set of manufacturer obligations. This distinction helps preserve openness while maintaining clarity around accountability.
For manufacturers, the CRA introduces a number of concrete obligations. Products must be supported by appropriate cybersecurity measures, technical documentation and clear information for users. Manufacturers are also responsible for collecting and reporting security incidents and vulnerabilities to relevant EU authorities.
For organisations that already invest in security frameworks and structured vulnerability handling, these requirements will often build on existing practices. However, the CRA formalises these expectations and introduces additional coordination across engineering, security, legal and communications teams. Compliance is not a one-off exercise, but an ongoing responsibility throughout a product’s lifecycle.
The CRA may also have an indirect but important effect on long-standing challenges within open source ecosystems, including freeriding. Organisations that currently package open source software into commercial products without taking responsibility for security may now be required to develop their own compliance processes from scratch.
By contrast, products backed by a clearly identified original manufacturer and a valid CE mark may become more attractive and trustworthy. While licensing remains a key mechanism for shaping behaviour, the CRA introduces structural incentives that could encourage more responsible engagement with open source supply chains.
Despite its aims, the CRA introduces real risks for open source projects. Compliance requires time, legal and commercial expertise, and funding - resources that are often scarce in open source environments. There is also concern about how enforcement will be balanced across manufacturers, importers, and distributors - and whether obligations will be applied fairly in practice.
Another open question is whether the CRA could unintentionally push organisations towards proprietary solutions in order to simplify supply chain management. Ensuring that open source remains a viable and attractive option will require careful implementation, clear guidance, and sustained dialogue between policymakers and the open source community.
The CRA is intentionally high-level, with detailed guidance still under development - just as we were working on this blog post new draft guidance has been published and is open for consultation until the end of the month. This makes early engagement essential. Organisations and communities need time to map products, understand roles, assess gaps and adapt internal processes. Just as importantly, they need to share experiences and concerns to ensure that implementation supports security without undermining sustainability.
Handled thoughtfully, the Cyber Resilience Act has the potential to strengthen trust in digital products and align closely with open source values such as transparency, collaboration, and secure-by-design development. But achieving that outcome will depend on continued engagement, shared learning, and a clear recognition of the realities faced by open source projects.
At Element, this work is already underway. Whilst this is not an exhaustive list, it is already very clear to us that for a product such as Element Server Suite Pro, which was first placed on the market by Element, we are the original manufacturer under the Cyber Resilience Act. On the other hand, Element Server Suite Community is not intended for commercial use, so falls outside the scope of the CRA.
This means that for our commercial products we are responsible for meeting the CRA’s requirements across the full product lifecycle, including secure development practices, vulnerability handling, incident reporting and regulatory compliance. As part of this, we will be providing Software Bills of Materials (SBOMs) and applying a CE mark to these products.
Being the original manufacturer also means being the organisation to which security disclosures are directed and the entity accountable for the product’s security posture. This aligns with a principle that already underpins how we operate; if we develop and commercialise a product, we take responsibility for it.
The CRA also brings important clarity for open source more broadly. If a third party forks an open source project and commercialises their version, responsibility for CRA compliance rests with that party, not with the original developer or maintainer. In practice, this means that organisations choosing to deploy and purchase products such as Element Server Suite Pro or Synapse Pro can rely on Element to demonstrate how the regulatory and security responsibilities associated with the CRA are being met. This clarity benefits both users and the wider open source ecosystem by making accountability explicit.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。