Cyber Resilience Act for software and SaaS: does it apply?
Hephaestus Technology7 min read

The Cyber Resilience Act applies to software you place on the EU market, such as mobile apps, desktop programs and firmware, but pure SaaS delivered remotely is generally outside it. Cloud back ends are only covered when they are "remote data processing solutions" a manufacturer builds for its own product, under Regulation (EU) 2024/2847. Standalone cloud services fall instead under the NIS2 Directive, so the Cyber Resilience Act and software questions depend on how your product is delivered, not on whether it is "just code".
Key takeaways
- Downloadable or installed software, including mobile apps, is a product with digital elements under the CRA.
- Standalone SaaS is generally outside the CRA; Recital 12 points cloud services to the NIS2 Directive instead.
- A cloud back end you design so your app or device can work is 'remote data processing' and is in scope with that product.
- Free open-source software is usually out of scope unless it is monetised; the Commission's July 2026 guidance gives examples.
- Reporting of actively exploited vulnerabilities has applied since 11 September 2026 for in-scope software.
What counts as software under the Cyber Resilience Act?
Software is explicitly covered. The Act defines a product with digital elements as "a software or hardware product and its remote data processing solutions" (Article 3(1)). The Commission's CRA page gives household appliances, computer games and mobile applications as examples of products subject to a conformity procedure.
In practice, if a customer downloads, installs or receives your software and runs it in their own environment, it is a product. That includes:
- mobile apps on the App Store or Google Play;
- desktop and server software sold under licence;
- firmware and embedded software on devices;
- software libraries and SDKs supplied commercially;
- browser extensions and on-premises tools.
Is SaaS covered by the Cyber Resilience Act?
Generally no, when the SaaS is a standalone service. Recital 12 says cloud solutions are remote data processing solutions under the CRA "only if" they meet that definition, excludes "cloud services designed and developed outside the responsibility of a manufacturer", and notes that Directive (EU) 2022/2555 (NIS2) "applies to cloud computing services and cloud service models" such as SaaS, PaaS and IaaS.
The Commission's guidance of 27 July 2026 follows the same line. As summarised by Orrick, it says "Software executed remotely for user access regularly falls outside the scope of the CRA."
So a browser-based project management tool, an online accounting platform or a hosted analytics product is usually not a CRA product in itself. That does not mean no rules apply: depending on size and sector, a cloud provider may fall under NIS2, and almost every SaaS business handles personal data under the GDPR. Our GDPR checklist for a new SaaS product covers that side.
When is a cloud back end in scope?
When it is the "remote data processing" behind a product. Article 3(2) defines this as "data processing at a distance for which the software is designed and developed by the manufacturer", and Recital 11 limits it to processing that is "necessary for a product with digital elements to perform its functions".
The guidance adds two clarifications, according to the Commission's summary and Orrick's analysis:
- "At a distance" typically means processing outside the product's user environment, with cloud computing as the typical example.
- Internal systems such as HR tools, CRMs, CI/CD pipelines and security update infrastructure "should not be considered as remote data processing solutions".
The practical test: if the device or app would not deliver its intended functions without your cloud service, and you designed that service for it, treat the service as part of the product. Its security then counts toward your CRA compliance, and incidents in it can trigger reporting.
How do common software models compare?
The table below applies the definitions above to typical business models. It is a starting point, not legal advice; borderline cases need a proper assessment.
| Product model | CRA position | Why |
|---|---|---|
| Mobile app sold or offered commercially in the EU | In scope | Software product made available on the market |
| Licensed desktop or on-premises software | In scope | Software product made available on the market |
| Smart device with companion cloud and app | Device, app and companion cloud in scope | Cloud is remote data processing designed by the manufacturer |
| Mobile app with a back-end API it needs to work | App in scope; back end likely in scope as remote data processing | Back end is necessary for the app's functions |
| Pure SaaS used in a browser | Generally out of CRA scope | Recital 12 and the 2026 guidance; NIS2 may apply |
| Free open-source library, not monetised | Generally out of scope | Recital 18: no commercial activity |
| Open-source project monetised through the product | May be in scope | Guidance: monetisation can mean placing on the market |
What about open-source software?
It depends on monetisation. Recital 18 says open-source products "that are not monetised by their manufacturers should not be considered to be a commercial activity", and that regular releases alone do not make them commercial. The Commission's guidance, as reported by Orrick, explains that free software can still be treated as placed on the market if it monetises other products or services, or requires personal data processing for reasons other than security or compatibility.
Two further points matter for software companies. Manufacturers that integrate open-source components must apply due diligence to them (Article 13(5)) and report vulnerabilities they find to the maintainers (Article 13(6)). Open-source software stewards, such as foundations that systematically support projects intended for commercial use, have a lighter regime under Article 24.
What does an in-scope software company have to do?
Three things, on two timelines.
- Now: report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform, with a 24-hour early warning, under Article 14, which has applied since 11 September 2026.
- From 11 December 2027: meet the Annex I security requirements, including secure defaults, security updates, access control, encryption and logging, and the vulnerability handling rules, which require a software bill of materials covering at least top-level dependencies.
- Also from December 2027: set a support period of at least five years unless the product's expected use is shorter (Article 13(8)), prepare technical documentation, sign a declaration of conformity and affix the CE marking.
Most software is a default product that can self-assess. Some categories are listed in Annex III as important products, including operating systems, browsers, password managers, VPNs, identity and access management software and SIEM systems, which carry stricter conformity routes.
What are the pitfalls for SaaS founders?
The main one is assuming "we are SaaS, so the CRA is irrelevant". Three common traps:
- The companion app. A SaaS business that also ships a mobile or desktop client has a CRA product, and its back end may come into scope as remote data processing.
- The on-premises edition. Offering a self-hosted version for enterprise customers turns that edition into a product.
- The SDK. A client library or agent customers install in their own systems is software placed on the market.
If you sell into regulated customers, you may also be a supplier to NIS2 entities, which brings supply chain security questions into contracts. Our comparison of NIS2 vs the Cyber Resilience Act sets out which regime covers what.
Frequently asked questions
Does the Cyber Resilience Act apply to mobile apps?
Yes. A mobile app made available on the EU market in the course of a commercial activity is a product with digital elements. The Commission lists mobile applications among the products subject to a conformity procedure.
Is my SaaS platform subject to the CRA?
Usually not, if it is a standalone service accessed remotely. Recital 12 and the Commission's July 2026 guidance treat such services as outside scope, though NIS2 and the GDPR may still apply. A client app, SDK or on-premises edition can bring parts of your offering into scope.
Is a free app outside the CRA?
Not necessarily. The CRA notes that commercial activity is not only about charging a price. Monetisation through other products or services, or through personal data use beyond security or compatibility, can still mean the software is placed on the market.
What is remote data processing under the CRA?
It is data processing at a distance for which the software is designed and developed by or for the manufacturer, and which the product needs to perform its functions. A device's companion cloud is the typical example. Internal tools such as CRMs or CI/CD pipelines are not included.
When do software makers need to comply?
Reporting of actively exploited vulnerabilities and severe incidents has applied since 11 September 2026. The security, documentation and CE marking requirements apply from 11 December 2027.
Building a connected product and want a second opinion on its security plan? Book a free 30-minute call with our team.
Cover photo by cottonbro studio on Pexels.