What does the Cyber Resilience Act mean for software companies? New security standards explained simply

The most important facts about the Cyber Resilience Act for software companies

• The Cyber Resilience Act affects not only hardware, but also many software products.
• Software is considered CRA-relevant as soon as it processes, communicates or updates data.
• Manufacturers must establish security-by-design, vulnerability management, SBOMs and reporting processes.
• Those who act early not only meet regulatory requirements, but also increase security and customer confidence.

Why software companies cannot ignore the Cyber Resilience Act

At first glance, the Cyber Resilience Act only appears to be relevant for hardware manufacturers. The EU regulation refers to „products with digital elements“ - which initially sounds like networked devices, machines or IoT systems. Many software companies see themselves more as service providers or operators of digital services. They do not produce anything physical and therefore believe that the CRA does not play a role for them.

In fact, the wording partially confirms this impression: Pure services such as SaaS offerings that are not provided as a product on the market are excluded. The same applies to non-commercial open source software. But this first impression is deceptive.

Why software products also fall under the CRA

Article 3 of the CRA deliberately defines very broadly what a „product with digital elements“ is: software or hardware - including individual software components. This means that software falls within the scope as soon as it sends, receives or processes data, is downloaded via updates, communicates with other systems or is integrated as a component in another product.

Typical examples are apps with a cloud connection, systems with online licensing, backend services or APIs that exchange data, and software modules in larger platforms or vehicle services. The CRA is therefore not just a hardware law, but a security standard for modern, networked software.

Which CRA requirements specifically apply to software manufacturers?

In Articles 13 and 14, the CRA sets out clear requirements that also apply to software developers: These include compliance with basic security requirements, the performance of a conformity assessment, the creation of technical documentation and reporting obligations in the event of vulnerabilities and security incidents.

For many software teams, this means that security by design, active vulnerability management and structured lifecycle processes are becoming mandatory.

How the CRA is changing company processes

The CRA affects every product that communicates digitally - and therefore also most modern software solutions. Companies should check at an early stage which products fall within the scope, who is considered an internal „manufacturer“ within the meaning of the CRA and how security by design, vulnerability management and documentation can be established efficiently. The transition period until 2027 may seem generous, but early action is crucial, especially for processes that first need to be established.

How do we implement the CRA requirements in practice?

Our experience shows how complex the implementation of CRA requirements can be - especially when dealing with security vulnerabilities (CVEs) in software and third-party libraries. In recent years, we have systematically analyzed and evaluated CVEs, including with an internal virus scanner. Critical gaps, for example in third-party libraries such as Log4J, are immediately prioritized and communicated directly to affected customers in a timely manner. This is particularly important for on-prem customers, as they are responsible for implementing updates themselves.

Although gaps that cannot be exploited are assessed and rectified internally, they are not disclosed immediately. This is changing with the new public process according to CRA and BSI: In future, CVEs must be reported via an official BSI account, even if they are not classified as critical internally. The internal risk assessment therefore only determines the urgency of the customer information, not the report itself.

We also create an up-to-date software bill of materials (SBOM). This allows us to prove at any time which libraries and components were used to develop our product. This practical approach shows that safety processes, transparent communication and official notifications are crucial to ensure both compliance and customer safety.

FAQ: Frequently asked questions about the Cyber Resilience Act and software

Does the Cyber Resilience Act apply to software-only products?

• Yes, the CRA applies to software as soon as it is considered a product with digital elements - i.e. it processes data, communicates, is updated or is part of a larger system.

Is SaaS affected by the Cyber Resilience Act?

• Pure SaaS services are generally exempt. However, as soon as software is marketed as a product or integrated into other products, the CRA may apply.

What exactly do software manufacturers have to implement under the CRA?

• This includes security-by-design, vulnerability management, technical documentation, conformity assessment and reporting obligations in the event of security gaps and incidents.

What is an SBOM and why is it important under the CRA?

• A software bill of materials documents all libraries and components used. It is crucial for making safety risks transparent and demonstrating CRA compliance.

When does the Cyber Resilience Act become binding?

• The CRA provides for transition periods until 2027. Companies should use this time to set up processes and structures at an early stage.