---
title: "How to determine if your software product falls under the Cyber Resilience Act"
url: "https://www.sparkfabrik.com/en/blog/understanding-cyber-resilience-act-compliance/"
lang: "en"
type: "blog-post"
date: "2026-04-20"
lastmod: "2026-04-20"
author: "SparkFabrik Team"
description: "The Cyber Resilience Act imposes new mandatory security standards for anyone placing digital products on the European market. We analyze risk classes, planned exclusions, and legal responsibilities for manufacturers. Turn this regulatory constraint into a competitive advantage."
tags: ["Security","Digital Transformation","Open Source"]
schema:
"@context": "https://schema.org"
"@type": "BlogPosting"
"headline": "How to determine if your software product falls under the Cyber Resilience Act"
"description": "The Cyber Resilience Act imposes new mandatory security standards for anyone placing digital products on the European market. We analyze risk classes, planned exclusions, and legal responsibilities for manufacturers. Turn this regulatory constraint into a competitive advantage."
"url": "https://www.sparkfabrik.com/en/blog/understanding-cyber-resilience-act-compliance/"
"datePublished": "2026-04-20T00:00:00+00:00"
"dateModified": "2026-04-20T00:00:00+00:00"
"author":
"@type": "Person"
"name": "SparkFabrik Team"
"image": "https://www.sparkfabrik.com/images/blog/come-capire-se-il-tuo-prodotto-software-rientra-nel-cyber-resilience-act/featured-en.webp"
"publisher":
"@type": "Organization"
"name": "SparkFabrik"
"url": "https://www.sparkfabrik.com"
"logo": "https://www.sparkfabrik.com/images/logo.svg"
---
# How to determine if your software product falls under the Cyber Resilience Act
**Author:** SparkFabrik Team
**Published:** 20 April 2026
**Tags:** Security, Digital Transformation, Open Source
---
{{% tldr %}}The Cyber Resilience Act imposes mandatory security requirements for digital products sold in the European Union, shifting responsibility from consumers to manufacturers. Understanding risk classes, deadlines by 2027, and the implications for the software supply chain allows companies to turn this regulatory obligation into a competitive advantage. By adopting standards such as Security by Design and the use of SBOMs, businesses can ensure compliance while avoiding heavy financial penalties.{{% /tldr %}}
For decades, the software industry has operated according to a very permissive implicit logic: release the product quickly, and fix bugs and security flaws later through updates. A defect in the code could have serious effects, such as paralyzing hospitals or logistics chains, but most of the risk fell on the end users. The **Cyber Resilience Act** (CRA) puts an end to this logic.
In the world of physical products, however, manufacturers are subject to much stricter constraints and liabilities. For example, if a company places an appliance on the market with a manufacturing defect that risks causing a short circuit, the product is immediately recalled and the manufacturer is held legally liable. Until now, this level of direct responsibility did not exist for digital products.
With this new regulation, the European Union has decided to equate the digital world with the physical one. **If you sell software in the European single market, you must guarantee its security from the design phase until the end of its lifecycle.**
This is not a simple recommendation. Cybersecurity ceases to be an optional feature and becomes a **binding requirement for market access**.
Before tackling the complex technical challenges related to compliance, you must answer a fundamental question: does your product fall under this regulation?
In the following sections, we will explore exactly who is involved, who is excluded, and how risk classes work. We will guide you through the key concepts with the experience of those who have followed the evolution of this law since its first drafts, helping you turn a regulatory obligation into a real competitive advantage for your company.
## Why has Europe decided that software can no longer ignore security?
Europe introduced the Cyber Resilience Act to make cybersecurity a mandatory legal requirement for digital products. The goal is to protect the market from systemic vulnerabilities, overcoming regulatory fragmentation and shifting the responsibility for security from end consumers to software producers.
Before the approval of this law, there were no mandatory minimum requirements. Each member state had different guidelines, creating a regulatory mosaic that penalized virtuous companies and left huge gaps in the protection of infrastructure. The burden of security fell on the shoulders of users, who were forced to navigate constant updates and complex configurations.
The decisive push for legislation came from the reality of the facts. In recent years, we have witnessed incidents that have shown how **a single flaw can bring thousands of organizations to their knees simultaneously**. These events made it clear that there is a need to [understand the risks and vulnerabilities of the software supply chain](/en/blog/software-supply-chain-cos-e/) to avoid devastating chain reactions.
Among the historical cases that guided the European legislator are:
* The SolarWinds attack, where malicious code inserted into a legitimate update compromised government agencies and Fortune 500 companies.
* The **systemic vulnerability** of Log4Shell, a defect in a tiny logging library that exposed millions of servers globally.
* The compromise of Codecov, which allowed attackers to exfiltrate credentials directly from CI/CD environments.
These incidents opened the eyes of legislators, highlighting systemic flaws capable of triggering devastating chain reactions. They demonstrated that the problem lies in the very foundation of development, affecting **Supply Chain Security**, or literally the security of the software supply chain.
The CRA reverses this logic: it moves from a reactive approach, based on the frantic release of patches after an attack, to **preventive security**. Security must be integrated from the design phase, adopting the principle of **Security by Design**, and companies will have to adopt rigorous software supply chain management practices.
It will be necessary to ensure that every third-party component is tracked, verified, and kept secure from the first day of development. For example, the use of tools to generate and monitor software bills of materials ([SBOM](/en/blog/sbom-cos-e-il-software-bill-of-materials/)) will become an operational standard for a secure software supply chain. It is no longer enough to react well; the law now requires designing securely.
## Which software products fall under the scope of the Cyber Resilience Act?
The Cyber Resilience Act applies to all "products with digital elements" placed on the European market. The regulation involves manufacturers, importers, and distributors of applications, operating systems, firmware, and software components, establishing mandatory security rules for anyone who develops and markets technology in the European Union.
To understand if your company is involved, you must look at the definition of a digital product. The concept of **"Products with Digital Elements"** was deliberately formulated broadly to avoid legal loopholes. In simple terms, if your product contains code and communicates with the outside world, it is almost certainly subject to the regulation.
The law does not distinguish between a mobile application downloaded from a store, management software installed on-premise, or the firmware that runs a corporate router. If your code processes data or connects to a network, it is highly likely that it falls within the legislator's scope.
The regulation precisely defines who must bear the burden of compliance:
* **Commercial software producers**, regardless of company size, who sell licenses or distribute apps in the EU market.
* **Software component suppliers**, including those who develop SDKs, libraries, or modules that will then be integrated into other companies' products.
* **Importers and distributors** who place technologies developed outside the Union's borders on the European market.
A crucial aspect to understand is the link to the secure software supply chain. The scope of the law is not limited to the code written by your developers, but includes all open source libraries and third-party components integrated into the final product.
In other words, **you are legally responsible even for vulnerabilities present in external packages that you have decided to include**. For this reason, it becomes vital to adopt [principles and best practices for software application security](/en/blog/guides/software-security-best-practice/) from the very early stages of development.
Another highly debated point concerns SaaS (Software as a Service) platforms. Although the cloud infrastructure itself may fall under other directives, software provided via a SaaS model is often considered a product with digital elements.
If your company offers cloud services, it is essential to assess your position promptly and [implement compliant software supply chain security strategies](/en/servizi/cloud-native-services/supply-chain-security/) to avoid penalties.
However, the legislator has provided specific exclusions to avoid regulatory overlap:
* **Software for internal use**, custom-developed and used exclusively within the company without being commercialized.
* **Products already covered by equally strict sectoral regulations**, such as medical devices regulated by the Medical Devices Regulation or software systems for the automotive industry.
* **Open source** projects developed and maintained **outside of any commercial logic**, to protect research and free collaboration.
The goal is to create a secure supply chain at a continental level, targeting commercial products that pose real risks to users, without stifling internal innovation or over-regulating sectors that are already covered.
## How do the Cyber Resilience Act risk classes work?
The Cyber Resilience Act classifies products into three levels: the Default Class for most software, and two classes of "Important Products" (Class I and Class II) for critical systems. Each level corresponds to progressively stricter conformity assessment requirements.
For a Project Manager or an IT manager, understanding which "drawer" to put their project in is the first operational step.
Europe has chosen a **proportional approach**. It makes no sense to impose the same security controls on a note-taking app and an enterprise-level firewall. For this reason, the legislator has structured a pyramid system that determines the effort required from companies.
For technical precision, it is useful to note that Class I and Class II make up the category of so-called "Important Products" (Annex III of the regulation). There is also an even narrower category of "Critical Products" (Annex IV) subject to specific rules. The following table summarizes how the main risk categories are divided.
| Class | Regulation Category | Examples | Required Assessment |
| -------------------- | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| **Default Class** | ~90% of standard software products on the market | Common mobile apps, management software, video games, smart TVs, IoT thermostats | Self-assessment of conformity by the manufacturer |
| **Class I** | Important products that handle privileges or sensitive data (Annex III) | Password managers, web browsers, routers, general operating systems, antivirus | Application of EU harmonized standards or third-party assessment |
| **Class II** | Important products with high risk to digital infrastructure (Annex III) | **Container runtime**, **hypervisor**, industrial firewalls, smart meters | Mandatory audit conducted by independent certification bodies |
| **Critical Products** | Critical systems for strategic digital infrastructure (Annex IV) | Systems for national critical infrastructure | Additional specific requirements |
The impact of the classification established by the CRA on modern IT architectures is profound. **Fundamental technologies for the Cloud Native paradigm**, such as container runtimes and hypervisors, have been **explicitly included in Class II**. This means that the engines that run the microservices of half of Europe will have to pass the strictest exams provided for by the law.
If your company develops or provides infrastructure based on Kubernetes or virtualized environments, the level of attention must be at its highest. It becomes essential to [delve into the challenges and strategies of Cloud Native Security](/en/landing/guida-cloud-native-security/) to understand how these requirements will change the way we orchestrate and deploy modern applications. The security of the underlying infrastructure is no longer just an operational best practice, but a certified legal obligation.
## What are the deadlines and dates to mark for the Cyber Resilience Act?
The Cyber Resilience Act provides for a gradual application to allow companies to adapt. The key dates are June 11, 2026, for the operation of assessment bodies, September 11, 2026, for the obligation to notify vulnerabilities, and December 11, 2027, for full product compliance.
The regulation is now in force, and companies must start planning their adaptation to the CRA. The legislator has provided for a phased transition period to allow the market to organize itself without suffering sudden blocks.
Here are the legal **deadlines** that every Project Manager and CTO must know:
* **June 11, 2026**: Provisions relating to conformity assessment bodies become operational. The certification infrastructure for Class I and II products will officially begin.
* **September 11, 2026**: The notification obligation is triggered. Manufacturers will have to report actively exploited vulnerabilities and significant security incidents to the competent authorities within strict time limits.
* **December 11, 2027**: All mandatory requirements for new products come into force. From this date, no software subject to the regulation can be sold in the EU without demonstrating full compliance with the CRA.
## From controversial proposal to law: what changes for open source?
The Cyber Resilience Act explicitly excludes open source software developed outside of commercial logic from its direct regulatory scope. This is a fundamental protection for the ecosystem that underlies Cloud Native technologies and protects independent contributors to the open source ecosystem.
Yet this exclusion is not a given: it is the direct result of a strong mobilization of the community, which obtained a revision of the original proposal and a much more balanced final text.
Today, the law makes a very clear and pragmatic distinction. If a programmer develops software or a library in their spare time and publishes it online as a **non-profit open source project, they are not subject to the obligations of the CRA**.
However, if a company takes that free project, integrates it into its proprietary software, and sells the final product, **the company assumes full legal responsibility for the security of that component**.
This mechanism shifts the responsibility exactly where the profit lies. Companies that use open source components to build their services will have to invest resources to verify the open source code they choose to adopt. A compromise that protects independent creators while forcing companies to do their part.
### SparkFabrik and #FixTheCRA: when the community made itself heard
Achieving this regulatory balance did not happen by chance. It is the result of a strong global mobilization in which the technology community made its voice heard in a cohesive and structured way.
When the regulation was still in draft form, the original text presented a huge risk to innovation. The initial wording did not clearly distinguish between the release of open source code by volunteers and the placing of a commercial product on the market.
This would have made upstream contributors legally liable for the vulnerabilities of their projects, even when they were used by multinationals to generate profits.
Understanding the gravity of the situation, SparkFabrik and many other players in the sector joined the **#FixTheCRA** campaign promoted by the **Linux Foundation Europe**. Our goal was clear: to defend [European competitiveness and the EU's digital sovereignty](/en/blog/cyber-resilience-act-competitivit%C3%A0-europea-sovranit%C3%A0-digitale-ue/) without destroying the collaborative model on which modern software is based.
Our CTO, **Paolo Mainardi**, as an Advisory Member of the Linux Foundation Europe, actively participated in this advocacy effort. We documented and disseminated the [community's concerns for open source](/en/blog/cra-e-open-source/), explaining to policymakers that strangling independent maintainers would have made Europe less secure, not the other way around.
This effort reflects SparkFabrik's deep [commitment to the open source ecosystem](/en/open-source/), which we consider the true engine of digital innovation.
The community's mobilization worked, leading to a final text that is much more balanced and aware of the actual development dynamics. In fact, today [the position of Europe and public administrations towards open source software](/en/blog/drupal4goveu-sovranita-digitale-e-open-source-per-la-pa/) is increasingly favorable, recognizing its importance for digital sovereignty goals.
## What does the CRA mean for your company and what are the next steps?
For your company, the CRA means having to accurately map all the software produced and used, assess risk classes, and prepare transparent documentation on dependencies. The first step is to perform a comprehensive assessment to identify current vulnerabilities.
The central message is unequivocal: **the CRA transforms cybersecurity from an optional product feature into an indispensable legal requirement** to access the European market. Today, it is no longer possible to think about releasing software without also thinking about security, starting from the design phase.
The **first step** is to understand **if your product falls under the regulation and what risk level it falls into**. This initial mapping is essential to avoid wasting resources or, conversely, underestimating strict legal obligations.
The next step is to **understand how to address technical adaptation**. This is a profound impact that requires specific knowledge, from secure dependency management to the implementation of automated controls in release pipelines.
Furthermore, it should not be forgotten that this law does not operate in isolation; it is part of a much broader European strategy. The European Union is building an integrated regulatory shield.
While the CRA focuses on the intrinsic security of products, it is also essential to [analyze the impact of NIS2 and DORA on cybersecurity](/en/blog/nis2-dora-impatto-sulla-cybersecurity-nel-cloud-native/) to understand how to protect critical infrastructure, always keeping an eye on the AI Act for high-risk systems.
To navigate this complexity and the transition to compliance without slowing down time-to-market, it is advisable to evaluate the **support of an expert partner like SparkFabrik**, capable of combining regulatory expertise and deep mastery of Cloud Native architectures.
As a guarantee of our competence in this area, SparkFabrik is in the process of **ISO 27001** certification, the international standard for information security management. The synergy with the CRA is direct: the risk management and operational controls of ISO 27001 facilitate the risk assessments and secure lifecycle management required by the CRA. In fact, those who already implement ISO 27001 processes have a significant advantage in achieving compliance.
Despite the technical challenges, the Cyber Resilience Act should not be experienced only as a bureaucratic burden. **This transition is an extraordinary opportunity** to eliminate technical debt, improve product stability, and win the trust of enterprise customers, turning a legal obligation into a solid competitive advantage.
If your company develops commercial software or manages complex platforms, don't wait until 2027 to discover that your architecture is not compliant. [Find out how SparkFabrik can support you with the Cyber Resilience Act](/en/risorse/hot-topics/cra-cyber-resilience-act/) through assessment, modernization, and secure-by-design pipeline implementation services.
---
## Frequently Asked Questions
### What is the Cyber Resilience Act in simple terms?
The CRA is a European regulation that imposes mandatory cybersecurity requirements for all products with digital elements sold in the EU, ensuring they are secure from design through the end of their lifecycle.
### Does the Cyber Resilience Act apply to open source software?
It applies to open source software only if it is integrated into commercial contexts or monetized. Open source code developed and distributed outside of commercial activities is explicitly excluded from direct obligations.
### What are the penalties provided for by the Cyber Resilience Act?
Companies that do not meet compliance requirements face severe penalties, which can reach up to 15 million euros or 2.5% of annual global turnover, whichever is higher.
### How does the CRA relate to the NIS2 directive and the AI Act?
The CRA focuses on the intrinsic security of software and hardware products. It works in parallel with NIS2, which regulates the resilience of critical infrastructure, and with the AI Act, which specifically regulates risks related to artificial intelligence systems.
### Do web applications or e-commerce sites fall under the CRA?
Web applications and e-commerce sites fall within the scope of the CRA if they distribute software components to users or if they process data in a complex way. Simple non-commercial informational websites are generally excluded from the regulation.
---
## Related Articles
- [Drupal AI 1.3: security, governance, maturity and new tools](https://www.sparkfabrik.com/en/blog/drupal-ai-1-3-security-governance/) - The adoption of LLMs in CMSs requires solid architectures to avoid privacy risks and hallucinations. …
- [NIS2 and DORA: Strategies and Best Practices for Cloud Native](https://www.sparkfabrik.com/en/blog/nis2-dora-strategies-best-practices-cloud-native/) - Practical strategies for implementing NIS2 and DORA requirements in cloud-native architectures. …
- [The impact of NIS2 & DORA on Cloud Native cybersecurity | SparkFabrik](https://www.sparkfabrik.com/en/blog/nis2-dora-impact-on-cybersecurity-in-cloud-native/) - Analysis of NIS2 and DORA and the security implications for Cloud Native architectures. Learn how …
---
*This is a Markdown version of the blog post to facilitate reading by AI and crawlers.*
*Visit [https://www.sparkfabrik.com/en/blog/understanding-cyber-resilience-act-compliance/](https://www.sparkfabrik.com/en/blog/understanding-cyber-resilience-act-compliance/) for the full version with images and formatting.*
