If your company develops software, sells connected devices, or distributes digital products in Europe, you've probably heard about the Cyber Resilience Act (CRA).
Unfortunately, most explanations online either quote the legislation directly or dive into legal terminology that leaves you with more questions than answers.
After reading through all 71 articles of the regulation, one thing became clear:
The CRA isn't trying to make software development harder. It's trying to make software vendors responsible for the security of what they ship.
Here's what that means in practice.
The Cyber Resilience Act is a new EU regulation that introduces mandatory cybersecurity requirements for products with digital elements.
In simple terms, if you sell software, hardware, IoT devices, or cloud-connected products in the European Union, cybersecurity is no longer just good practice; it is a legal requirement.
Unlike standards such as ISO 27001, which organizations voluntarily adopt, the CRA is legislation. If your product falls within its scope, compliance is mandatory.
The first reporting obligations begin in September 2026, while the full regulation applies from December 2027.
This is where many people get confused.
The CRA primarily targets organizations that place products on the EU market.
That includes:
However, not every open-source project is automatically subject to the same obligations.
The regulation makes an important distinction between:
This distinction matters because the compliance requirements are very different.
For example, an organization maintaining an open-source Kubernetes management tool has significantly lighter obligations than a company selling that tool as part of a commercial product.
The regulation is long, but most organizations will spend their time on surprisingly few areas.
Security can no longer be something that's added just before release.
Organizations are expected to follow secure development practices throughout the software lifecycle, including:
Many engineering teams already do much of this today; the difference is that it now needs to be consistent and demonstrable.
Sooner or later, someone will discover a security issue in your product.
The CRA expects organizations to make it easy for researchers and customers to report vulnerabilities and to have a documented process for investigating and fixing them.
In practice, this usually means:
Many organizations already have internal incident procedures, but never publish them externally.
Shipping software isn't the end of your responsibility.
The CRA expects vendors to continue fixing security vulnerabilities throughout the declared support period.
Security updates must remain available, and customers should clearly understand how long a product will receive security maintenance.
From September 2026, certain actively exploited vulnerabilities and severe security incidents must be reported to European authorities within strict timelines.
The regulation introduces reporting windows measured in hours rather than weeks.
Fortunately, these requirements apply only to a relatively small number of high-impact security situations, not to every bug that gets discovered.
This is probably the most misunderstood part of the CRA.
Maintaining an open-source project does not automatically make you a manufacturer under the regulation.
If your project is freely available and isn't being commercially placed on the market, your obligations are much lighter.
Open-source maintainers are still expected to:
They are not expected to complete product conformity assessments or CE marking simply because they maintain an open-source repository.
Most companies can approach compliance gradually, which should help organizations feel less overwhelmed and more in control as they prepare.
For many teams, compliance is about documenting and formalizing practices that already exist.
A practical starting point is to make sure you have:
Organizations already following frameworks like ISO 27001 will find that many operational security practices are already in place. The CRA simply makes several of these practices mandatory for products placed on the European market.
The Cyber Resilience Act represents a significant shift in how software security is regulated.
Rather than focusing only on compliance paperwork, it encourages organizations to treat cybersecurity as an ongoing responsibility throughout a product's lifecycle.
For engineering teams, the biggest challenge won't be writing documentation; it will be proving that secure development, vulnerability handling, and long-term product maintenance are part of everyday operations.
Organizations that start preparing now by reviewing their security practices, establishing vulnerability-reporting channels, and documenting their processes will find it much easier to meet the September 2026 and December 2027 deadlines, thereby avoiding unnecessary last-minute compliance work.