Cyber Resilience Act: What Software and SaaS Providers Need to Implement Now

IT Law · Digital Law Series, Part 2 | Part 1: Product Liability for Software | Part 3: NIS2 ·As of: October 2026

Friday, 10 p.m.: A security researcher informs you that attackers are actively exploiting a vulnerability in the update agent of your software. Since 11 September 2026, this message starts a deadline. Under the Cyber Resilience Act (CRA), an early warning must reach the European reporting platform by Saturday evening. Anyone who only starts looking for the process now will lose exactly the hours they do not have.

The CRA makes cybersecurity a product characteristic, as binding as the electrical safety of a toaster. It also specifies what level of security your product must offer. In this article, you will learn which software is covered and when SaaS falls under it. We also show which obligations already apply today and the seven steps you can take to become compliant by December 2027.

Key points at a glance

• Software is covered as soon as it runs on the user’s side: Desktop programs, apps, plug-ins, SDKs, firmware and operating systems are included. You do not need your own hardware for this.
• The reporting obligation already applies: Early warning within 24 hours, notification within 72 hours. This also applies to products that were already on the market before the cut-off date.
• SaaS is a borderline case: The hosted backend usually remains outside the scope. Cloud functions without which a device cannot work, however, are part of the product.
• At least five years of security updates are the rule, and correspondingly more if a longer period of use is expected.
• Fines of up to EUR 15 million or 2.5% of worldwide annual turnover may be imposed for violations of the core obligations. Under civil law, the CRA takes effect via the new product liability rules.

What is the Cyber Resilience Act?

The Cyber Resilience Act is an EU regulation. It applies directly in all Member States, so no German implementing act is required. Its approach is new to the IT industry but familiar from product law. Before a product is placed on the market, the manufacturer assesses the risks and implements the requirements. It then documents everything and confirms conformity with the CE marking.

The key difference from conventional products: the obligations do not end with the sale. Instead, the CRA accompanies your product throughout its entire life cycle, from design and updates to the end of the support period.

Overview of the Cyber Resilience Act timeline

The Commission guidance is not legally binding. Only the CJEU can interpret the CRA bindingly. However, market surveillance authorities and conformity assessment bodies will follow it. Anyone who deviates from it must therefore be able to justify their solution well.

CRA, NIS2 and product liability: Who regulates what?

Many companies lump the new regulations together. However, they apply at different points and can apply in parallel:

In the first part of our series, we showed why software will in future be liable like a machine. The CRA provides the benchmark for this. The link to product liability is therefore particularly close: cybersecurity requirements feed into the question of whether a product is defective. If your product does not meet mandatory security requirements, a court may even presume a product defect. Your CRA documentation is therefore also your most important evidence in a liability case.

Which products fall under the Cyber Resilience Act?

The CRA refers to products with digital elements (Art. 3(1) CRA). This means software or hardware with a direct or indirect data connection to a device or network. The intended or reasonably foreseeable use is decisive. A logical connection is sufficient, for example that of a local program to the operating system. The industry is irrelevant; only the product matters. Typically covered are:

• Connected hardware such as routers, cameras, smart home devices, wall boxes or industrial controllers
• Locally executed software such as desktop applications, mobile apps, browser extensions and operating systems
• Components, that are marketed separately, such as firmware, libraries or software modules
• Remote data processing, i.e. cloud functions that a manufacturer develops for its product and without which the product cannot perform one of its functions

Products without any connectivity, on the other hand, are not covered, for example the firmware of a dishwasher without a network connection.

Exceptions: Specific legislation takes precedence

Where equivalent EU rules already exist, the CRA steps back. This applies above all to medical devices and in vitro diagnostics (MDR and IVDR) as well as type-approved motor vehicles. Certified aeronautical products, marine equipment as well as products for national security and defence are also excluded. Identical spare parts are not covered either (Art. 2(6) CRA). Check each exception on a product-by-product basis, as there is no blanket industry exemption.

Open source: privileged, but not exempt across the board

Free and open-source software that you make available without commercial activity does not fall under the manufacturer obligations. It becomes commercial as soon as you charge a price for the software. The same applies if you monetise it through advertising or subscriptions. According to the guidance, however, a donation link alone is not sufficient. Some foundations and other legal entities support open-source projects on a long-term basis. For them, the CRA creates the role of the open-source software steward with significantly lighter obligations (Art. 24 CRA).

For most companies, however, the other direction is more important. Anyone who integrates open-source libraries into their product remains the manufacturer of the overall product. You must exercise due diligence when selecting components (Art. 13(5) CRA). You must also report any vulnerabilities you find to the project (Art. 13(6) CRA). This follows the same logic we described for product liability in Part 1.

Does SaaS fall under the Cyber Resilience Act?

This is the question software companies ask most often. The answer does not depend on the business model. What matters is where the software runs and what function it performs for another product. Some software runs exclusively on your infrastructure, and your customers only use it in the browser. On its own, it is therefore not a product within the meaning of the CRA. Comparable services are more likely to fall under NIS2. Everything you ship to customers, on the other hand, is covered.

This means that one and the same offering can be partly in and partly out of scope . The following overview helps with an initial classification:

Remote data processing: the three test questions

However, many overlook the most difficult case: cloud services that support a function of a connected product. Remote data processing exists if all three conditions are met:

• Remoteness: The data is processed outside the product, for example in the cloud.
• Necessity: Without the processing, the product could not perform at least one of its functions.
• Responsibility: The software comes from the manufacturer itself or was developed under its responsibility.

According to the guidance, only the modules with which the product directly interacts, including their interfaces, count. Downstream back-office systems are therefore not included.

Practical example: A wall box manufacturer has load management calculated in its own cloud. Without this calculation, however, the wall box only charges at minimum power. The cloud is therefore remote data processing, and the manufacturer assesses it together with the wall box. The external service the same manufacturer uses to send invoices, on the other hand, is not covered by the CRA.

What SaaS providers should prepare anyway

Even if your service itself does not fall under the CRA, it may be part of the supply chain of a regulated product. Your customers must carefully vet their suppliers and will therefore ask for evidence. Have the following ready:

• An up-to-date list of third-party components and subcontractors used
• A documented vulnerability process, from report to customer notification
• Binding information on security updates and their frequency
• Emergency and recovery plans for business-critical services
• A responsibility matrix that defines who coordinates vulnerabilities, approves updates and informs customers

What obligations do manufacturers have under the Cyber Resilience Act?

The main burden lies with the manufacturer. This is anyone who develops a product or has it developed and markets it under their own name. Distributors and importers also become manufacturers if they sell a product under their own brand or substantially modify it. This particularly affects white-label models. From 11 December 2027, the following obligations in particular apply:

• Risk assessment (Art. 13(2) CRA): This is the foundation. It determines which requirements are relevant for your product. The CRA is risk-based and does not require products to be completely free of defects.
• Security by design and by default (Annex I Part I): secure default settings, protection against unauthorised access, data minimisation and protection of integrity and confidentiality.
• Vulnerability handling (Annex I Part II): a software bill of materials (SBOM), remediation without delay and free security updates, separated from feature updates where possible. In addition, a coordinated vulnerability disclosure policy and a contact point for reports are required.
• Support period (Art. 13(8) CRA): It is based on the expected period of use and is generally at least five years. Buyers must be able to identify it at the time of purchase. For software with many releases, each version needs its own period.
• Documentation and conformity: technical documentation, conformity assessment, EU declaration of conformity and CE marking.

Important and critical products: When a conformity assessment body is required

How you demonstrate conformity depends on the core functionality of your product. Annexes III and IV of the CRA list the categories. They are technically described in Implementing Regulation (EU) 2025/2392:

• Standard products: You assess conformity yourself. This applies to the vast majority of software.
• Important products of Class I, such as password managers, VPN software or operating systems: self-assessment only if you fully apply a harmonised standard or a comparable framework.
• Important products of Class II, such as firewalls or hypervisors, as well as critical products: You must involve an external body.

An additional function does not change the classification as long as it merely complements the core function. Be careful with modular platforms, however: modules that customers buy or subscribe to separately are separate products with their own classification. Plan early for Class II, as the capacities of conformity assessment bodies are limited.

Updates: When does your software become a new product?

A substantial modification (Art. 3(30) CRA) legally turns your product into a new product requiring a new assessment. The benchmark is the risk, not the extent of the change. A security update is generally not a substantial modification, even if it makes deep changes to the code. A small new feature, on the other hand, can be one if it opens up new attack surfaces. This applies, for example, to remote access for support.

For every major release, check four questions: Do new attack vectorsarise? Do new attack scenarios become possible? Does the likelihood of known scenarios increase? Does their impactchange? If the answer is no four times, there is usually no substantial modification.

Practical tip: Include planned roadmap features in your risk assessment today. Features that have already been assessed can be activated later without triggering a substantial modification.

Reporting obligations since 11 September 2026: How reporting works

The reporting obligations under Art. 14 CRA are the first part of the CRA that already applies. They concern two events: actively exploited vulnerabilities and severe security incidentsthat affect the security of your product. You report once via the ENISA Single Reporting Platform. From there, the report is forwarded to the competent national CSIRT at the location of your main establishment and to ENISA. In Germany, the CSIRT is located at the BSI.

In practice, however, companies often overlook three points:

• Legacy products are also covered. The reporting obligation applies regardless of when the product was placed on the market. According to the guidance, it even applies after the support period has ended.
• Third-party components count if attackers exploit them in your product. A vulnerability in an integrated library becomes reportable as soon as attackers actively exploit it in your product.
• You must inform users, in a risk-based and proportionate manner. However, you do not have to publish technical details that would help attackers.

Practical example: A provider of accounting software learns on Friday at 6 p.m. that attackers are actively attacking its desktop client. The early warning must therefore be submitted by Saturday at 6 p.m. If personal data is leaked, the 72-hour deadline under the GDPRruns in parallel. This requires a separate notification to the data protection authority. You should therefore manage both processes from a joint response plan.

What are the penalties for violating the Cyber Resilience Act?

The sanctions framework follows the pattern of recent EU digital laws (Art. 64 CRA):

• Up to EUR 15 million or 2.5% of worldwide annual turnover for violations of the essential security requirements and the core manufacturer obligations, including the reporting obligations
• Up to EUR 10 million or 2% for violations of other obligations
• Up to EUR 5 million or 1% for incorrect or incomplete information provided to authorities

In addition, market surveillance measures may be taken, up to and including sales bans and recalls. The biggest economic lever, however, is likely to be product liability . Anyone who does not meet the CRA requirements hands injured parties the argument for a product defect on a plate.

Recommendations: 7 steps to CRA compliance

1. Record products and roles: First, list all products with digital elements. Then determine for each product whether you are the manufacturer, importer or distributor. Pay particular attention to white-label and private-label products.
2. Separate the components: For SaaS offerings, first separate the backend from everything you ship. Then check the three criteria for remote data processing for cloud functions.
3. Set up the reporting process immediately: Create an EU Login account, register on the ENISA platform, determine the competent CSIRT, and define on-call duty and templates. This obligation already applies.
4. Build an SBOM and map the supply chain: Record all third-party and open-source components with their versions. Then continuously monitor them for vulnerabilities.
5. Define the support period: Determine the period for each version and calculate the costs. Also include it in offers and contracts.
6. Clarify the class and conformity route: First assign each product to a category. For Class II or critical products, talk to a conformity assessment body at an early stage.
7. Align contracts and liability: Agree with suppliers contractually on SBOM delivery, vulnerability information, update obligations and recourse. Finally, align the measures with your preparations for the new product liability law.

Conclusion: The Cyber Resilience Act makes security a product characteristic

The CRA ends the era in which cybersecurity was a voluntary question of quality. Here are three key takeaways:

• Software is a product. Anyone who ships software is therefore a manufacturer, even without a single device in their portfolio.
• SaaS does not automatically exempt you. What matters is what runs on the customer’s side and what function your service performs for another product.
• The clock is already ticking. The reporting obligations have applied since September 2026, with full application following in December 2027.

If you consider the CRA and product liability together, you only have to complete many tasks once. The same documentation that proves conformity will also defend you in court.

This article is for general information purposes only and does not replace legal advice in individual cases. As of: October 2026. The text of Regulation (EU) 2024/2847 published in the Official Journal is authoritative. The Commission guidance is not binding.

Would you like to know which of your products fall under the CRA? Arrange a no-obligation initial consultation. We will classify your portfolio and review your reporting process and your supply contracts.

Request an initial consultation

FAQ: Frequently asked questions about the Cyber Resilience Act