It’s July 2026, and part of the Cyber Resilience Act (CRA) is now in effect; the remainder is imminent. The new EU regulations aim to significantly improve the cybersecurity of connected products placed on the European market. If your organization develops digital products such as IoT devices or EV chargers, you’re affected.
It’s July 2026, and part of the Cyber Resilience Act (CRA) is now in effect; the remainder is imminent. The new EU regulations aim to significantly improve the cybersecurity of connected products placed on the European market. If your organization develops digital products such as IoT devices or EV chargers, you’re affected.
The bar for cybersecurity is being raised - and substantially so. Especially if cybersecurity has not historically been a core part of your development process, a lot of new responsibilities are coming your way. Figuring out how to handle those responsibilities in practice, can be quite challenging.
Additionally, if you’re engaging a specialized software development partner (such as us) to assist with product development, you’ll need to decide how to divide these new responsibilities.
In this article, we’ll dive into your new obligations and how you can share them with your software partner. We’ll present our point of view based on three guiding principles.
Additionally, we'll give examples of what CRA-compliant product development can look like by illustrating how we apply some proven practices in the development of critical open-source projects.
The CRA in a nutshell
There are many great resources that explain the Cyber Resilience Act in detail, and we’ve relied on several of them in shaping our internal policy and this article. In particular, the official annexes are surprisingly accessible and worth reading. For example, Annex I outlines the essential cybersecurity requirements you’ll need to meet; and Annex III defines the two classes of critical products under the CRA.
For the purpose of this article, the most important thing to understand is:
- the party that places a product with digital elements on the EU market is considered to be the manufacturer, and;
- the manufacturer is responsible for CRA compliance.
This implies that you, as a manufacturer, are ultimately responsible. You can collaborate with a software development partner like us, and we can take the lead on and assist with many technical and process-related aspects. However, relying indefinitely on an external partner to meet requirements that may span five to ten years is neither practical nor cost-effective.
So, at some point, you’ll need to develop those capabilities in-house. That’s something worth anticipating and planning for early on.
Start preparing now!
The law was passed in December 2024, but when it comes to CRA compliance, the major milestones are:
June 2026: notification of conformity assessment bodies becomes mandatory
September 2026: reporting obligations take effect
December 2027: full application of the CRA
This means that preparation time - at the time of writing, i.e. July 2026 - is running out. For any future product development cycles, if you haven’t already done so, the time to start preparing is now!
What we think of the CRA
For years, we’ve been advocating that software must become safer. And we’re still struck by the number of vulnerabilities discovered in software people use every day, and the societal impact of large-scale data breaches. It should come as no surprise that we support legislation like the CRA, which pushes manufacturers to take security more seriously.
We strongly feel that the need for security by design and “shifting left” - embedding security early in the development process rather than treating it as an afterthought - is greater than ever in this era of agentic bug-finding and AI powered exploits.
The CRA formalizes this shift: It requires manufacturers to design, build, and maintain secure products from the outset. Combined with recent updates to the lesser known Product Liability Directive, which now explicitly includes software products, responsibility for security is firmly placed where it belongs: not with end-users, but with you, the manufacturers, and if you choose to collaborate, also with us, the parties that help to build these digital products.
Yes, having to comply with the CRA increases the complexity and cost of digital product development, and may even constrain innovation to some extent.
However, we think that the overall shift is positive and necessary, and creates opportunities to stand out with good security practices, for those who get it right.
Three guiding principles
Regardless of what industry you are intending to sell your products in, the CRA will confront you with the following questions:
- What are the exact requirements?
- What security measures should we implement?
- In which phase of the development life cycle should we do that?
And if you’ve opted to work with an external partner to assist you in product development:
- Who should do what?
That brings us to the key question of this article: How to approach dividing responsibilities when working with a partner for product development?
To us, these are the three guiding principles that shape these decisions:
Expertise matters. You’re the expert in your domain, while your product development partner will primarily bring technical expertise (in our case, this is expertise in building safe and secure products with Rust). This means that certain requirements, such as producing user documentation, naturally sit with you; while others, such as product development and security engineering requirements, sit with us.
Operational feasibility and costs matter. In our opinion, requirements such as long-term support (e.g. 5+ years) are typically better handled internally (at least eventually), i.e. by you yourself. Outsourcing these through long-term SLAs quickly becomes impractical and therefore expensive.
Design for independence over time. While we greatly value long-term partnerships, we think it is wise to assume that at some point you will want your team to become independent of your product development partner; When that time comes, you should have built the capabilities to handle CRA requirements independently. It’s extremely helpful if your partner takes the lead in meeting part of the CRA-requirements in the beginning, but it’s unwise to lean on that for too long.
Typical division
The requirements of the CRA for manufacturers are described here, and we have divided them into several categories in the table below. For each of these categories, we describe who we think should typically do what, based on our three guiding principles.
In light of the third principle, “Design for independence over time”, please note that even when we take the lead, you should anticipate being able to handle this requirement in the future yourself.
| Category | Who does what | Reasoning |
|---|---|---|
| Documentation | You’ll take the lead; we’ll assist you. | We’re skilled in writing technical documentation and developing threat models, but this category also includes documentation such as a broader risk assessment of your product and company, so you have an important role here too. |
| Product development | We will take the lead. | Developing safe and secure products with Rust is our core expertise, so we’ll take the lead; But eventually you should understand how this works and be able to continue independently. |
| Identification | You’ll handle this. | The CRA requirements dealing with correctly identifying your product are up to you. |
| Support | You’ll take the lead; we’ll assist you. | This may be tempting to offload, but be prepared to handle at least L1 support yourself, as it is costly to enter into an SLA for a 5+ year support period. |
| Vulnerability handling | You’ll take the lead; we’ll assist you. | We can help with a solid setup, applying best practices from critical open source projects; but be prepared to handle this yourself eventually, as entering into a long term contract to cover this is costly. |
Meeting the CRA requirements in practice
So far, we’ve examined CRA-compliance on an abstract level. For a more concrete understanding of how we typically fulfil certain requirements, let’s look at some practices from critical open source projects.
Why open source projects?
Why am I bringing up “critical open source projects”? After all, the CRA often doesn’t apply to those projects. Well, there is a significant overlap between the responsibilities that shape our open source practices and the CRA requirements!
Here are two examples of critical projects I’m thinking of:
The development of the open source Rust implementation of sudo that ships in Linux Ubuntu (the sudo-rs project)
The development of open source software written in Rust that is used by the Dutch Electoral Council in our national elections (the e-KS project)
For these kinds of open source projects, the security aspect is of paramount importance, and the shift-left mentality (“an ounce of prevention is worth a pound of cure”) has been part of our modus operandi for years.
We’ll give some examples of practices that can be used to meet some of the CRA’s documentation, product engineering, and vulnerability handling requirements.
Threat modelling
Threat modelling is the art of systematically mapping out what assets you’re trying to protect and the threats you anticipate that are associated with those assets. Once your threat model is clear, you can decide on mitigation, see what residual risk is acceptable to you (or not) and build your product accordingly.
There are many different ways of threat modelling. We’ve blogged about the Trike methodology before (and used it, for example in sudo-rs), but we have also applied different methods (such as in e-KS).
Regardless of the method chosen, a threat model, particularly one created early in the development process, is a very useful part of technical (developer aimed) documentation and is essential for the risk analysis and risk-based design requirements the CRA imposes.
Carefully selecting dependencies
Modern software, be it open source or closed source, includes many lines of code written by third parties. Rust projects in particular are known for having many dependencies, i.e. libraries or crates they pull in for specific functionalities. Without going into the discussion of whether many small dependencies (like in Rust) are better than fewer large dependencies (like in Go), it is important to very carefully select and monitor dependencies to decrease the product’s attack surface as much as possible and limit supply chain risk.
For dependency monitoring, we use tools like GitHub’s Dependabot extensively, and are pleased with a tool like Sonar Cloud which has proven useful in e-KS.
We previously wrote about dependency selection in sudo-rs. Similar practices are very useful for CRA-compliant product development.
Coordinated disclosure
In open source, it is common to practice “coordinated vulnerability disclosure”, i.e.ensuring that a fix is available before the details of a vulnerability are publicly announced, without unnecessarily delaying the disclosure of those details to the public. This way of working can easily be used as a blueprint for dealing with the vulnerability handling requirements the CRA imposes, as well as the requirements regarding downstream vulnerability reporting (i.e. reporting vulnerabilities to the users of your product or others that depend on you).
For example, whenever a vulnerability in sudo-rs is identified, downstream packagers (Ubuntu, Fedora, and others) are notified ahead of time, and the release date containing the fix is coordinated with them. This gives them optimal time to package the fix quickly. If necessary we also share more details with them under embargo. After that is done, an advisory is published containing full information about the bug, including its impact, what versions are vulnerable, and possible workarounds for users that cannot upgrade immediately.
Backporting security fixes
Finally, and particularly relevant for the CRA: if a software component is deeply embedded in a legacy product, a fix may be more difficult than a simple “update to the latest version”. This is quite similar to maintaining software that is part of a stable or Long Term Support Linux distribution. In these cases security fixes need to be retroactively applied to older versions, a practice which is called “backporting”. For example, even though the sudo-rs version in Debian “stable” is from April 2025, we have assisted in readying security patches that fix problems identified after its initial release.
Conclusion
The CRA imposes many obligations on the manufacturers of products with digital elements; Especially when working with a technical partner for product development, it’s important to clearly divide responsibilities and anticipate that at some point, you should be able to handle them yourself.
The guiding principles we put forward in this article offer a framework you can use to approach these decisions.
In practice, luckily, it’s not that hard to meet CRA requirements. We’ve shown several examples of practices we regularly apply in critical open source projects that would instantly tackle certain CRA requirements when applied to a commercial product.
Hopefully, the framework and observations in this article can help you solidify your CRA compliance process or get the conversation going with your current or future partner for product development.
If you’re considering building your next CRA-compliant product with us, please reach out. We'd be more than happy to explore how we can help you!